Bug 91448 - Upgrading to kernel 2.4.20-13.8 breaks --reject-with tcp-reset
Upgrading to kernel 2.4.20-13.8 breaks --reject-with tcp-reset
Status: CLOSED ERRATA
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
8.0
i686 Linux
high Severity high
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
: 110544 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-05-22 14:32 EDT by Jim Tubman
Modified: 2015-01-04 17:02 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-12-31 14:01:08 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Fix for --reject-with tcp-reset (812 bytes, patch)
2003-06-11 21:07 EDT, Tom Eastep
no flags Details | Diff
Patch for kernel 2.4.20 fixing the bug (812 bytes, text/plain)
2003-12-03 09:17 EST, Peter Bieringer
no flags Details

  None (edit)
Description Jim Tubman 2003-05-22 14:32:34 EDT
Description of problem:
Since upgrading from 2.4.18-14 to 2.4.20-13.8 I get this problem.
/sbin/iptables -A INPUT -i eth0 -p tcp --dport 113 -j REJECT --reject-with tcp-reset
.... does not work anymore. I have to do this or my SMTP is SLOW.
/sbin/iptables -A INPUT -i eth0 -p tcp --dport 113 -j ACCEPT

This used to work before the kernel upgrade


Version-Release number of selected component (if applicable):
2.4.20-13.8

How reproducible:
100%

Steps to Reproduce:
1. upgrade kernel
2.
3.
    
Actual results:
SMTP slow because port 113 blocked

Expected results:
no change in firewall/iptables function

Additional info:
Comment 1 acount closed by user 2003-05-28 18:43:19 EDT
rh7.3 with 2.4.20-13.7 has the same bug, "REJECT --reject-with tcp-reset" desn't
work
Comment 2 Rajiv Manglani 2003-06-04 02:06:43 EDT
redhat 7.2 with kernel-2.4.20-13.7 and iptables-1.2.5-3 has the same problem.
Comment 3 acount closed by user 2003-06-07 11:32:07 EDT
new kernel 2.4.20-18.7 still has this bug
Comment 4 Alan Cox 2003-06-08 09:09:21 EDT
Please provide more detail. This works faultlessly in testing here
Comment 5 Jim Tubman 2003-06-08 11:11:52 EDT
This rule has been in my iptables for a long time:
/sbin/iptables -A INPUT -i eth0 -p tcp --dport 113 -j REJECT --reject-with tcp-
reset

After upgrading the kernel - SMTP was slow. Took 30 - 90 seconds for an email 
to leave my outbox. After much searching I found that this:
/sbin/iptables -A INPUT -i eth0 -p tcp --dport 113 -j ACCEPT
fixes the  problem. SMTP is fast again.

Even with the ACCEPT rule NMAP shows the port as closed because i have nothing 
running on that port. I guess this is secure enough. The email server we use is 
Courier 0.42.1  http://www.courier-mta.org. I can reproduce this 100% of the 
time. Simply adding the reset slows down the SMTP.

If you need more information let me know. Not sure what else to tell you.

Jimmy
Comment 6 acount closed by user 2003-06-08 11:50:10 EDT
for me it's not a bug, it was my mistake. Because I am using this rule 
$IPTABLES -A irc -p TCP --dport 1080 -j REJECT --reject-with tcp-reset
to avoid a big delay but IRC server is sending UDP to socks port.
The _correct_ rule is:
$IPTABLES -A irc -p UDP --dport 1080 -j REJECT --reject-with icmp-port-unreachable

-thanks for your time alan, it was my mistake-
Comment 7 Rajiv Manglani 2003-06-08 13:38:27 EDT
i ran this:

iptables -I INPUT -p TCP -i eth0 -j tcp_packets
iptables -I tcp_packets -p TCP --dport https -j REJECT

and then from another host:

nc -v host1 https ... and it correctly and quickly says connection refused.

however, if i clear the chains then run:

iptables -I INPUT -p TCP -i eth0 -j tcp_packets
iptables -I tcp_packets -p TCP --dport https -j REJECT --reject-with tcp-reset

and then:

nc -v host1 https ... the connection attempt just hangs.


i believe this is still a bug, please reopen.
Comment 8 Jim Tubman 2003-06-08 14:17:10 EDT
reopened
Comment 9 Alan Cox 2003-06-08 15:12:16 EDT
On a test setup this also works perfectly. 

iptables -F
iptables -N tcp_packets
iptables -I INPUT -p TCP -i eth0 -j tcp_packets
iptables -I tcp_packets -p TCP --dport https -j REJECT --reject-with tcp-reset

Please test with no other rules present on either host.

Comment 10 Tom Eastep 2003-06-10 19:37:14 EDT
Here's a simple demonstration of the problem:

[root@lists root]# uname -a
Linux lists.shorewall.net 2.4.20-18.9 #1 Thu May 29 07:09:43 EDT 2003 i586 i586 
i386 GNU/Linux
[root@lists root]# iptables -L -n -v
Chain INPUT (policy ACCEPT 48 packets, 2790 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 35 packets, 2436 bytes)
 pkts bytes target     prot opt in     out     source               destination
[root@lists root]# iptables -I OUTPUT -p tcp --dport 23 -j REJECT --reject-with 
tcp-reset
[root@lists root]# telnet 206.124.146.176
Trying 206.124.146.176...

<after several seconds, I hit ^C>

[root@lists root]# iptables -L -n -v
Chain INPUT (policy ACCEPT 406 packets, 34978 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 309 packets, 28661 bytes)
 pkts bytes target     prot opt in     out     source               destination
    2   120 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0    
      tcp dpt:23 reject-with tcp-reset
[root@lists root]#

Comment 11 Alan Cox 2003-06-10 20:03:52 EDT
Ok your one line demonstration works on the older 2.4.20 and breaks on 2.4.21rc1
and the current Red Hat errata. Looks like a netfilter bug crept in somewhere
Comment 12 Tom Eastep 2003-06-11 21:07:46 EDT
Created attachment 92350 [details]
Fix for --reject-with tcp-reset

Reverses the source and destination IP addresses in the call to ip_route_out()
to correspond to the call to that function in 2.4.20.
Comment 13 Piero Calucci 2003-07-31 08:20:36 EDT
seems still broken in 2.4.20-19.8 -j REJECT --reject-with tcp-reset works the
same as -j DROP
Comment 14 Peter Bieringer 2003-08-28 11:11:49 EDT
Confirmed by me on RHL 7.3 kernel 2.4.20-20.7 
2.4.18-3 sends TCP resets.

A simple ruleset like
iptables -I INPUT -i eth0 -p tcp --dport echo -j REJECT --reject-with tcp-reset
and a "nc $buggy-kernel-host echo" shows the difference (also tcpdump).

BTW: do not test on loopback interface, here the bug don't came up.

I have now rebuilded a kernel containing fix from attachment (id=92350)...voila,
tcp-reset is working again.

BTW: looks like this bug was solved in 2.4.21, see patch-2.4.21 (SADDR/DADDR are
exchanged):

diff -urN linux-2.4.20/net/ipv4/netfilter/ipt_REJECT.c
linux-2.4.21/net/ipv4/netfilter/ipt_REJECT.c
--- linux-2.4.20/net/ipv4/netfilter/ipt_REJECT.c        2002-11-28
15:53:15.000000000 -0800
+++ linux-2.4.21/net/ipv4/netfilter/ipt_REJECT.c        2003-06-13
07:51:39.000000000 -0700
@@ -61,12 +63,28 @@
...
+       /* Routing: if not headed for us, route won't like source */
+       if (ip_route_output(&rt, oldskb->nh.iph->SADDR,
+                           local ? oldskb->nh.iph->DADDR : 0,
+                           RT_TOS(oldskb->nh.iph->tos), 0) != 0)
+               return;
...


@@ -130,16 +148,6 @@
...
-       /* Routing: if not headed for us, route won't like source */
-       if (ip_route_output(&rt, nskb->nh.iph->DADDR,
-                           local ? nskb->nh.iph->SADDR : 0,
-                           RT_TOS(nskb->nh.iph->tos) | RTO_CONN,
-                           0) != 0)
...


BTW: digging through kernel patches it looks like this bug was introduced in
2.4.19 during some code replacements.

I suggest severity=security, because all iptables-related firewall setups are
affected.


Comment 15 Dave Jones 2003-11-21 10:12:19 EST
*** Bug 110544 has been marked as a duplicate of this bug. ***
Comment 16 Michael Schwendt 2003-12-02 06:20:27 EST
On 7.3, the kernel package changelog between revision 20.7 and 24.7
does not mention that a fix would be included. What's the status of
this bug?
Comment 17 Peter Bieringer 2003-12-02 13:43:16 EST
I've made a short test on 2.4.20-24.7 (RHL 7.3): -j REJECT
--reject-with tcp-reset doesn't still work!
Comment 18 Peter Bieringer 2003-12-03 09:17:36 EST
Created attachment 96310 [details]
Patch for kernel 2.4.20 fixing the bug
Comment 19 Jan Grobecker 2003-12-31 10:57:42 EST
Looks like this has finally been fixed. At least it's already patched
in kernel-source-2.4.20-27.7 which I just tried to apply
pb@bieringer.de's patch for installing it on my RH 7.3 box (like I've
been used to for every kernel 2.4.20 release). If anyone can confirm
this for RH 8 and 9 someone who's allowed to should close this bug.
Comment 20 Jan Grobecker 2003-12-31 13:08:14 EST
Sorry, guys! No need to bother, just noticed this bug as resolved in
the kernel-2.4.20-27 changelist in RHN. So only thing left to do is to
close this bug as resolved fixed for somebody at Red Hat. All the best
for you in 2004!

Note You need to log in before you can comment on or make changes to this bug.