Always On VPN Force Tunneling with Office 365 Exclusions

Always On VPN Force Tunneling with Office 365 ExclusionsWith 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.

Additional Information

Windows 10 Always On VPN Split vs. Force Tunneling

Windows 10 Always On VPN Routing Configuration

Windows 10 Always On VPN Lockdown Mode

Leave a comment


  1. victor bassey

     /  April 14, 2020

    Great 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.

    • The 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.

  2. Jeff Jarratt

     /  May 21, 2020

    Great 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.

    • I 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.

  3. Jamie Thatcher

     /  July 7, 2020

    Great 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?

    • I’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, 2020

        does this split tunnel apply also on lockdown mode?

      • I’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.

  4. David

     /  September 18, 2020

    Richard 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.

  5. Ben

     /  September 24, 2020

    Hi 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?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: