Jason Stubbs wrote:
Hi,
While testing patches for IPVS, I found a strange behaviour of conntrack that
happens on an unpatched kernel too (2.6.24.4). Given the following rules:
iptables -A FORWARD -p tcp -d 192.168.1.3 --dport 80 \
-m state --state NEW -j ACCEPT
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -P FORWARD DROP
And a network setup where replies from 192.168.1.3 don't go via the same
machine - ie, they appear to be being dropped - the following conntrack entry
appears when sending only an ACK packet to 192.168.1.3:
ipv4 2 tcp 6 431684 ESTABLISHED src=192.168.0.104 dst=192.168.1.3
sport=12345 dport=80 packets=2 bytes=95 [UNREPLIED] src=192.168.1.3
dst=192.168.0.104 sport=80 dport=12345 packets=0 bytes=0 mark=0 use=1
If a SYN has been sent the following state appears and no traffic (including
an ACK) is allowed to pass:
ipv4 2 tcp 6 119 SYN_SENT src=192.168.0.104 dst=192.168.1.3
sport=23456 dport=80 packets=1 bytes=50 [UNREPLIED] src=192.168.1.3
dst=192.168.0.104 sport=80 dport=23456 packets=0 bytes=0 mark=0 use=1
I would think that behaviour to be correct, but an entry appearing when only
an ACK packet has been sent seems wrong. Is it a bug or intentional?
Probably cat /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_loose says 1?
--
"Los honestos son inadaptados sociales" -- Les Luthiers
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
