Situation: Connect to SSH server through UTM and then reboot UTM. The SSH server has configured TCP keepalives, so it is expected that after UTM reboot, the keepalive packet from SSH server will be rejected and the TCP session will die.
But after reboot, the traffic is as follows:
utm:/root # tcpdump -i eth0 ip host *SSH_SERVER*
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
08:15:48.009572 IP *SSH_SERVER*.ssh > *CLIENT*.64737: Flags [.], ack 1290682868, win 228, length 0
08:15:48.011201 IP *CLIENT*.64737 > *SSH_SERVER*.ssh: Flags [.], ack 1, win 16570, length 0
(eth0 is facing towards the SSH server)
The keepalive ACK packet (green), instead of been discarded, silently resumes the session, client responds with another ACK (red) and the session continues well. As seen in ip_conntrack, new session appears:
utm:/root # cat /proc/net/ip_conntrack | grep *SSH_SERVER*
tcp 6 290 ESTABLISHED src=*SSH_SERVER* dst=*CLIENT* sport=22 dport=64737 packets=1 bytes=40 src=*CLIENT* dst=*SSH_SERVER* sport=64737 dport=22 packets=1 bytes=40 mark=528384 use=2
So from netfilter perspective, the session is established in REVERSE DIRECTION, as if it were ACCEPTed by mirrored rule [:O]
And finally, there's no record in packetfilter.log.
I'm still calm, since my UTM is surrounded by Cisco 87x routers with CBAC, but the statefulness of firewall inside UTM is now disputed for me. The strange thing in iptables configuration is that eth0 has some rules (mostly marking) in primary filter chains (INPUT, OUTPUT, FORWARD) while the other interface (eth1) has not such.
No NAT. "TCP strict" turned on.
Has anyone logical explanation of this behavior?
This thread was automatically locked due to age.
