Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 4 replies
  • Subscribers 39 subscribers
  • Views 5992 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

How to handle Office 365 network traffic separation in Sophos XG?

layer9

Dear all,

we are currently not using a Sophos product for Internet access (neither as proxy nor as the outgoing gateway) but are looking into Sophos XG to replace our current proxy (Microsoft TMG 2010) with it. In preparation of implementing the Sophos XG I would like to know about features in the product in order to make sure the configuration for Internet access can be aligned with the Office 365 Network Principles. Please see below for further information on the topic.

We are currently moving our roughly 700 users from Office 2010 & Exchange 2010 to Office 365 and Exchange Online and so far everything works quite well. Regarding handling of Office 365 network traffic we have read the Office 365 Network Principles from Microsoft:
 
  docs.microsoft.com/.../office-365-network-connectivity-principles
 
Usually all our clients can only access the Internet using a proxy server that is explicitely configured in the OS by GPO. Traffic that not traverses the proxy server is usually blocked and needs to be explicitly allowed on our outbound router.
 
Following the guidlines to seperate traffic destined for Office 365 we have deployed proxy settings to our clients that exclude traffic for all Office 365 destinations from the "Optimized Category" (i.e. *.sharepoint.com; outlook.office365.com etc.) so that traffic to those targets is routed directly (as recommended by Microsoft). Traffic to those endpoints is allowed as per the Office 365 URLs and IP address ranges:
 
docs.microsoft.com/.../urls-and-ip-address-ranges
 
We are using a script that reads the corresponding IP addresses from the Office 365 IP Address and URL web service to update the firewall rules on the outbound router.
 
So basically the concept is:
 
1. Traffic to Office 365 endpoints from the Optimize category is routed directly
2. All other http/https traffic is traversing the explicitly configured proxy server
 
We now have experienced connectivity issues with Outlook and found that some of the IP addresses that Outlook is connecting to are not listed in the Office 365 URLs and IP address ranges. For example, when resolving outlook.office365.com the DNS returns addresses that are not included in the list but Outlook is connecting to. I have posted the issue this along with a more detailed description on the Github site as feedback for the Office 365 URLs and IP address ranges website:
 
  github.com/.../543
 
Others have posted about similar issues as well. As we obviously cannot rely on the Office 365 URLs and IP address ranges (since not all addresses are included) we have now allowed all outbound https traffic on our outbound router. The Outlook connectivity issues are solved now, but all clients now have direct outbound https access to the whole Internet which could pose a security risk if a user removes the GPO configured proxy and uses the direct outbound access for other traffic as well.

The problem could theoretically be solved if we use the explicitly configured proxy for all Office 365 traffic as well. In this case, DNS resolution is done at the proxy. If the proxy allows all outgoing connections to a particular URL like https://outlook.office365.com/ then the IP addresses don't matter anymore since the proxy can allow access solely based on the URL which it receives from the client. Using a proxy for Office 365 traffic however does not align with the recommendations by Microsoft and can lead to usability issues and performance problems.

In addition to that all our clients are dual stacked and have both IPv6 GUA and private IPV4 addresses. Besides following the recommendations from Microsoft for avoiding proxy services we also would prefer using IPv6 point to point connections between our clients and the Office 365 servers. 

Does Sophos XG come with any features to provide this functionality even under the condition that the endpoints included in the Office 365 IP Address and URL web service from Microsoft are NOT complete? If the list from Microsoft WOULD be complete it of course would work as follows:

a) We are using an explicitly configured proxy for normal web traffic
b) We exclude Office 365 URLs from the client configuration
c) Clients would resolve those Office 365 URLs in DNS by themselves
d) Traffic to the resolved IP addresses is routed directly to the Sophos XG which also acts as transparent proxy
e) Sophos XG is aware of the Office 365 IP addresses and excludes this traffic from the proxy service and routes it directly
f) All other traffic is redirected to the proxy service where filtering is applied

However, since the list from Microsoft is NOT complete this will lead to cases in which traffic to Office 365 IP addresses is NOT excluded from the proxy service and therefore filtering is applied (which breaks usability). Or as in our current case: The traffic is completely blocked.

Is it possible to monitor traffic that is routed directly to the Sophos XG on the application layer before it is redirected to the proxy service? Then we maybe could look for the URL in the HTTP headers or TLS client handshake (in case of TLS) within the traffic and decide based on that if we route traffic directly or pass it through the proxy service. Well...but thinking through it I guess this wouldn't even work since we are receiving the information from HTTP headers / TLS handshake only AFTER establishing the initial TCP connection. And we cannot switch the connection between from direct to proxy or otherwise AFTER the TCP handshake has been completed (and this of course would BREAK the connection).

I therefore guess that we have no other options than to configure the XG as explicit proxy for normal web traffic and exclude Office 365 URLs directly on the client and route that traffic directly (with all outgoing https traffic allowed, since IP addresses are not correctly defined). 

Anyway, any thoughts on Office 365 traffic separation with Sophos XG is appreciated.

Thanks
Michael



This thread was automatically locked due to age.
Parents
  • 0

    Hi Michael,

    If the clients were IPV4 only(that list is complete AFAIK), you can create an API script which downloads the list/ parses and creates an API request that updates/creates a rule at the top of the firewall list which is unfiltered for the o365 destinations. Of course you can make a cronjob that periodically runs the script to keep it up to date. 

    I think the same should be possible for IPv6 but I have not looked into it.

    If the list is not complete, things become complicated and there isn't a feature to bypass the proxy completely based on the client hello (exceptions in the proxy still have traffic go through it although it should be 'untouched').

  • 0 in reply to MasterRoshi

    Hi MasterRoshi,

    thanks for your reply. Regarding the first part we have been informed by our Sophos distributor that XG will receive new features in version 18 that allow to bypass traffic for cloud services more easily. I guess this will be a feature that allows to query i.e. the REST service from Microsoft directly so that a self written script is not needed anymore.

    Regarding the exceptions: Isn't is possible to completely bypass the proxy at all or is this just not possible based on the TLS client hello for https traffic (as you have written)? I would imagine that if we use the XG as transparent proxy there should be a at least a ruleset that excludes traffic from the proxy based on layer3/4 information like destination IP.

    For example, let's assume my client sends packets to 100.30.20.1:443. No explicit proxy is configured so the client sends those packets directly to 100.30.20.1. Once the XG receives the first packet it should recognize that traffic to 100.30.20.1 must not be redirected to the proxy but routed directly instead.

    Not being able to bypass the proxy based on TLS client hello for https traffic would make sense indeed since we need the proxy to parse the target hostname from the TLS client hello in the first place. And before we can parse information from the client hello the underlying TCP connection to the destination is already established and cannot be switched afterwards.

    That means we have the following options:

    1. Exclude traffic completely from proxy based on destination IP (which only works if the lists provided by Microsoft are complete)
    2. Process everything by proxy and exclude destinations from proxy processing (SSL, malware etc.) based on hostname in TLS client hello

    Option 2 however still uses the proxy service for outgoing connections which does not align to the recommendations from Microsoft. Also in case of IPv6 we are loosing the ability to make use of point to point connectivity as all outgoing connections to the destination are initiated by the XG's proxy service and not the original client itself.

    Can you confirm that this is correct?

    Thanks,
    Michael

  • +1 in reply to layer9

    Of course you can bypass it based on layer 3 (2,4 as well if using non-standard ports/certain source mac addresses). Just have a firewall rule without web policy enabled for certain destinations above the one that does have it for everything else. 

    1. Yes

    2. Yes

Reply
  • +1 in reply to layer9

    Of course you can bypass it based on layer 3 (2,4 as well if using non-standard ports/certain source mac addresses). Just have a firewall rule without web policy enabled for certain destinations above the one that does have it for everything else. 

    1. Yes

    2. Yes

Children
  • 0 in reply to MasterRoshi

    Hello MasterRoshi

    is it possibile in my case to adapt all the required FQDNs by Microsoft in one XG Firewall rule and activating a BWM (sahred for all destinations but max limitaion of bandwith) to limitate the troughput from LAN to WAN to Microsoft O365 ? In my company is no limitation by GPO set and all hope it would work fine ;( 

    thx forward for your feedback

    Regards
    Chris

     

Unfiltered HTML