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

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

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