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

Sophos XG breaks SSL when connecting to Outlook Anywhere

Hi, I have setup a virtual XG firewall at home. I have have created an "allow all" policy for the web filter and have switched off the "Scan HTTPS" Feature. In my web browsers, this works fine and I see the SSL certificates of all the websites I visit.

When I start Outlook and connect to the mailbox of my company, I get a certificate warning from Outlook 2013 that shows the Sophos CA. Obviously, the XG appliance is breaking SSL for the connection to Outlook Anywhere. The company is running Exchange Server 2013.

When I connect to another Exchange 2013 system, the certificate warning does not appear, which totally confuses me. I assume this issue might be related to Exchange 2013 autodiscover, but I am sure it is related to Sophos XG as well. I did not have this problem with UTM 9 that I have been using before migrating to XG.

Do you have any ideas on how to resolve this issue?

Kind regards, Matthias



This thread was automatically locked due to age.
Parents
  • Hello Friends,

    I found this post is more interesting and I want to jump into it. I may answer to your problems at some levels. Other than this, it's a development only. Some might get a clue what is about am I talking. Right?

    Actually, to improve user experience, there was an additional development taken into SF OS proxy.  Whenever there is an error because of web request blocked or network error, proxy will try to inform the end user about the error. And yes if your request is HTTPS then proxy will handshake with its own CA (SSL CA) to send the error message.  I guess this is gonna wrong here for some user (might for all)  if https request is blocked because of network error.

    In outlook case (most probably Office365), autodiscover domain connection (say for example: https://autodiscover.example.com/autodiscover/autodiscover.xml OR https://example.com/autodiscover/autodiscover.xml) gets failed because of server which sends RST signal, I mean server is not accepting the connection request which leads proxy to send the same "connection error" with 502 response code to end user because proxy is also failed to connect to server and which is resulting into certificate error. 

    Note: You may have different reason other then this. But this is what I found at some customer place.  

    And the good news is, we have an enhancement in which we are going to revert the changes. That means proxy won't send any error message if there is a network issue.  

    This is what all about the issue is but what is the solution?  hold on...hold on...

    To resolve this issue, we can have two options.

    (1) Install the SSL CA certificate: 

    I know this is not a good solution, even I don't think it is a solution especially when I didn't configure SSL scanning.  But for a suggestion, I think it is a good solution. just kidding...

    (2) Using FQDN base rule:

    Create a FQDN host, in that configure your domain of Office365  like, example.com & autodiscovery.example.com etc...

    Create network base security policy and in that configure FQDN host as a destination network.

    Note: Don't apply any web filter policy in this rule. 

    2nd solution is more helpful instead of disabling whole web filter policy feature. It requires only less configuration.

    Hope it clears to you and helpful to you.

    Regards,

    Vishal Patel

  • I can confirm this works on XG (Second option)

    Make sure you put it before you default outbound rule.

  • Yes HaydenKirk  and thanks for your confirmation, 

    Also make sure that you have same DNS server in end user as well as in XG DNS settings.

    Regards,

    Vishal Patel

  • Just as a heads up - this still breaks for me about once or twice a day. I will get Outlook popping up asking about the certificate. Any reason why this would happen?

    I also notice that when malware inspection is on, active connections are dropped after a few minutes. When turning this off, connections stay persistent. 

  • I've created the rule, but it still happen's once or twice a day... (in several customers)

    Has anyone solved this?

     

    thank you

  • I had similar issues, creating a rule never fully removed the certificate warnings.  We are using Outlook with Office 365 email.

     

    the only solution that worked for me was to deploy the certificate from the XG.  I haven't tested this after the V16 release, only prior.

  • I had this problem here, solved it creating a rule without web filter BEFORE the rule that have web filter, allowing everithing to autodiscover.mydomain.onmicrosoft.com and autodiscover.mydomain.com.

Reply Children
  • Hi all,

    I am having the same issue with Citrix StoreFront and XG.

    And adding the rule without Web filter does not solve the problem.

    Even turning off web filtering completely on default rule, does not solve the problem. (It's a test environment only, so I can turn everything off)

    When I try to https to StoreFront, I am presented with Sophos Appliance certificate and the connection does not work.

    Any help would be much appreciated.

    Thanks.

    Regards.

  • I also created the rule with the FQDN of autodiscover.mycompany.com and it's still throwing security certificate errors at me. I did put it before the Default inbound/outbound rule. 

    Only way I don't get the certificate errors is if I turn off web filtering all together on every rule. 

  • we deployed the certificate via group policy to all machines to clear up the message.

     

    its kinda lame that we needed to do that.  The Sophos response thus far has been that is necessary and there exists no way to make it go away. 

     

    The issue with that response is that other vendors don't require this to happen in order to inspect the traffic, this is an XG-specific thing that they desperately need to fix. 

  • The autodiscover certificate or the Sophos XG certificate? 

  • The Sophos certificate. 

     

    in our experience, we were getting the error on almost every site when turning on web filtering until the certificate was deployed. 

     

    with filtering turned off, we still got an error in Outlook related to the same problem. 

     

    Hence, we just bit the bullet and deployed the certificate, which isn't that difficult via a GPO

  • Is there an article or something you used to correctly deploy the certificate? 

  • If I recall correctly, in a world without XG:

    Outlook tries to do an SSL connection to a site that does not exist (or supports SSL?)

    Outlook fails on the SSL connect

    Outlook tries to do an SSL connection to the next site, and that works

    Outlook is happy.

     

    In a world with XG:

    Outlook tries to do an SSL connection to a site that does not exist (or supports SSL?)

    The XG intercepts this, can see that it will fail.  It does man-in-the-middle so that it can display a friendly error message.

    Outlook gets a successful SSL connect, but cannot use it.

    Outlook is not happy.

     

    Try the following:

    Go to admin advanced console and type the following command.  This turns off all microapp detection but also affects some HTTPS interception.

    system application_classification microapp-discovery off

     

    Do a packet-capture (wireshark) on the client computer

    Capture the failure.  Look at exactly what it is trying to connect to.

    Create a higher level firewall rule with the destination IP of what you found in the packet capture.  No HTTPS decryption, etc.

    Retest.  If it continues to fail, take another look at the capture to find next thing it tries to connect to.

     

    Remember - When the application fails it is probably when the packet capture says there is a successful connection (unfortunately it is to the XG not to whatever it thinks it is going to).  You need to actually let that connection through so that the connection fails, causing the application to go to the next one and succeed.

  • that seems like a lot of work to fix something that Sophos should be fixing.  I agree with your breakdown of what is happening.

     

    but seriously, deploying the certificate takes much less time and effort than the troubleshooting you are describing here.

  • Deploying the Sophos Cert via Group Policy seems to be working for me.