Bug 91448

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!