Bug 110544 - iptables' REJECT with tcp reset does not work
Summary: iptables' REJECT with tcp reset does not work
Status: CLOSED DUPLICATE of bug 91448
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.3
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-11-21 00:12 UTC by akopps
Modified: 2007-04-18 16:59 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2006-02-21 19:00:05 UTC

Attachments (Terms of Use)

Description akopps 2003-11-21 00:12:07 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030625

Description of problem:
We're using RedHat Linux 7.3 with all recent updates and the standard
kernel.  I have structured my iptables rules so that they look like
this, for example:

iptables -A INPUT -d 0/0 -p tcp --dport 0:1023 -j local
iptables -A INPUT -d 0/0 -p udp --dport 0:1023 -j local
# A bunch of IP addresses or subnets
iptables -A local -s xxx.xxx.xxx.xxx/32 -j ACCEPT
iptables -A local -s xxx.xxx.xxx.xxx/32 -j ACCEPT
iptables -A local -m limit -j LOG --log-prefix "netfilter: "
iptables -A local -p tcp -j REJECT --reject-with tcp-reset
iptables -A local -p udp -j REJECT --reject-with icmp-port-unreachable

This works. However, when tcp connections are rejected, the machine
does not send a TCP reset packet back to senders even though I have
explicitly specified this action. According to tcpdump output, nothing
gets sent back when a packet is denied. So, essentially, -j REJECT
seems to be acting like -j DROP. In fact, I don't have a rule that
says -j DROP anywhere in this script. Does anyone know why this is

Version-Release number of selected component (if applicable):
kernel-2.4.20-20.7 iptables-1.2.8-8.72.3

How reproducible:

Steps to Reproduce:
1. Add a rule that looks like this:
iptables -A INPUT -d 0/0 -s xxx.xxx.xxx.xxx/32 -p tcp --dport X -j
REJECT --reject-with tcp-reset

for some port X and IP address xxx.xxx.xxx.xxx
2. Start "tcpdump host xxx.xxx.xxx.xxx" 
3. Login to xxx.xxx.xxx.xxx and try to access the blocked service.

Actual Results:  Witness the tcp reset packet not being sent back to
the originating host.

Expected Results:  A TCP reset packet should be sent back to the host
that matched the
above rule.

Additional info:

This problem might exist in newer versions of RedHat Linux but I
haven't tested those.

Comment 1 Dave Jones 2003-11-21 15:12:17 UTC

*** This bug has been marked as a duplicate of 91448 ***

Comment 2 Red Hat Bugzilla 2006-02-21 19:00:05 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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