SSL VPN Split Tunneling and Office 365
UPDATE: Apr 9, 2020 A colleague, Vinicius M. , put together a Configuration guide:
Optimizing Office 365 traffic on Remote Access through VPNs when using BIG-IP APM.pdf
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.
Updated Jun 16, 2022
Version 2.0
ReganAnderson
Employee
EmployeeReganAndersonEmployee
Employee
PeteWhiteGreat 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
sh00bNimbostratus
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
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- Dan_Pacheco
Cirrus
Hiya,
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?
Thanks,
- PeteWhiteDead simple - I’ll take a look at changing this script to update a datagroup Regards Peter White T: 07785 456991
SmithyCirrostratus
you can find that here: https://github.com/f5devcentral/f5-office365-ip-url-automation
GeoffGAltostratus
Very useful and really well done.
Was wondering if there was something similar for Microsoft windows Updates along the same lines?
Cheer and thanks for the share
ReganAndersonI'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-cannot-access-update-files
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.
