This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

9.201 - connections forgotten after any config change

Just upgraded from 9.1 to 9.201-23. After upgrade, it seems that any configuration change (including changed comment in network object) causes firewall to forget all connections. In case of "Use strict TCP session handling" turned on, TCP connection dies with any further activity (or keepalive), logging "strict TCP state" in packetfilter.log. In /proc/net/ip_conntrack the session seems alive, but UTM does fw functionality in userland also.

I am nearly sure that 9.1 has not this bug - I've experienced this behavior during the first day on 9.2 and never seen it for several months before on 9.1.

Also I've noticed wishes from the community that UTM should invalidate RELEVANT sessions after FIREWALL policy change and the target version mentioned was 9.2. It seems that the final implementation in 9.2 is to invalidate ALL sessions after ANY config change.

This thread was automatically locked due to age.

Parents

0 ondrej.holas over 10 years ago

Some changes to config are done automatically:

2014:05:15-14:33:04 utm confd[3115]: I main::top-level:652() => id="310a" severity="info" sys="System" sub="confd" name="object changed" class="network" type="dns_group" ref="REF_NtpPool" objname="NTP Server Pool" user="system" srcip="127.0.0.1" sid="***" facility="system" client="dns-resolver.plx" pid="11398" attr_addresses="['5.9.80.113','194.50.97.34','5.9.39.5']" oldattr_addresses="['83.231.183.4','87.124.126.49','87.117.251.3']"

2014:05:15-14:33:05 utm confd[3115]: I main::top-level:749() => id="310n" severity="info" sys="System" sub="confd" name="applied changes" user="system" srcip="127.0.0.1" sid="***" facility="system" client="dns-resolver.plx" pid="11398" version="9" storage="/cfg"

In such case, the connections are also forgotten. It sounds like the strict TCP checking in 9.2 is useless due to broken conn invalidation.

0 ondrej.holas over 10 years ago in reply to ondrej.holas
Well, upgraded to 9.202-28... The connections do not die after upgrade even with "strict TCP handling" turned on. The bad thing is that the connections are still forgotten after config change, but in 9.202-28 the checkbox "strict TCP handling" has no effect - session is resumed by data packet in both cases:

2014:05:15-21:05:49 utm ulogd[4277]: id="2002" severity="info" sys="SecureNet" sub="packetfilter" name="Packet accepted" action="accept" fwrule="3" initf="eth1" outitf="eth0" srcmac="CLIENT" dstmac="UTM" srcip="CLIENT" dstip="SERVER" proto="6" length="120" tos="0x00" prec="0x00" ttl="126" srcport="51997" dstport="22" tcpflags="ACK PSH"
Cancel
Vote Up 0 Vote Down

Cancel
0 funky81 over 10 years ago in reply to ondrej.holas
Well, upgraded to 9.202-28... The connections do not die after upgrade even with "strict TCP handling" turned on. The bad thing is that the connections are still forgotten after config change, but in 9.202-28 the checkbox "strict TCP handling" has no effect - session is resumed by data packet in both cases:

2014:05:15-21:05:49 utm ulogd[4277]: id="2002" severity="info" sys="SecureNet" sub="packetfilter" name="Packet accepted" action="accept" fwrule="3" initf="eth1" outitf="eth0" srcmac="CLIENT" dstmac="UTM" srcip="CLIENT" dstip="SERVER" proto="6" length="120" tos="0x00" prec="0x00" ttl="126" srcport="51997" dstport="22" tcpflags="ACK PSH"

May I know where to download 9.202-28?
I wonder why Sophos dont put this bug into known bugs list [:(]
Cancel
Vote Up 0 Vote Down

Cancel

Reply

0 funky81 over 10 years ago in reply to ondrej.holas
Well, upgraded to 9.202-28... The connections do not die after upgrade even with "strict TCP handling" turned on. The bad thing is that the connections are still forgotten after config change, but in 9.202-28 the checkbox "strict TCP handling" has no effect - session is resumed by data packet in both cases:

2014:05:15-21:05:49 utm ulogd[4277]: id="2002" severity="info" sys="SecureNet" sub="packetfilter" name="Packet accepted" action="accept" fwrule="3" initf="eth1" outitf="eth0" srcmac="CLIENT" dstmac="UTM" srcip="CLIENT" dstip="SERVER" proto="6" length="120" tos="0x00" prec="0x00" ttl="126" srcport="51997" dstport="22" tcpflags="ACK PSH"

May I know where to download 9.202-28?
I wonder why Sophos dont put this bug into known bugs list [:(]
Cancel
Vote Up 0 Vote Down

Cancel

Children

0 ondrej.holas over 10 years ago in reply to funky81

May I know where to download 9.202-28?
I wonder why Sophos dont put this bug into known bugs list [:(]

9.202-28 was available on FTP server since May 15th, but a few days later it was removed.

Also discussed here:

https://www.astaro.org/gateway-products/hardware-installation-up2date-licensing/52251-utm-9-202-28-soft-released.html
https://www.astaro.org/beta-versions/utm-9-2-beta/52281-9-202-28-new-bug-reverse-auth-no-longer-works.html
Cancel
Vote Up 0 Vote Down

Cancel
0 ondrej.holas over 10 years ago in reply to ondrej.holas
Assume the 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, instead of been discarded, silently resumes the session. 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 enabled by mirror 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 firewall inside UTM is now disputed for me.

Has anyone logical explanation of this behavior?
Cancel
Vote Up 0 Vote Down

Cancel
0 ondrej.holas over 10 years ago in reply to ondrej.holas

Moved to Network protection discussion as this is firewall-specific problem.

New thread: https://community.sophos.com/products/unified-threat-management/astaroorg/f/54/t/41580
Cancel
Vote Up 0 Vote Down

Cancel