9.201 - connections forgotten after any config change

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.

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" 

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.

Thanks Sir..You're report here help me alot.
It's been almost a day I'm trying to solve whats the problem with my firewall since upgrade and almost gave up and wanna downgrade the firmware.

But your analysis here and solution, saves me [:D]

Thanks

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 [:(]

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

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?

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

Hi, would enabling the strict TCP options be a solution or workaround for this?

Barry

Barry,

I'm sure that in 9.201+ TURNING ON "strict TCP check" can (and in many cases will) cause observed problems. Let me summarize my experiences so far:

The problem with 9.201 is that UTM forgets connections after config change, so there's workaround to TURN OFF strict TCP checking to allow UTM to pickup the session in the middle (this may not work in all scenarios, NAT/masq could be problematic).

In 9.202 it seems that some changes in code were implemented to work around (not yet fix!) the problems with connection dropping. One of them is changed effect of setting "strict TCP check" as if it were permanently TURNED OFF, thus UTM can pickup session from the middle regardless of "strict TCP check" setting. And probably the second change is TCP session pickup by reply packet (see new thread https://community.sophos.com/products/unified-threat-management/astaroorg/f/54/t/41580 for details).

Whatever it is, 9.2 is still too buggy. I hope 9.204 would be at least a bit better...

(9.203 is scheduled for tomorrow to fix new OpenSSL vulnerability: Advisory: OpenSSL Security Advisory [05 Jun 2014] Personally I expect that no other fixes will be included in 9.203.)