During the planning phase of a Windows 10 Always On VPN implementation the administrator must decide between two tunneling options for VPN client traffic – split tunneling or force tunneling. When split tunneling is configured, only traffic for the on-premises network is routed over the VPN tunnel. Everything else is sent directly to the Internet. With force tunneling, all client traffic, including Internet traffic, is routed over the VPN tunnel. There’s been much discussion recently on this topic, and this article serves to outline the advantages and disadvantages for both tunneling methods.
Force Tunneling
Force tunneling is typically enabled to meet the following requirements.
Visibility and Control
By routing all the client’s Internet traffic over the VPN tunnel, administrators can inspect, filter, and log Internet traffic using existing on-premises security solutions such as web proxies, content filters, or Next Generation Firewalls (NGFW).
Privacy
Enabling force tunneling ensures privacy and protection of all Internet communication. By routing all Internet traffic over the VPN, administrators can be certain that all communication from the Always On VPN client is encrypted, even when clients access unencrypted web sites or use untrusted or insecure wireless networks.
Force Tunneling Drawbacks
While configuring force tunneling for Always On VPN has some advantages, it comes with some serious limitations as well.
Poor User Experience
User experience is often degraded when all Internet traffic is routed over the VPN. These suboptimal network paths increase latency, and VPN encapsulation and encryption overhead increase fragmentation, leading to reduced throughput. Most Internet traffic is already encrypted in some form, and encrypting traffic that is already encrypted makes the problem even worse. In addition, force tunneling short-circuits geographic-based Content Delivery Networks (CDNs) further reducing Internet performance. Further, location-based services are often broken which can lead to improper default language selection or inaccurate web search results.
Increased Resource Consumption
Additional resources may need to be provisioned to support force tunneling. With corporate and Internet traffic coming over the VPN, more CPU, memory, and network resources may be required. Deploying additional VPN servers and higher throughput load balancers to support the increase in network traffic may also be necessary. Force tunneling also places higher demands on Internet Service Provider (ISP) links to the corporate datacenter.
Split Tunneling
The alternative to force tunneling is “split tunneling”. With split tunneling configured, only traffic destined for the internal corporate network is routed over the VPN. All other traffic is sent directly to the Internet. Administrators define IP networks that should be routed over the VPN, and those networks are added to the routing table on the VPN client.
Security Enforcement
The challenge of providing visibility and control of Internet traffic with split tunneling enabled can be met using a variety of third-party security solutions. Microsoft Defender ATP recently introduced support for web content filtering. Also, there are numerous cloud-based security offerings from many vendors that allow administrators to monitor and control client-based Internet traffic. Zscaler and Cisco Umbrella are two popular solutions, and no doubt there are many more to choose from.
Recommendations
The general guidance I provide customers is to use split tunneling whenever possible, as it provides the best user experience and reduces demands on existing on-premises infrastructure. Enabling split or force tunneling is ultimately a design decision that must be made during the planning phase of an Always On VPN implementation project. Both configurations are supported, and they each have their merits.
In today’s world, with many applications accessible via public interfaces, force tunneling is an antiquated method for providing visibility and control for managed devices in the field. If required, investigate the use of Microsoft or other third-party solutions that enforce security policy in place without the requirement to backhaul client Internet traffic to the datacenter over VPN for inspection, logging, and filtering.
Additional Information
Whitepaper: Enhancing VPN Performance at Microsoft
Whitepaper: How Microsoft Is Keeping Its Remote Workforce Connected
Patrick
/ April 14, 2020Hello,
It is important to consider local traffic and not just Internet traffic. To date Always On does not manage the restriction of flows on the local network of the user and this is really a shame. Only LockDown mode allows you to restrict all flows in the VPN tunnel which is really recommended in a highly secure context
Richard M. Hicks
/ April 14, 2020Good point. 🙂
IT-Connect
/ May 25, 2020Hi Richard,
Thank you for this article. I think that Windows 10 Always On VPN is a good solution to secure remote access.
Regards,
Florian
James Hawksworth
/ May 26, 2020My org is (unfortunately) keen for me to set up Always On with Force Tunnel, so it’s really useful that we can now add O365 exceptions. Would dual NIC not be a hinderance with force tunnel though as you’d need endless static routes to override the default gateway? I’m sure I’m overthinking this…
Richard M. Hicks
/ May 27, 2020If you plan to use force tunnel I’d suggest moving to a single-NIC configuration on your VPN server to eliminate these issues. The alternative is to ensure that your VPN server has access to the public Internet and that all firewalls/gateways upstream allow traffic from the VPN client subnet.
Charlee Ult
/ September 12, 2021Hi James
Can you share your method of configuring force tunneling, are you hosting a VPN server on prem or on azure. Would be great if you could
Share your VPN design.
Thanks
James Hawksworth
/ May 6, 2022Apologies, I’ve only just seen this, must have missed the email.
We’re hosting on-prem, load balancing between 3 servers, but have since switched to Split Tunnel now we have a solution that supports client-based web filtering.
Richard M. Hicks
/ May 6, 2022Good choice. That’s a much better solution. 🙂
Justin
/ June 25, 2020Thanks Richard, this was very informative! I have just implemented an AOVPN with Azure VWAN P2S VPN and was forced to go for split tunneling. So far so good will let you know how it goes. Only limitation that keeps tripping me up with split tunneling is whitelisting the Public IP with 3rd parties & allowing access to internal resources based on the same. Otherwise, Split tunneling works well and keeps the users happy!
Richard M. Hicks
/ June 29, 2020Great to hear! How is the throughput with Azure Virtual WAN?
Maciej
/ July 2, 2020Hi Richard amazing blog. I have deployed Device tunnel with your help :_)
Now i’ve this problem. We would like to use DeviceTunnel in split mode so our device can be managed by SCCM and other services. After Device is established and user logs on i would like to be able connect with an another 3rd party VPN where user will have access to fileservers and another resources dedicated to him/her
Regards.
Maciej
Richard M. Hicks
/ July 7, 2020Do you want to use another VPN separately? Or do you want the VPN to access resources over the device tunnel VPN connection?
Maciej
/ July 7, 2020I would like to use separately 3rd party VPN (Fortinet to be precise) for user access when computer is connected using DeviceTunnel to the DC and SCCM servers. (using split tunnel or even force tunnel)
Have you tried this kind of setup. ?
Richard M. Hicks
/ July 10, 2020I’ve not implement device tunnel using Fortigate before. It might be possible, just not something I’ve done myself.
aventador06
/ September 12, 2020Hi Richard,
We are finally deploying AOVPN to a test population and, of course, some questions have emerged that wasn’t answered when we asked them in June/July when we studied the infrastructure.
We’ve decided to deploy split-tunnel device AOVPN with a single route to access all of internal resources. The WAN and LAN security is then handled by Cisco ASA and FirePower.
Now, we have the following problem:
Some providers have public websites that are not displaying the same page when coming from the LAN or from a public IP address.
How can we force this traffic to go through the VPN and exit through the Internet access of our LAN?
What is the best practice in this situation?
Thanks
Richard M. Hicks
/ September 15, 2020If you want to route a public web site over the VPN, you would simply add their public IP addresses to your VPN client routing table to point it over the VPN.
bueschu
/ December 1, 2021I’m testing force tunneling for a client, which already has an AoV deployment with user tunnel in split tunneling mode, which works perfect
If I configure force tunneling the VPN get’s not autotriggerd, I have to start It manually and then it connects. Is this by design?
I’ve used the same profile as for the split mode, changed the RoutingPolicyType and deleted all de route entries and the trustednetwork detection is still in place.
Richard M. Hicks
/ December 2, 2021No, definitely not. The Always On VPN profile should establish a connection automatically regardless of the tunneling configuration. Make sure your VPN profile isn’t listed in the following registry key.
HKLM\SYSTEM\CurrentControlSet\Services\RasMan\Config\AutoTriggerDisabledProfilesList
If it is, remove it and try it again. 🙂
bueschu
/ December 5, 2021After deleting the other VPN-Profile it seems to work. Many thanks for your help und your fantastic blog.
ME
/ April 28, 2022Thanks for the suggestion Richard. I too have encountered this same issue and noticed that even on a machine which has been freshly built that we don’t necessarily get auto-connect. I understand from an existing machine that may’ve had a previous profile that the key would be relevant.
So in that specific reg key you’ve mentioned is the old profile name, the new profile is listed in the registry directory under the “AutoTriggerProfileEntryName” key. Intermittently it behaves and auto connects without intervention. But I’ve noticed a few different latops where if you disconnect it using the Wi-Fi console it either does reconnect/or doesn’t. Then if you disconnect it using rasphone.exe (either using the executable or via command prompt then it doesn’t auto reconnect at all)?
I hadn’t seen any of these issues with the split tunnel design where the ‘auto connect’ button is available within the Wi-Fi menu.
Richard M. Hicks
/ April 28, 2022Interesting. I wouldn’t expect the behavior to change based on tunneling mode. Odd, for sure. I can tell you, though, that proactively disconnecting an ‘always on’ connection like this does lead to unexpected behavior. Usually clearing the registry key resolves things. However, you still have to go back and check the ‘connect automatically’ box in the UI to restore the automatic connection.
ME
/ May 3, 2022I too, wasn’t expecting any difference. However, further testing on a few different devices (including one that never had a VPN profile) has confirmed if you have it set to ‘force tunnel’ rather than split tunnel (this is still user based) – that if you disconnect using rasphone.exe or via rasdial through CMD it breaks the auto connect. Attempting to disconnect it via the Wi-Fi menu UI or via ‘VPN’ within the W10 Settings menu, it auto connects without any issue.
The difficulty with clearing the registry keys & ensuring the ‘check box’ is still set is that within force tunnel mode the auto connect box disappears from the UI so the user has no way of using this to establish the right registry keys if they don’t already exist.
I assume, by design that the force tunnel purposefully removes the ‘connect automatically’ box to prevent a user disconnection but it seems this particular scenario has uncovered issues with retaining auto-connectivity. The chances of a user accessing rasphone or using the rasdial command are very slim but I suppose it’s not an impossibility?
Richard M. Hicks
/ May 5, 2022True. It’s not likely an end-user will use rasphone.exe or rasdial.exe. It’s certainly odd that the behavior is different for split vs. force tunnel though.
Alex
/ January 3, 2023Hi there, we set up always on vpn for some time for some users to test.
Device Tunnel is configured split tunneling, user tunnel is forced tunneling. So far so good. Everything works fine and fast.
Now we faced two behaviors:
1. i have set up a pihole in my private LAN and during the connected user tunnel the pihole blocks ads from websites and shows my company device in the query log. I thought this cant be happen with force tunneling. all traffic should go through the tunnel?! ipconfig shows our two correct dns servers and not the pihole (it is configured in my router to provide to all devices)
2. ive got a new isp from cable to fiber with active Dual Stack Lite. I faced errors when connecting the exchange servers and low speedtests. After switching to dual stack (non lite) everything works fine and fast but i think many people could get this behavior when we go online for 12.000 users. In germany the isp often works with dual stack lite. We dont use ipv6 and we use IKEv2.
Do you have any experiences with that?
Thanks and best regards
Alex
Richard M. Hicks
/ January 3, 2023The first behavior is expected. Windows sends DNS queries to the first DNS server listed on ALL active network adapters in parallel. The second behavior is unusual. I’m not aware of any issues with VPN and DS-Lite. However, it’s possible that the encapsulation process is causing problems for IKEv2. Ensure that you have IKEv2 fragmentation support enabled on the VPN server (Windows RRAS requires a registry setting, other vendors I’m not sure about). Also, it would be interesting to see if you have the same performance issues using SSTP.