One of the requirements for properly integrating with Microsoft Office 365 is to ensure that your clients and (in some instances such as hybrid Exchange) servers have access to all of the proper endpoints. To achieve this, most customers simply allow their clients internet access and there is no outbound restrictions put in place that would prevent access to the services.
However, there are some customers that want to only allow access to a minimal amount of endpoints on the Internet and have an outbound proxy device that is in place to ensure that they can control this closely. This control can be done in one of two ways:
- A customer could use IP address filtering which will only allow their internal client machines access to the specific endpoint they specify.
- They can also use URL based filtering which allows customers to control access by only allowing access to specific URL’s.
Many customers ask, “What are the challenges involved with IP vs. URL filtering? Which option is best for me? Is there a recommended option?”
Keeping up with changes is the first challenge customers may face. The IP addresses and URL’s that are used in the service are mentioned here and if configured today, could change at any time. We do have an RSS feed for this page to try to alert customers of changes and we do try to prevent IP address changes by using larger IP ranges, but in the end there are still times when we have additional datacenters come online or other factors that lead to more IP addresses than is on the list.
Somefeatures will simply not work is the second challenge (such as OWA for customers that decide to use IP addresses as the mechanism for preventing outbound connectivity instead of URL based blocking). The reason behind this is documented here; some of the IP addresses we Use are dynamic and could change without notice for non-secure traffic. Things such as images for OWA are retrieved from third party content delivery networks (a.k.a. CDN) outside of the Microsoft controlled IP address space to improve performance.
Here is the “important” snip from the above mentioned article:
“Microsoft Office 365 relies on third-party content caching engines to achieve good performance and response times. The types of content cached with these third parties are non-SSL resources, such as the images downloaded to draw the Outlook Web App user interface. As stated above, it's possible and supported to use IP-based filtering for the SSL content downloaded from Office 365 and for the Office 365 end-points that make in-bound calls to an on-premises environment. However, it isn’t possible or supported to use IP-based filtering for the non-SSL resources hosted on third-party content caching engines. To express filtering rules that allow those non-SSL resources to be downloaded to clients on your intranet, you need to use hostname-based filtering (as opposed to IP-based filtering). This is because the IPs used by the third-party content caching engines change frequently in a manner which makes it impractical to track each individual IP change. Allow the following hostnames for these non-SSL resources:
r3.res.outlook.com
r4.res.outlook.com
prod.msocdn.com”
You may ask if URL based filtering requires no upkeep and will continue to work after you initially configure it.
The answer is no, not 100% anyway. There will still be times when URL’s for the service could change and changes will be reflected in the articles mentioned above. However, the frequency of the changes is dramatically decreased when URL filtering is used.
Often a customer will choose IP based filtering not because it is easier, but instead because their outbound proxy device cannot do URL based filtering. While this may be true for many older devices, we have seen many times where the application of a software update to your device may allow for URL based filtering functionality. URL based filtering is becoming more prevalent and most devices do give you the opportunity to adapt to this style of filtering.
Some features may not work depending on where users are physically situated is the third major challenge. In some situations we have seen customers attempt to allow only the IP addresses of only Office 365 geographical region datacenters they signed up in. For example, a North American Office 365 customer’s IT staff may attempt to allow only the North American datacenter IP ranges by watching what IP addresses their clients are connecting to then removing the IP ranges they do not see being accessed from the allowed IP list. At first, this may appear to work until (hypothetically speaking) you get a call from your CEO on business travel to Europe asking if Office 365 is down because they cannot access any of the services. Let’s first talk about why this may happen.
Microsoft utilizes geographically aware DNS (aka Geo-DNS) to respond to incoming DNS queries. Microsoft DNS servers first compare the IP address of an incoming request from the querying device against a database of industry standardized IP ranges and what regions of the planet they reside in. Microsoft DNS servers will then issue a DNS response back to the querying device that will be the closest physical entry point to the Office 365 services in the identified IP region. For example a traveling North American Office 365 customer in Europe will be given a European Office 365 entry point. This will prevent the user’s network traffic from having to travel long distances across the public Internet before reaching the desired services. Using Geo-DNS we get the user’s network traffic into the closest Microsoft datacenter and then pass their network traffic across our low latency global private network back to the user’s home datacenter region. This allows Microsoft to provide the best user experience possible for all regions of the planet by reducing dependencies on the public Internet where possible.
So back to our CEO example. The CEO may be in a European hotel on business using the hotel Wi-Fi with a company laptop to do some work. The DNS response they get back for outlook.office365.com will point them at European datacenter. Due to the fact you have only allowed the IP ranges of the North American datacenters, the user is unable to connect to services. You may think forcing the laptop to always utilize corporate DNS servers would help here. Remember that by going down that path you would be forcing the client to traverse the public Internet to reach the North American datacenter and not be able to take advantage of Microsoft’s low latency private network between its datacenters, thus giving your user a less optimal experience.
What is the best or recommended option is based on the challenges outlined above. Microsoft would like to see all customers use URL based filtering to overcome those challenges. URL based filtering will provide you with the fewest number of changes over time, prevent unwanted situations when some content may be unreachable due to changes at the third-party CDNs level, and allow users outside of their home region to always access the most appropriate datacenter for their client connectivity.
Thanks to Brian Day and Joshua Maher for review / comments on this post.