With the COVID-19 global pandemic forcing nearly everyone to work from home these days, organizations that implemented force tunneling for their VPN clients are likely encountering unexpected problems. When force tunneling is enabled, all client traffic, including Internet traffic, is routed over the VPN tunnel. This often overloads the VPN infrastructure and causes serious slowdowns, which degrades the user experience and negatively impacts productivity. This is especially challenging because so many productivity applications like Microsoft Office 365 are optimized for Internet accessibility. It is one of the main reasons that force tunneling is not generally recommended.
Force Tunneling with Exceptions
When enabling split tunneling is not an option, administrators frequently ask about enabling force tunneling with some exceptions. The most common configuration is enabling force tunneling while still allowing Office 365 traffic to go outside of the tunnel. While this is something that third-party solutions do easily, it has been a challenge for Always On VPN. Specifically, Always On VPN has no way to route traffic by hostname or Fully-Qualified Domain Name (FQDN).
Exclusion Routes
To address this challenge, the administrator can configure Exclusion Routes. Exclusion Routes are supported in Windows 10 1803 with update KB4493437, Windows 10 1809 with update KB4490481, and Windows 10 1903/1909.
Exclusion routes are defined in the client routing table that are excluded from the VPN tunnel. The real challenge here is determining all the required IP addresses required for Office 365.
Microsoft Published Guidance
Given current events and the heavy demands placed on enterprises supporting exclusively remote workforces, Microsoft has recently published guidance for configuring Always On VPN force tunneling while excluding Office 365 traffic. Their documentation includes all the required IP addresses to configure exclusions for. This will make it much simpler for administrators to configure Always On VPN to support this unique scenario. The following links provide detailed configuration guidance for enabling force tunneling for Always On VPN with exceptions.
- Optimize Office 365 connectivity for remote users using VPN split tunneling
- Optimizing Office 365 traffic for remote workers with the native Windows 10 VPN client
- Implementing VPN split tunneling for Office 365
Additional Information
Windows 10 Always On VPN Split vs. Force Tunneling
victor bassey
/ April 14, 2020Great stuff again. I was looking at this for excluding MS Teams traffic for a client using forced tunnel. Not sure how manageable this would be though as office 365 endpoints and ip address is a lot and can often change. But yes it’s a good option as it will allow my client to enforce a forced tunnel and selectivity excluded routes the want to go out directly.
Richard M. Hicks
/ April 14, 2020The best advice is to avoid force tunneling whenever possible (see split tunneling vs. force tunneling). If you can’t avoid it for some reason, then having the option to exclude some traffic is helpful. The problem with Always On VPN/Windows is that it can only be done by IP. This is where third-party solutions provide a better experience, because they can also exempt traffic by name or FQDN.
Jeff Jarratt
/ May 21, 2020Great information. I am wondering how to go about implementing these exceptions in a forced tunnel scenario while using intune to deploy the VPN profile, rather than the config XML.
Richard M. Hicks
/ May 22, 2020I don’t believe exclusion routes are supported when using the native Intune UI. You’ll have to use custom ProfileXML if you want to enable this feature.
Jamie Thatcher
/ July 7, 2020Great information Richard! Im trying to implement this for Windows updates to allow our force tunnelled clients to access only window updates form the internet. Annoyingly Microsoft dont publish IP Ranges for this. Do you know if there is any way we can exclude certain urls?
Richard M. Hicks
/ July 7, 2020I’m surprised Microsoft doesn’t publish Windows Update IP addresses, and wasn’t aware they didn’t. I don’t know of anything that’s published, and URLs won’t work as Always On VPN would only be able to exclude IP addresses/ranges, not hostnames or FQDNs.
Panos
/ August 27, 2020Hi.
does this split tunnel apply also on lockdown mode?
Richard M. Hicks
/ August 28, 2020I’m not certain to be honest. I typically don’t recommend using lockdown mode as it has some serious limitations. As such, it’s not something I’ve tested myself.
David
/ September 18, 2020Richard Thanks. I am from China and use O365 international version. Sometimes you know we have to use VPN/SDWAN solution withO365, since traffic and performance will be impacted by China greatwall. So I am a little bit concern about doing the exclusion solution.
Richard M. Hicks
/ September 19, 2020This is purely optional. You don’t have to exclude Office 365 traffic if you don’t want or need to.
Ben
/ September 24, 2020Hi Richard,
It might be a bit off topic but I’m having an issue with splittunneling and app triggers for printing.
Problem is the following:
I need to be able to print to our network print server (print01.corporate domain) so no local lan printing.
When using a forced tunnel this works fine, but we run into other issues.
When using a splittunnel with apptriggers for spoolsv.exe procmon shows bad network path.
when using forced tunnel with apptrigger spoolsv.exe this fails as well.
so my conclusion is I’m missing a process in the apptrigger.
do you have any idea which app trigger to use part from spoolsv.exe?
Richard M. Hicks
/ September 24, 2020Is the IP address of the LAN-based printer routed over the VPN tunnel? Not sure why it wouldn’t just work.
Colin
/ November 8, 2020Hi Richard,
Great articles, just a quick question / confirmation please:
I’m aiming to configure a Forced tunnel with web browsing traffic being routed via the on-premises proxy servers via a PAC file.
Is this supported through the use of the following only or are there other considerations/config needed?
http://servername/proxyfile.pac
I’m able to establish a forced user tunnel and RDP/access file shares etc internally but not able to browse the web despite various combos or explicit or PAC file proxy so just looking for some confirmation or guidance. Cheers!
Richard M. Hicks
/ November 9, 2020Yes, that’s supported. You should define the proxy settings in the <Proxy> section of your ProfileXML, or simply enter those values in the Intune UI if you are using that. Be sure to test with all browsers though. I’m hearing reports that only IE/Edge works and Chrome/Firefox might ignore it.
Colin
/ November 9, 2020Thanks, will test.
Paddy Berger
/ December 4, 2020Hi, wanted to confirm a issue I have seen. We are using split tunnelling and also both user and device tunnels, we have notice that outlook (office 365) is slow when opening,sending,etc. Would the exclusions help in this case? have you seen anything similar? If we do this, are the ips added to the route table of the local win 10 laptops?
Richard M. Hicks
/ December 4, 2020If you are using split tunneling there shouldn’t be any need to configure exclusions. They are only required for force tunneling. I’d suspect that something else is causing this delay in your case.
Simon Quist Erichstrup
/ January 21, 2021Sorry. Found it in the second article you link to 🙂
8.8.4.4
32
true
But how odd is it that the article I linked in my prior comment states it is only for SplitTunnel…. Typo?
Richard M. Hicks
/ January 21, 2021Exclusion routes are only used when force tunneling is enabled. Is that what you’re asking?
Bstan
/ June 15, 2021Hey Richard, I’ve been looking across the internet about how to implement this exact solution. Do you have any information on exactly how to implement this?
Richard M. Hicks
/ June 17, 2021How are you provisioning Always On VPN profiles to your clients? Microsoft Endpoint Manager? SCCM? Something else?
Richard M. Hicks
/ June 17, 2021I would suggest using my Get-VpnClientProfileXML.ps1 script to look at the XML as it is configured on your device. You should see the trusted network detection section in the export. Make sure it is there and that there aren’t any typos.
https://github.com/richardhicks/aovpn/blob/master/Get-VPNClientProfileXML.ps1
Let me know what you find!
Brett Stanavich
/ June 18, 2021Thank you Richard. I will take a look at the script. I’m not 100% sure what type of VPN profiles we have. I’m assuming user tunnels. We have a forced tunnel and I’m hoping to add some exclusion routes. From what I know we don’t deploy any VPN profiles remotely using a script but if we did it would be through connectwise which can be found here: https://www.connectwise.com/platform/unified-management
Adding the exclusion routes to the XML is very simple… So, I’m hoping that once I export the VPN profile I can modify the XML and then run a script to recreate a new VPN profile with the desired exclusion routes.
Richard M. Hicks
/ June 18, 2021Just to be clear, you can’t just export the XML from a standard VPN profile and deploy it as an Always On VPN tunnel. There are a number of settings unique to an Always On VPN profile that are not included in the XML for a regular VPN connection. I’d suggest downloading my sample Always On VPN XML file as a starting point. You can then modify as you need.
https://github.com/richardhicks/aovpn/blob/master/ProfileXML_User.xml
aibulat
/ September 29, 2021Great post! Thank you, Richard! I have a question on Force-Tunneling with certain exclusions.
Exclusions works great — and I can see them in the routing table. But also, we need users to be able to use their local DNS to resolve names corresponding to the exclusions. The Office 365 FQDNs — can be a good example. We need this because of content-localization and geo-dns(gslb) usage on those destination (excluded) services. Central DNS in Office/VPN breaks geo-dns…
The problem is that — we don’t know which DNS users would be using. And we cannot use something standard like 8.8.8.8 — it might be blocked in their locations.
If DNS is in same subnet — it just works, of course. If it is a separate subnet — it is not reachable while using Forced VPN tunnel. It can be easily fixed by adding a route. But, as said, that route has “dynamic variables”: the dns and the gateway.
Are you aware of any method by which VPN client could dynamically add the required route, before (or, just after) making connection?
Like: route add
Where, those “variables” are received from DHCP…
Richard M. Hicks
/ September 30, 2021I’m not aware of any way to do this using Always On VPN with force tunnel. This is one of the main reasons we recommend avoiding force tunneling. There are just too many scenarios where force tunneling breaks essential functionality. If you have to use force tunneling, you’ll have to accept these limitations, unfortunately.