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

Question

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

Elardus Erasmus · Accepted Answer

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 &ldquo;unstable&rdquo; 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

Elardus Erasmus · Answer

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

Elardus Erasmus · Answer

Hi Nicolai, 
 The ATP exception is a workaround to get past the immediate issue that you experienced. The issue was in the TLS inspection path, due to the hairpin deployment. The ATP exception, in addition to disabling all other features on the firewall rule, means that these connections will not be sent for TLS decryption and inspection anymore. If you are happy with this, then you can leave it as is. 
 The problem with hairpin type deployments, however, is larger than this alone, and you may experience other problems. As mentioned in the past, it can cause all sorts of trouble. Functionally and functions/features that rely on traffic accounting per user - the XG/S effectively sees the traffic with the same src/dst details, ingressing (and egressing) the firewall twice. 
 That is why masquerading on the router is recommended in these types of scenarios. The firewall will essentially see two different flows, and then you can turn TLS inspection back on if you want, by removing the ATP exception and enabling more features on the firewall rule if desirable. Even though it will be seen as two flows, only one of them will be inspected - so you will not use double the resources to inspect the traffic. 
 We are in the process of writing a Knowledge Base Article on this, which may contain a few more details. I will send it along once it is done. 
 Hope it helps. 
 Regards, Elardus

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

Top Replies