Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 3 subscribers
  • Views 2386 views
  • Users 0 members are here
Options
Suggested
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

ondrej.holas
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
    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 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" 
  • 0 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 [:(]
  • 0 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
  • 0 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?
Reply
  • 0 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?
Children
Unfiltered HTML