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:
rh7.3 with 2.4.20-13.7 has the same bug, "REJECT --reject-with tcp-reset" desn't work
redhat 7.2 with kernel-2.4.20-13.7 and iptables-1.2.5-3 has the same problem.
new kernel 2.4.20-18.7 still has this bug
Please provide more detail. This works faultlessly in testing here
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
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-
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.
reopened
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.
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]#
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
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.
seems still broken in 2.4.20-19.8 -j REJECT --reject-with tcp-reset works the same as -j DROP
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.
*** Bug 110544 has been marked as a duplicate of this bug. ***
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?
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!
Created attachment 96310 [details] Patch for kernel 2.4.20 fixing the bug
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'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.
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!