Sophos UTM: Decommissioning of obsolete URL categorization services CFFS.Click here for important info.

SSL/TLS inspection | bridge mode | multiple local subnets | SSL connections time out

Dear community,

i think we are suffering the same problem mark57165 described in his post 'IPS Service - with no FW rules - Prevents Certain Sites from Loading'.

https://community.sophos.com/sophos-xg-firewall/f/discussions/134535/ips-service---with-no-fw-rules---prevents-certain-sites-from-loading

Our Situation:

SOPHOS XG / XGS Firewall

in Bridge Mode

no firewall rule / no SSL/TLS inspection rule for the problem connections

multiple IPv4 Subnets on the LAN side

SSL/TLS connections from one local subnet to another local subnet time out

Unsatisfying workarounds:
- disable SSL/TLS inspection completely
- stop IPS Service
- add bypass-stateful-firewall-config rules for the local subnets


Is someone facing the same problem?

Did someone find a solution?



Regards, Nicolai



Added V19.5 MR3 TAG
[edited by: Erick Jan at 9:20 AM (GMT -7) on 1 Sep 2023]
Parents
  • To all of you following this topic:

    New additional workaround:

    set ips ac_atp exception fwrules <add at most eight rule IDs, comma separated>

    See: Sophos Firewall: Bypass a specific firewall rule for application classification and ATP:

    https://support.sophos.com/support/s/article/KB-000038900?language=en_US

    Does anyone exactly know what this exception does? And why it could help here?

    Regards, Nicolai

  • The reason this workaround (disabling ATP) is working, is because this feature was the only remaining feature that was also interested in the initial part of TLS connections (you have everything else disabled on rule 12 already, like IPS, Web, AV, etc.). Even if not decrypting, there is data in the handshake that is used for threat protection. With ATP (and the rest of the features) disabled, packets on the TLS connection do not have to be sent into the DPI and TLS processing logic anymore. This is effectively the same as completely disabling SSL/TLS, that you already found to be a workaround too.

    In this setup, with the external gateway directing traffic back through the XG/S, the TLS connection is effectively "picked up" twice. From client to router, and then again (the same data) from the router to the server. Resulting in the issue that you are experiencing.

    If the XG/S were to make the routing decision, or the client and server were not routed through the same XG/S, this issue would of course not be seen (the connection would not traverse the TLS inspection logic twice).

    We will have some more discussion on this internally.

    Thanks for the detailed info that you have provided. Based on it, we were able to determine the cause of what you are experiencing.

    Best,
    Elardus

  • Hi Elardus,

    thanks for these technical informations.

    I had already guessed that the fact, that the TLS connection is effectively "picked up" twice, could be the problem.

    For the moment we can live with the 'set ips ac_atp exception fwrules'-solution.

    Does this setting survive firmware updates?

    How do you suggest to carry on? Can we hope for an adjustment in one oft the next firmware versions?

    Regards, Nicolai

  • Yes, that setting is saved and retained across upgrades.

    I understand your interest in this going forward. We are still to discuss and finalize the course of action here. I will update you once there is progress.

    Best,
    Elardus

  • Hi Elardus,

    Thanks a lot!!

    I look forward to hear again from you!

    Best, Nicolai

  • Hi Nicolai,

    So, it turns out this hairpin type of deployment could have ramifications to multiple features. E.g. the proxy would also fail, normal conntrack could become “unstable” in the presence of retransmits and speed differences between the various links involved, double accounting of traffic, and so on.

    In this case, the recommended solution is to configure masquerading on the router. In that way, the connection between the client and router, will be distinct from the one between the router and server. And that should get everything working as expected.

    We plan to create a KB article for this. Hopefully helping others that run into the same thing in the future.

    Thanks for your time on this.
    Elardus

Reply
  • Hi Nicolai,

    So, it turns out this hairpin type of deployment could have ramifications to multiple features. E.g. the proxy would also fail, normal conntrack could become “unstable” in the presence of retransmits and speed differences between the various links involved, double accounting of traffic, and so on.

    In this case, the recommended solution is to configure masquerading on the router. In that way, the connection between the client and router, will be distinct from the one between the router and server. And that should get everything working as expected.

    We plan to create a KB article for this. Hopefully helping others that run into the same thing in the future.

    Thanks for your time on this.
    Elardus

Children
No Data