24-Mar-2020 17:08 - edited 16-Jun-2022 11:56
As we shift to a much larger remote workforce than ever before, additional strains are being placed on the remote access infrastructure of many organizations around the world.
Over the past several weeks we have seen organizations adapt quickly, and as it relates to APM, implement split tunneling configurations to specifically allow Office 365 traffic to egress a client's local interface instead of the corporate network via the VPN tunnel. Microsoft publishes their Office 365 endpoints (URLs & IPs) via an API but occasionally they make changes and keeping on top of those changes can be an administrative nightmare.
To make the ongoing maintenance of the Network Access Lists / split tunneling configuration as seamless as possible, I’ve adapted a Python script (see GitHubRepo) we commonly use for SSL Orchestrator deployments to fetch Office 365 endpoints and update one or more Network Access Lists. Used in conjunction with iCall, this script will periodically check for and apply updates to your Network Access List(s) without any administrative intervention, allowing you to focus on other mission critical tasks.
The script is maintained and documented in this GitHub repository: https://github.com/f5regan/o365-apm-split-tunnel
Microsoft has provided us with a statement concerning their recommendations for Office 365 and split tunneling:
"Microsoft recommends excluding traffic destined to key Office 365 services from the scope of VPN connection by configuring split tunneling using published IPv4 and IPv6 address ranges. For best performance and most efficient use of VPN capacity, traffic to these dedicated IP address ranges associated with Office 365 Exchange Online, SharePoint Online and Microsoft Teams (referred to as Optimize category in Microsoft documentation) should be routed directly, outside of the VPN tunnel. Please refer to Microsoft guidance for more detailed information about this recommendation."
Microsoft’s recommendations have been incorporated into the script published in the aforementioned GitHub repository. See the changelog for details.
In addition to considering how the steps in this article may relieve some strain on your organization’s remote access infrastructure, I’d highly recommend visiting How to optimize SSL VPN connections when BIG-IP is reaching 100% CPU for further guidance on optimizing SSL VPN connections.
Great job Regan - I have translated this into an iApp which installs the script and creates an iCall to update daily at https://devcentral.f5.com/s/articles/SSL-VPN-Tunnel-and-Office-365
I am looking for a similar functionality (retrieve MS IP and subnet list), but instead of updating the APM network access list, I want it to automatically update an LTM IP data-group. Any idea where I might find such a thing?
I'm not aware of a published list of IPs used for Windows Update but Microsoft has published a list of Windows Update URLs here: https://docs.microsoft.com/en-us/windows/deployment/update/windows-update-troubleshooting#device-can...
You would have to verify with Microsoft whether these URLs are subject to change but assuming it is fairly static list you could simply add these addresses to the "additional_urls" list in the script.
Thanks very much I have been playing around on my testbed. One thing I have noticed is I need to apply the Access policy after the update is working. maybe I have missed something(probably 😉 ) but is there another step I need to take o make sure this is applied to the Network Access List automatically ?
Cheers and thanks again
The Access policies/profiles defined in the "access_profiles" list (line 40) should be applied (on or around line 386) when the script is executed. If you have them defined but they aren't applying, make sure you don't have a typo in the name.
The access policy and NA is being updated ok but I still need to "Apply" the access policy so it won't take effect until this is done is all.. Just needs my manual intervention.
Also, adding the URLs to the script includes them in the DNS exclusion. Which is fine as this is the intended functionality of the script but in my case this would likely mean the routing table on the client could potentially be very long as a result.. I believe each entry from the DNS Exclusion list is resolved and then added in as a host route.
I'm not actually sure Microsoft has an endpoint specifically of windows update like it seems they do for O365.
Thanks very much for your replies too. This script in any event is great and much appreciated.
Great solution !
Any plan to extend it to other collaboration services like Webex and Zoom ?
Great! Anyone has suggestion on how to make the connections via proxyservers?
@ReganAnderson The PDF seems to be corrupt and does not open after downloading. Can you re-upload the file?
@_johnloi Thanks for bringing this to my attention! I've re-uploaded the PDF and the link should be working now.
Brilliant work @ReganAnderson !!
IMO it's worth noting that a more "off the shelve" but less flexible approach (dynamic address spaces) has been introduced with v16 which pulls the full O365 endpoint list (not just the "optimize" category) from what I understand
Which brings me to my question: What's the best practice as far as O365 tunnel exclusions go - offload all O365 hosts or just the "optimize" ones?
Couple videos on this topic:
VPN Split Tunneling: The Benefits and Risks
@PSilva Thanks for sharing, well presented, I fully agree, always sign your work 🙂
I understand F5 is not giving MS-product specific recommendations, which is completely valid of course.
However, pardon my stubbornness, let me rephrase the question on the otherwise wonderful address space improvement in v16:
MS' recommendation seems to be to only exclude O365 endpoints used for real-time or high-volume traffic, which are the ones categorized as "optimize" on their JSON .
So what's the rationale for F5 to exclude all hosts instead?
It's not ideal from my perspective, e.g. since login.microsoftonline.com is also hit directly by clients in that case, which means MS authentication-wise sees a non-corp IP from our VPN clients and thus considers them "off network" which has implications on conditional access.
On a more general layer, as you indicate on youtube, there's a risk to excluding hosts from the tunnel. So we'd prefer to avoid excluding more than absolutely necessary.
On our end we're planning to address this manually by pointing our APMs to an internal server where we cache the O365 endpoint list and modify the content (e.g. using jq) to take out any non-"optimize" categories.
And we'll likely do similar customizations by abusing the "zoom" template to cover some of the other applications we're excluding from VPN. Not ideal, but still WAY better than keeping exclusions up to date by hand.
Hi @sh00b. Apologies for the delay. I'll need to ask PM/PD as to the rational. In the meantime, I did find a few articles about the set up for O365 but based on your response, you may have reviewed these already.
Please shout when there's news from PM
Here's how we might work around it using python for the time being 🙂
import requests import json # Fetch the data from the web service response = requests.get("https://endpoints.office.com/endpoints/worldwide?clientrequestid=b10c5ed1-bad1-445f-b386-b919946339a7") # Parse the JSON data data = json.loads(response.text) # Create an empty list to hold the Optimize entries optimize_entries =  # Iterate over the entries in the data for entry in data: # Check if the entry is categorized as "Optimize" if entry["category"] == "Optimize": # Add the entry to the list optimize_entries.append(entry) # Convert the list of entries to JSON optimize_json = json.dumps(optimize_entries) # Print the JSON data print(optimize_json)