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

V17.0.2 MR2 HTTPS Outlook clients are dead, don't upgrade.

After upgrading to V17.0.2 MR2 all outlook clients connected to Office365 as exchange HTTPS/IMAP are dropped cause using HTTPS scanning & decrypt.

Outlook error when using scanning and decrypt with appliance certificate.

"There is a problem with the proxy server security certificate.The name on the security certificate is invalid or does not match the name of the target site outlook.office365.com"

Going back again to V16.5.8 for the 4th time faild to keep running V17, V17.0.1 MR1, and last but not least V17.0.2 MR2.

Please fire XG team and open applying SG UTM on your HW appliances to make us "paid customers" keep running Sophos firewall device, until you can fix and test XH firewalls enough and ready to production as NGFW.

 

Respect your name SOPHOS.

Until now not going to renew our license due to poor and unreliable XG Firewall product.



This thread was automatically locked due to age.
Parents
  • Have you considered or already added  a scanning exception rule for office365.com in the Web->Exceptions? If not, that may address the issue as you can allow a known site that you trust to avoid scanning. You could also create a first firewall rule that is specifically for office365 and not enable scanning.Either of those could help both performance and avoid the certificate issues. In a sense, this isn't really a Sophos issue. That is how SSL/TLS works along with how default Sophos https scanning works.

     

    Regards,

    Gary

Reply
  • Have you considered or already added  a scanning exception rule for office365.com in the Web->Exceptions? If not, that may address the issue as you can allow a known site that you trust to avoid scanning. You could also create a first firewall rule that is specifically for office365 and not enable scanning.Either of those could help both performance and avoid the certificate issues. In a sense, this isn't really a Sophos issue. That is how SSL/TLS works along with how default Sophos https scanning works.

     

    Regards,

    Gary

Children
  • Hi GaryChancellor,

    I already working since V15 using scan and decrypt all HTTPS traffic including offie365 as we are using only the exchange email package and everything was working fine and smooth.

    Intrusion Prevention: default LAN to WAN

    Web policy: Allow All

    App Policy: Allow All

    Destination Domains = all office365 domains.

    all were working fine for more than a year now, only happened when upgraded to V17.0.2 MR2

    Even i upgraded before to V17.0.0 and V17.0.1 and also worked fine before downgraded cause other problems like VPN.

    I don't know if something changed in FW behavior or not but that was how we always worked by.

  • Haytham,

    I read your post with a lot of interest because I also use Office365 but I have not upgraded from V16 MR8 to V17 yet. I think I had the same issue after upgrading from V15 to V16, so I turned off scanning. I think I recall that V15 had some hidden scanning exceptions that were not visible until V16. I had to add additional exceptions after the upgrade from V15 to V16.

    Regards,

    Gary

  • Hi Gary,

    We did not have any issue in V16 regarding office365 using decrypt and scan until last version 16.5.8 and also upgraded to V17.0.0 and revert with same settings then upgraded again from 16.5.8 to 17.0.1 MR1 and revert back again also was working normal for office365.

    Only when upgraded from 16.5.8 to V17.0.2 MR2 that behavior changed and no more we can scan Office365 but when revert back again to V16.5.8 because of this issue, the issue is is now happening on 16.5.8 also and no more able to scan HTTPS traffic as before we upgraded also Antivirus service stopping every 5-10 min and Browsing also effected as most users complained in viewing normal websites they access daily.

    This was the first time we had an issue in reverting back to previous versions.

    Now i had to go forward again to V17.0.2 MR2 and everything working normal again until now except the office365 scan and decrypt still not applicable and had to not scan the traffic.

    We also cumming from V15 and i understand from support that still traces from V15 on the appliance, so we are going to reset and reconfigure from scratch to completely remove anything related to V15 as only solution to achieve that but waiting for V17 stable release to reset.

  • Your special firewall rule for office365 should be high than your other HTTP/HTTPS rules and should look like:
    LAN to WAN, Destination Office 365 domains
    Services: HTTP and HTTPS
    Web Policy: None
    App Policy: None
     
    When you set "Allow All" in the Web and App policy you are turning on the HTTP proxy and turning on IPS to look at and potentially interfere with your traffic.  Right now your client is trying to connect to outlook.office365.com and is problem expecting it to fail to connect.  When you send it through the web proxy with an Allow All policy, the proxy will see the fail to connect, then try to serve a friendly error message back to the client using it's own certificate.  Outlook then sees it as a certificate problem.  By using a Web Policy of "None" the proxy is not used, the Outlook client properly fails to connect to outlook.office365.com and then it tries to connect to the next server in your list.
     
    There were some changes between v16 and v17 that might have affected this (we changed block pages) however I can't think of anything functionally that would have made it stop working - especially in MR2.
     
    ---
     
    If the above does not work:
     
    There was a change made (NC-13909) in 16.5 MR4 (16.05.4) that affected Office 365 and HTTPS scanning, fixing an issue that existed in all versions MR3 and earlier.  This fix included both a code change and a configuration change.  However it is possible that if you've been installing and rolling back it may be that the configuration side of this has become incorrect.
     
    In 16.5 MR4 and later, and all of 17 the following configuration should be applied.
    Go into the command line Device Console (this is not SSH)
    system application_classification microapp-discovery show
    The value should be off.
    system application_classification microapp-discovery off
     
     
    ----
     
    If the above still does not work:
     
    v17.0 MR2 also had a change (NC-22403) that could affect Outlook but only in Standard/Explicit proxy mode, not in transparent mode.  However the effect should only have improved Outlook because we are passing back a more original error condition to the Outlook client rather a friendly error message.  After 17 MR2 we use our certificate less, not more.
     
    If you are still having problem please let me know if you are using transparent mode or direct mode (eg have a proxy explicitly configures in IE), provide screenshots of your firewall rules and definitions, and copies of any error messages and logs.
  • Hi Michael,

    Thanks & appreciate your clear and reasonable descriptions as i think it match our case as we stayed in V16 most of the time on 2 versions V16.01.4 then directly to V16.05.5 until switched to 16.05.8 recently then V17s (tried all other versions until since V15 until V16.01.4 and after 16.05.5, )

    (in previous working settings used default IPS policy LANtoWAN, used customized Web policy and App was Allow all, Services was ANY.

    Yes it only completely stopped with V17 MR2 and stayed like that even after revert back to 16.05.8.

    Thanks to you HTTPS decrypt and scan rule for office365 clients is now working smooth and clean.

    changed to top level (did that during troubleshooting), IPS policy is active, Web-App are none and changed service from any to HTTP & HTTPS.

    Thank you again

  • Sorry Michael Dunn my mistake,

    Update it still doesn't work

    I think i tried when the outlooks were already running, today all gives the same behavior, by the way support told me that this is not applicable for office365 and HTTPS traffic should not be decrypted or scanned ........ before i opened this post.

    The same message that appeared with us only on V17.0.2 MR2 and stayed even after revert back to 16.05.8 outlook stop on entering credentials.

     

  • Hi Haytham,
    I suspect there is still a configuration problem.
     
    Can you please post (or DM me) the following:
    Are using transparent mode or direct mode (eg have a proxy explicitly configures in IE)
    Provide a screenshot of the overall firewall rules (especially anything above your specific rule for outlook).
    Provide a screenshot of the specific firewall rule you have for outlook.
    Provide a screenshot of the Destination Network definition (under Host and Networks) that you are using inside that firewall rule.
     
    Can you also go to Log Viewer (top right corner),
    Reproduce the error.  In the Log Viewer tab, switch to viewing the Web Filter log.  Add a filter for Source IP to the device.  Copy any logs from the relevant time period.
    Now go to the Policy Test tab.
    Put in the https://outlook.office365.com and make sure you are doing Test Firewall Policy with the source IP and Auto-Detection.
    Screenshot (or copy paste) the results.
     
    Go into the command line Device Console (this is not SSH).  What are the results of
    system application_classification microapp-discovery show