SSL VPN Split Tunneling and Office 365
Optimizing Office 365 traffic on Remote Access through VPNs when using BIG-IP APM.pdf
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.
More Resources
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.
EmployeeEmployee19 Comments
Mikael_Lindelö1Nimbostratus
Great! Anyone has suggestion on how to make the connections via proxyservers?
Matias1this is awesome! but i need to make the connections through a proxy as well :(
_johnloiReganAnderson The PDF seems to be corrupt and does not open after downloading. Can you re-upload the file?
ReganAnderson_johnloi Thanks for bringing this to my attention! I've re-uploaded the PDF and the link should be working now.
sh00bBrilliant 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
https://techdocs.f5.com/en-us/bigip-16-1-0/big-ip-access-policy-manager-network-access/configuring-address-spaces/what-is-address-space.html
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:
- sh00b
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.
Not sure if any of those help your situation and I'll ask about the reasoning.Thanks for the note!!ps- sh00b
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)
