In a recent post, I described how to configure routing for Windows 10 Always On VPN clients. In that article, I shared guidance for disabling the class-based default route in favor of defining specific routes for the VPN client. While this is easy enough to do when you use custom XML (deployed via PowerShell, SCCM, or Intune), there is a known limitation when using the native Intune UI that could present some challenges.
Intune VPN Profile Configuration
Defining specific routes is easy to do in Intune using the native VPN configuration profile. In the Configuration settings expand Split Tunneling and click Enable. The administrator can then add routes by entering their Destination prefix and Prefix size, as shown here.
Class-Based Default Route
The limitation with using Intune to configure routes is that there is currently no option to disable the class-based default route as there is with custom XML. This means the routes shown in the example above will be added to the client, but the class-based route will also be added automatically, as shown here (class-based default route highlighted with the arrow).
Considerations
In most cases, the inclusion of the class-based default route along with the administrator-defined routes will not be a problem. However, in some scenarios, it could yield unexpected results. Specifically, Always On VPN clients may have unintended access to some networks over the VPN tunnel. This is most significant for the Always On VPN device tunnel, where it is common to limit access to only specific resources using individual host routes.
Workaround
Today there is no option to disable the class-based default route using the native Intune UI. Your only option is to deploy the Always On VPN profile using custom XML, as described here.
Additional Information
Deploying Windows 10 Always On VPN with Intune and Custom XML
Deploying Windows 10 Always On VPN Device Tunnel with Intune and Custom XML
Windows 10 Always On VPN Routing Configuration
Windows 10 Always On VPN Device Tunnel Operation and Best Practices
j03oe
/ March 4, 2021Richard, thank you for your post. I’m still experimenting with pushing the User and Device Tunnels out via Intune. I also don’t fully understand the capabilities of OMA-URIs. Would it be possible to use the default Intune VPN Device Tunnel template and then push a separate custom configuration profile that just changes the DisableClassBasedDefaultRoute setting? Using the Custom profile template works fine, but I seem to have issues with making changes to it and those changes being propogated down to the device. Unless the OMA-URI of the custom profile is exactly the same, I end up with a lot of orphaned connections on client devices. Also, remove devices from a Group assigned to a custom template does not seem to remove the connection from that device..
Richard M. Hicks
/ March 4, 2021Indeed, using custom XML with Intune is not without its own limitations. Typically if you make a change to XML those changes will be updated on your clients. I have heard reports that if you remove the profile that it doesn’t get removed from the client though. It might be possible to use the native Intune UI to deploy the profile, then use a follow-up script to subsequently remove the class-based route. It’s not something I’ve tried but will test as soon as I can.
Paul
/ April 12, 2021Hi Richard, I’d be very interested to know the results of your testing as we’re in a similar position of having profiles deployed via InTune but wanting to run a follow-up script to disable the class based route (at least on the device tunnel).
Richard M. Hicks
/ April 14, 2021I haven’t yet tested this, but you should be able to do this. You’ll have to edit the entry in rasphone.pbk to affect this change, however. You’ll need to change the value of DisableClassBasedDefaultRoute to ‘1’. I’ll update my Update-Rasphone.ps1 script to include this option soon.