SSL interception for IMAPS ignored; Non-WWW IPv6 traffic fails

I just finished spending 6 hours troubleshooting why email (Google Apps) completely quit working on the network, and determined it's once again due to issues with the XG's broken IPv6 implementation. I'm ready to quit using XG - never had this issue with UTM at all . The broken implementation of IPv6 in XG is getting extremely frustrating.

The symptom encountered was that email clients would never connect to on 995 - the connection would time out. Troubleshooting determined that a "telnet" timed out and never completed because it was attempting to connect to the IPv6, despite having full IPv6 connectivity ( passed all tests) - but connecting to the IPv4 destination succeeds. I determined that this is because IPv6 requires being proxied via the XG and can't happen directly, while IPv4 can.  

I then found that if I enabled the "Scan IMAPS" option within the policy, telnet connections would work successfully, however the email client connections would fail due to the use of HSTS and the wrong certificate from the XG being provided.

Adding the domain(s) to the "Local TLS Exclusion List", or to the web exceptions, or disabling SSL/TLS interception entirely, made no difference. The connection was always attempted for interception. 

Ultimately, disabling IPv6 resolves the issue as well, since the computer no longer attempts to connect to the IPv6 destination, but that's not an ideal solution either.

Is anyone aware of a way to disable certificate interception for IMAPS scanning? Or to get IPv6 to function directly without being Proxied and NAT'd?

  • Hi,

    your IMAPS port should be 993.

    You cannot use the IPv6 on XG without a NAT.

    None of my IPv6 mail rules carry any traffic, I suspect that none of the ISPs have IPv6 0n the ir mail servers which seems strange.

    What version of XG are you running? v18.0.1 MR-1 enabled me to fix my mail issues, so waiting until the new MR-1 is released to try again.