Connection tracking and REJECT target.

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

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.