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
  • Hi all,

    we have been experiencing this problem with the outlook certificate issue for the last 6 months, the more we query what’s going on the more no one really knows and we are forced to deduce it’s a bug. Introduced somewhere after a 9.3 update. We are not sure which one but the short version is that Sophos have changed the way the proxy works.

    So we have deduced that this problem is encountered in 2 scenarios.

    Scenario 1

    This scenario, is only for users that are running Sophos UTM and using any other AV product in their internal network. Before the Sophos UTM proxy would actually receive the error message about the certificate but not forward that back to the end user. Hence the problem never arose but it did exist. They changed that and now the error actually goes to the end-user’s computer causing the pop up to occur. Not really certain if this is due to the ports issue as explained in the knowledgebase below, but I know that this command has resolved the certificate problem for some clients.

    1. Your organization is running Sophos UTM with some other AV vendor
      1. To fix this please run the following command as root on the backend
      2.   #cc set http display_http_blockpage_explicit_mode 1

     

     

    Scenario 2

    This scenario might be un-related however the logs we find prove to be different, this scenario requires you to be running Sophos AV using live protect on your internal network and the Sophos UTM to be your DNS proxy.

    We dug deeper on this matter and found it to be something with relation to DNS limitation on the backend, specifically Bind9 currently only allows 1000 DNS requests per second, and we saw the following error in the log:

    1. "no more recursive clients (1000/0/1000): quota reached”

    Every time this happened a enduser would experience the certificate pop up, so this is what I’m thinking… since Sophos changed the way the proxy works, when the DNS quota is reached and the proxy times out the error pops up, clients wouldn’t see this previously because the error would simply not be returned to the endpoint and the endpoint would try again. And the user would be none the wiser, but Sophos UTM proxy now sends the error back causing the popup to happen.

    Since then we have implemented a fix on our clients UTM to allow 2000 requests per second on the DNS (bind9).

    To confirm this was DNS proxy related we removed the Sophos UTM as the main DNS proxy and let our AD servers request directly to google DNS, the pop up disappeared.

    please note we are hitting the DNS limit because the actual live protect in the Sophos AV is making thousands of unique DNS queries causing the Bind 9 limit to be reached at certain times of the day.

    Command to change DNS recursive limit

    1. Log into the shell and elevate to root

    2. run the command cd /var/chroot-bind/etc

    3. edit the following files, with VI

                Named.conf

                Named.conf-default

                Named_split.conf-default

    4. under the options section on all of the files add the line: press I to insert text.

     

    recursive-clients 2000;

     

    so it would look something like this

     

    options {

       directory "/var/named";

       recursive-clients 2000;

    };

     

    5. write and save the changes eg: ESC, wq!

    6. then restart the Bind service using the following command

                # /var/mdw/scripts/named restart

     

    If you have HA setup, this will also need to be carried out on the slave unit as well

     

    I would also run the command in Scenario 1 afterwards

    • # cc set http display_http_blockpage_explicit_mode 1

     

    so as a summary:

     

    1. on Scenario 1 we believe that this works were still monitoring
    2. on Scenario 2 I also believe this to be the cause and I am not getting the errors at the moment
    3. proven fact is removing the utm as the DNS proxy and using another DNS server to query google directly stops the certificate pop up from happening.

     

    Anyone else with some ideas or solutions would be appreciated.

Reply
  • Hi all,

    we have been experiencing this problem with the outlook certificate issue for the last 6 months, the more we query what’s going on the more no one really knows and we are forced to deduce it’s a bug. Introduced somewhere after a 9.3 update. We are not sure which one but the short version is that Sophos have changed the way the proxy works.

    So we have deduced that this problem is encountered in 2 scenarios.

    Scenario 1

    This scenario, is only for users that are running Sophos UTM and using any other AV product in their internal network. Before the Sophos UTM proxy would actually receive the error message about the certificate but not forward that back to the end user. Hence the problem never arose but it did exist. They changed that and now the error actually goes to the end-user’s computer causing the pop up to occur. Not really certain if this is due to the ports issue as explained in the knowledgebase below, but I know that this command has resolved the certificate problem for some clients.

    1. Your organization is running Sophos UTM with some other AV vendor
      1. To fix this please run the following command as root on the backend
      2.   #cc set http display_http_blockpage_explicit_mode 1

     

     

    Scenario 2

    This scenario might be un-related however the logs we find prove to be different, this scenario requires you to be running Sophos AV using live protect on your internal network and the Sophos UTM to be your DNS proxy.

    We dug deeper on this matter and found it to be something with relation to DNS limitation on the backend, specifically Bind9 currently only allows 1000 DNS requests per second, and we saw the following error in the log:

    1. "no more recursive clients (1000/0/1000): quota reached”

    Every time this happened a enduser would experience the certificate pop up, so this is what I’m thinking… since Sophos changed the way the proxy works, when the DNS quota is reached and the proxy times out the error pops up, clients wouldn’t see this previously because the error would simply not be returned to the endpoint and the endpoint would try again. And the user would be none the wiser, but Sophos UTM proxy now sends the error back causing the popup to happen.

    Since then we have implemented a fix on our clients UTM to allow 2000 requests per second on the DNS (bind9).

    To confirm this was DNS proxy related we removed the Sophos UTM as the main DNS proxy and let our AD servers request directly to google DNS, the pop up disappeared.

    please note we are hitting the DNS limit because the actual live protect in the Sophos AV is making thousands of unique DNS queries causing the Bind 9 limit to be reached at certain times of the day.

    Command to change DNS recursive limit

    1. Log into the shell and elevate to root

    2. run the command cd /var/chroot-bind/etc

    3. edit the following files, with VI

                Named.conf

                Named.conf-default

                Named_split.conf-default

    4. under the options section on all of the files add the line: press I to insert text.

     

    recursive-clients 2000;

     

    so it would look something like this

     

    options {

       directory "/var/named";

       recursive-clients 2000;

    };

     

    5. write and save the changes eg: ESC, wq!

    6. then restart the Bind service using the following command

                # /var/mdw/scripts/named restart

     

    If you have HA setup, this will also need to be carried out on the slave unit as well

     

    I would also run the command in Scenario 1 afterwards

    • # cc set http display_http_blockpage_explicit_mode 1

     

    so as a summary:

     

    1. on Scenario 1 we believe that this works were still monitoring
    2. on Scenario 2 I also believe this to be the cause and I am not getting the errors at the moment
    3. proven fact is removing the utm as the DNS proxy and using another DNS server to query google directly stops the certificate pop up from happening.

     

    Anyone else with some ideas or solutions would be appreciated.

Children
  • Hey Mark, do your suggestions only apply for the UTM or do these work for XG boxes as well?

  • Hey there,

    I haven't taken a look at the xg backend yet, however I believe as it is Linux, it's just a matter of finding the same config files and editing them! So I hope so..

    I would load a vm and play around there on the xg before implementing it on the actual production box but I don't see why this won't work!

    This has been quite the nightmare for my clients! But try it! If your results are successful post it here then we know what the fix is and Sophos can action the changes. :)

    Hope this helps