Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 38 subscribers
  • Views 724 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

PowerPete

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 imap.gmail.com on 993 - the connection would time out. Troubleshooting determined that a "telnet imap.gmail.com" timed out and never completed because it was attempting to connect to the IPv6, despite having full IPv6 connectivity (test-ipv6.com 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?



This thread was automatically locked due to age.
  • 0

    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.

    Ian

    XG115W - v20 GA - Home

    XG on VM 8 - v20 GA

    If a post solves your question please use the 'Verify Answer' button.

  • 0 in reply to rfcat_vk

    Sorry, 995 was a typo, 993 is correct.

    After some further testing, the IPv6 is a red herring - the issue returned a few days later with it disabled. While IPv6 only functions if web proxy is enabled, it's definitely related to the SSL Inspection & web filter engine, although disabling SSL Inspection made no difference. However, when I un-checked "Scan HTTP and decrypted HTTPS", the issue went away and everything functioned correctly. I then re-enabled it and the issue has not reoccured.

    In the SSL/TLS Inspection logs, I noted that there were failures for the host (imap.gmail.com) previously with a "Dropped due to TLS engine error: FLOW_TIMEOUT[5]", whereas now they are going through successfully.

Unfiltered HTML