Inbound TLS on Sophos XG and XGS does not work like Palo Alto’s “inbound inspection”. Sophos inspects outbound TLS, and for inbound traffic it uses a WAF or reverse proxy. If you want TLS terminated before traffic reaches the origin, that is the model to work with.
If TLS already terminates on a reverse proxy in the DMZ, leave it there. The Sophos Web Application Firewall is also a reverse proxy: it can protect web servers and apply WAF rules, but it terminates and re-encrypts traffic rather than acting as an inline decryption engine. The product docs for TLS inspection and inspection rules set out Sophos’s model and the zones and rule types it supports: https://docs.sophos.com/nsg/sophos-firewall/21.5/help/en-us/webhelp/onlinehelp/AdministratorHelp/Web/HowToArticles/WebProxyDPITLSDecryption/ and https://docs.sophos.com/nsg/sophos-firewall/21.0/help/en-us/webhelp/onlinehelp/AdministratorHelp/RulesAndPolicies/SSL/TLSInspectionRules/.
For outbound HTTPS inspection, create or import a CA on the Sophos device, enable DPI or web proxy TLS inspection, and add an inspection rule that matches the traffic you want decrypted. The CA needs to be trusted by the endpoints. DPI mode is the better fit for performance; use web proxy when you need URL filtering against decrypted content.
For inbound traffic, treat Sophos as a reverse proxy or put a decryption-capable proxy in front of the origin servers. If you want behaviour like Palo Alto’s inbound inspection, terminate TLS on a dedicated reverse proxy in the DMZ and let it forward plain HTTP to internal services, or use the Sophos WAF as the terminating proxy. Do not try to force a TLS inspection rule with the source zone set to WAN. In many cases the UI will not offer WAN as a source, because the inspection rules are built for outbound or proxy-style paths.
On XG and XGS hardware, map public IPs with DNAT to the proxy or WAF virtual server. Bind certificates to the WAF or proxy, not to a generic inspection rule. That keeps SNI, headers, and client certificate flows intact where they matter.
Validation is straightforward.
- Test with a browser and
curl -vk. If the firewall is terminating TLS, you will see its certificate. If the origin server is terminating, you will see the origin certificate. That tells you which device is decrypting. - Packet capture on the WAN interface is useful. Look for Client Hello and Server Hello sequences. If you see a Server Hello from the firewall, it is terminating. If you only see passthrough TLS messages, the firewall is not decrypting that flow.
- Check certificate chains on clients. If a decrypted flow shows a certificate signed by your inspection CA, a client missing that CA will throw certificate errors. Install the CA on any endpoint that needs to trust decrypted sessions.
- If WAN is not available as a source zone when you create an inspection rule, that is expected. Move the termination point to the DMZ or use the WAF as the terminating proxy.
The common failures are predictable.
- Clients see certificate errors: import the firewall CA into the client trust store, or switch to a proxy that uses a public certificate for inbound termination.
- SNI does not reach the origin: terminate TLS on the proxy and configure HTTP host headers for multiple backends. Sophos WAF has limits compared with full reverse proxies such as Nginx or HAProxy.
- Full decryption hits performance: enable DPI streaming, cut back the number of rules that need full inspection, or offload TLS to dedicated hardware or a proxy.
For true inbound TLS/SSL inspection in the Palo Alto sense, use a dedicated reverse proxy or Sophos WAF as the termination point. Use Sophos XG/XGS TLS/SSL inspection for outbound and proxy inspection paths. Keep termination and backend routing clear, and check the result with curl and packet captures before you call it done.
