Connection tracking and REJECT target.

Connection tracking and REJECT target.

[Anders Peter Fugmann]

Hi,

I'm seeing some strange classification by the connection tracking system
of packets being generated by the REJECT target.

Consider the following rules:

iptables -A OUTPUT -m state --state RELATED -p tcp --sport 113 -j LOG
--log-prefix "RELATED:"
iptables -A OUTPUT -m state --state ESTABLISHED -p tcp --sport 113 -j
LOG --log-prefix "ESTABLISHED:"

iptables -A INPUT -p tcp --dport 113 -j REJECT --reject-with tcp-reset

Marks the ACK,RST packet generated to reset the TCP connection as related:

Feb 22 22:01:14 localhost kernel: RELATED:IN= OUT=eth0 SRC=10.0.0.2
DST=10.0.0.254 LEN=40 TOS=0x10 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP
SPT=113 DPT=51889 WINDOW=0 RES=0x00 ACK RST URGP=0

I have no ident daemon running on the machine. Removing the reject rule
from the INPUT chain, makes the ACK,RST packet being marks as RELATED
as expected:

Feb 22 22:01:26 localhost kernel: ESTABLISHED:IN= OUT=eth0 SRC=10.0.0.2
DST=10.0.0.254 LEN=40 TOS=0x10 PREC=0x00 TTL=64 ID=20 DF PROTO=TCP
SPT=113 DPT=51891 WINDOW=0 RES=0x00 ACK RST URGP=0

Is this intended behaviour? Are RST,SYN packets (or any other packet
generated by a REJECT rule) automatically marked as RELATED by design?

The problem is observed on Linux 2.6.15 and 2.6.16-rc4.

Regards
Anders Fugmann

Re: Connection tracking and REJECT target.

[Philip Craig]

On 02/23/2006 07:10 AM, Anders Peter Fugmann wrote:
> Is this intended behaviour? Are RST,SYN packets (or any other packet
> generated by a REJECT rule) automatically marked as RELATED by design?

This is by design.  It is due to the RST being generated at different
points within the network stack.

When the REJECT rule creates the RST, the SYN is immediately dropped,
and so there is no existing established conntrack for the RST.

When the TCP layer creates the RST, the SYN has already passed through
all of netfilter, the conntrack is created, and so the RST can use it.