Always On VPN Routing Configuration

Windows 10 Always On VPN Routing ConfigurationWhen configuring Windows 10 Always On VPN, the administrator must choose between force tunneling and split tunneling. When force tunneling is used, all network traffic from the VPN client is routed over the VPN tunnel. When split tunneling is used, the VPN client must be configured with the necessary IP routes to establish remote network connectivity to on-premises resources. How those routes are established is a common source of confusion. This article provides guidance for properly configuring routing for Always On VPN clients.

Class Based Routing

IP addresses are assigned to Windows 10 Always On VPN clients from either a static pool of addresses configured by the administrator or by DHCP. If split tunneling is enabled, the client will also be assigned a class-based route that is derived from the IP address assigned to it by the VPN server, by default. If the client is assigned an IP address from the Class A network, a corresponding /8 prefix is used. For Class B networks a /16 prefix is defined, and for Class C networks a /24 prefix is used.

As an example, if the VPN server assigns the client an IP address of 10.21.12.103, a route to the 10.0.0.0/8 network is added to the client’s routing table, as shown here.

Windows 10 Always On VPN Routing Configuration

Complex Networks

This default class-based route is of limited use though, and is only applicable when the internal network is simple and VPN clients are assigned IP addresses from the same subnet class. In the example above, if the entire internal network resides in the 10.0.0.0/8 Class A address space, all resources will be reachable by the VPN client. Any resources in the Class B or Class C subnet ranges would be unreachable without additional configuration.

Route Configuration

To configure routing for Windows 10 Always On VPN clients, first disable the default class-based route by defining the following element in ProfileXML as shown here.

<VPNProfile>
   <NativeProfile>
      <DisableClassBasedDefaultRoute>true</DisableClassBasedDefaultRoute>
   </NativeProfile>
</VPNProfile>

Next, enable specific routes as needed by defining the following element(s) in ProfileXML. The example below defines routes for all private RFC 1918 networks.

<VPNProfile>
   <Route>
      <Address>10.0.0.0</Address>
      <PrefixSize>8</PrefixSize>
   </Route>
   <Route>
      <Address>172.16.0.0</Address>
      <PrefixSize>12</PrefixSize>
   </Route>
   <Route>
      <Address>192.168.0.0</Address>
      <PrefixSize>16</PrefixSize>
   </Route>
</VPNProfile>

Once implemented, the VPN client’s routing table will appear as shown here.

Windows 10 Always On VPN Routing Configuration

Summary

Proper routing is crucial for ensuring full network connectivity and access to internal resources for Windows 10 Always On VPN clients. When split tunneling is employed, avoid using the default class-based route and instead define specific routes using ProfileXML as required.

Additional Information

Always On VPN Client DNS Server Configuration

Deploying Windows 10 Always On VPN with Microsoft Intune

Windows 10 Always On VPN Certificate Requirements for IKEv2

Windows 10 Always On VPN Certificate Requirements for SSTP

Leave a comment

87 Comments

  1. ND

     /  July 23, 2018

    Good post thanks for clarifying. Discovered this a while ago this post would have saved some time as the MSFT docs aren’t totally clear.

    Reply
  2. ced666

     /  July 24, 2018

    Hello Richard,

    I do not quite agree between Split Tunnel mode and Tunnel strength used in Always On.
    Contrary to what one might think, Tunnel Force mode only routes internet traffic into the tunnel and not all traffic. Split tunnel mode allows the Internet stream to pass through the home network router.

    In tunnel force mode, access to a local file server on its network is quite possible.

    Then I followed your Split Tunneling procedure with the Disabledclassroute directive to true and the declaration of all routes according to RFC 1918.
    I still can access my local resources on the home network.
    I think you really have to make the point between Tunnel Force and Split Tunnel mode. these two modes only manage Internet traffic.

    Patrick

    Reply
  3. Hello,

    In this case, the documentation is confusing between ForceTunnel mode and Split Tunnel mode. Only Lockdown mode allows you to control all traffic through the VPN connection.
    Partrick

    Reply
  4. Anders

     /  August 21, 2018

    FYI, there is an error in the example. Should be NativeProfile instead of NativePolicy.

    Thanks for this great article by the way, helped us a lot 🙂

    Reply
  5. David Oliver Elgh

     /  September 6, 2018

    Hi.
    We use Split Tunneling.
    Is there a way to direct specific traffic for a site to be tunneled and routed through the VPN. Without adding the IP ranges.

    Example I want all traffic to *.microsoft.com go through the VPN.

    BR, David

    Reply
    • You can route specific namespaces over the Always On VPN tunnel by configuring the DomainNameInformation element in your ProfileXML. However, you will also need to specify a proxy server for this to work by using the WebProxyServers element and providing the FQDN and port of your internal proxy server to be used for the namespace.

      Reply
  6. Marlon Rivera

     /  November 15, 2018

    Is there a way to set the metric on the static route?

    192.168.0.0
    16
    looking to set it here if possible. I’m reading on documentation about this

    the issue I’m facing is that I disable the class base routing and added a specific route but the metric comes lower than the Local Interface and VPN connection causing the intended traffic to go through the VPN when I do a traceroute. I’m using IP filters on the NPS server so when the user connects over vpn they are allow only the specified assigned resources, causing outlook to not connect which I will like to route the traffic on the split tunneling.
    I tested it by manually setting the metric on the interface lower than the static routes and everything works ok.

    thank you again and great documentation.

    Reply
  7. WADDAH

     /  December 13, 2018

    I need your advice, please
    I have setup a testing environment on Azure. So i have 1 VNET (172.0.0.0/16) on and one subnet (172.0.1.0/24) where all the DC/PKI/NPS/VPN servers are connected to. Only the VPN server is not joined to the domain. It has a public ip address attached to this single nic on the VPN server
    I have created the VPN connection profile and the clients can connect VPN successfully (they get ip addresses 192.168.1.0/24)
    The client is able to reach out to the VPN server internal IP address (172.0.1.6) but not able to reach to DC nor to NPS.
    I know it is a routing issue but i cannot figure out where exactly i need to do the routing? is it on the VPN server or on the VPN clients using the XML profile?

    Reply
    • Routing in Azure is a bit different. First, you’ll need to tell Azure it should route your VPN client subnet. Also, the VPN connection must also include routing information. For the Azure routing piece, have a look at this article I wrote about configuring NetMotion Mobility in Azure. The principle will apply to RRAS in Azure as well. https://directaccess.richardhicks.com/2018/02/08/deploying-netmotion-mobility-in-azure/

      You’ll need to make sure your server can reach any remote internal subnets and configure any static routes on the server if necessary. Finally you can follow the guidance in this post to configure your ProfileXML to ensure the Always On VPN client has the necessary routes as well.

      Reply
  8. Tavid

     /  January 7, 2019

    I am very inquisitive to test more secure ForceTunnel mode with this Always On VPN. Specially performance with IKEv2, is there any improvements versus DA/IPHTTPS or DA/Teredo.

    First of all, AOVPN SplitTunnel mode is working great. I can reach intra servers and surf to the public internet (straight from client´s ISP connection, not via VPN). When I change MakeProfile.ps1 configuration SplitTunnel -> ForceTunnel and deploy a new VPN profile, I still can access intra servers but not anymore to public internet. Also there is a yellow triangle icon on my connection saying some problem with connectivity test.

    Is there some additional steps in ForceTunnel mode to make clients ALL public internet traffic flow out through your VPN/Office and back to internet? Some proxy needed or is this scenario totally handled by proper routing configuration?

    Any tips are more than welcomed 🙂

    Reply
    • VPN performance using IKEv2 or SSTP will be much better than DirectAccess, no question about that. Interestingly enough, SSTP always seems to provide more throughput than IKEv2. Would be interesting to know if you have the same experience. Regarding force tunneling, you can configure an on-premises proxy but it isn’t strictly required. You just have to make sure that your VPN server and internal network routing/firewall configuration allows VPN clients to access the Internet.

      Reply
      • Tavid

         /  January 8, 2019

        Glad to share experiment results! But I still have problems to figure out how to make proper routing.

        In ForceTunnel mode, my client can access public routable internet address via VPN only if I add manually route to the target IP on my VPN-server. For example: “route -p add 8.8.8.8 mask 255.255.255.255 10.1.1.3”
        where 10.1.1.3 is VPN server´s internal network without gateway (because external network have the VPN servers default gateway). After this addon my VPN client is able to query google DNS 8.8.8.8. Just for example.

        But how to route all public networks via 10.1.1.3? I cannot add 0.0.0.0/0 route to 10.1.1.3 because then we loose VPN servers external network connectivity and clients on field cannot access at all. There is plenty of internet services with multiple/changing IP addresses and maintaining manually routes would be extremely painful. Is there some other way/place to do this routing? Thanks in advance!

      • In order for force tunneling to work correctly, the VPN server must have a default gateway with a path to the Internet. No way around this. On a single-NIC VPN server it usually just works. If you have multiple network interfaces, it is recommended the external interface be configured with a default gateway and the internal interface configured with static routes to any remote internal subnets. Details here: https://directaccess.richardhicks.com/2013/06/19/network-interface-configuration-for-multihomed-windows-server-2012-directaccess-servers/. Again, you’ll also need to ensure the Internet is reachable from this external interface because, as you’ve proven with your single static route, all traffic to the Internet from VPN clients will use this path. 🙂

  9. I added the lines and rebuilt the Vpn profile, but I don’t see any new routes appearing when i connected.
    I have tried to remove and readd to the exported xml, with no change.

    Is it maybe because similar subnets are already permanently defined with different gateway (for when I am on a local subnet)?

    Reply
    • No, any routes defined in your ProfileXML should appear in the routing table. If there are duplicate routes they’ll likely have different metrics assigned to them.

      Reply
  10. Also by removing the static routes, still no route addition. Force Tunnel mode works fine though, and also if I add a route manually.

    Reply
    • If the routes aren’t showing up in the client’s routing table it’s a good bet your ProfileXML isn’t configured correctly. Compare your configuration with some of the samples I’ve posted in my GitHub repository here: https://github.com/richardhicks/aovpn.

      Reply
      • It looks fine to me. It is the one exported with your lines added, but I remove the Native profile and Vpnprofile double tags, like in your example.
        I updated the Vpn server, tried in another machine 1809, with same result: only the route of the Dhcp lease relayed from the Vpn server appear, as though I hadn’t ever written the new lines from your site. Completely ignored.

      • Did you also set DisableClassBasedDefaultRoute to “true” in your ProfileXML?

  11. Positive. And also tried the same in a Win10-1803. Vpn works, no automatic extra routes.

    ….

    SplitTunnel
    true

    true
    true
    lab.domain.pro

    .lab.domain.pro
    192.168.6.66,10.1.1.4

    10.0.0.0
    8

    192.168.0.0
    16

    Reply
  12. Sergey

     /  April 2, 2019

    Hi Richard. Great article. Helped a lot for split tunneling, but I still have some issues.
    I have all routes in routing table and even use split tunnel, so I have internet while connected to VPN, but when I try to access local network I reach only VPN server. When can be wrong?

    Thank you

    Reply
    • Could be any number of things, but most commonly it can be routing configuration on the VPN server itself. Another common cause is internal network routing. For example, if you are using a unique IP subnet for your VPN clients, your LAN routing will need to be updated to return this traffic back to the VPN server.

      Reply
      • Sergey

         /  April 3, 2019

        Thank. I found the issue. It was routing on local network.

  13. Ben De Cock

     /  April 12, 2019

    Just wondering if you or anybody alse saw the following issue since feb 2019 patch rollup:
    After adding routes and disabling the classbasedDefault route we are getting reports of users sometimes getting the routes defined and sometimes not.
    They still get the VPN client ip, but all the routes defined in the profile just don’t appear.
    Disconnect + retry and they actually get the routes 0.o
    I’ve already got a premier case open for this, but just was hoping you came accros this and had a fix.

    Below the config of the routes.

    true

    10.0.0.0
    8

    185.138.96.135
    32

    185.138.96.136
    32

    185.138.98.135
    32

    185.138.98.136
    32

    Reply
    • Unusual for sure. This is the first report I’ve heard. Will be listening closely for others.

      Reply
      • Ben De Cock

         /  May 8, 2019

        Ok a few weeks later and msft has identified a possible issue when you have the aovpn profile with the alwayson value set to false… the last part i added as this is my setup and can see that with a full alwayson setup it might not be noticeable by the end user.
        The problem only occurs when going through the network “fly-out” to start your vpn connection.
        Details are still fussy but it seems to be related to the tcp stack calling a function, that is calling a service and receiving an access denied (for some reason)
        Will keep you updated when i have a confirmed fix.

    • I think it has to do with previously defined routes, like those distributed with Dhcp option…try reset those.

      Reply
      • As a point of reference, when using DHCP for VPN client IP addressing no options are provided to the client. The client only receives it’s IP address and subnet mask from the DHCP server and nothing else. It might be possible that some routes persist if moving from the corporate on-premises network to an external network. Of course if someone configured static routes on the client those could be problematic as well.

    • Ben De Cock

       /  July 15, 2019

      A bit late but forgot about this thread 🙂
      the solution for my issue was setting the following key:
      [HKLM:\SYSTEM\CurrentControlSet\Services\RasMan\RequiredPrivileges] with the values: “SeImpersonatePrivilege”,”SeIncreaseQuotaPrivilege”,”SeTcbPrivilege”,”SeChangeNotifyPrivilege”,”SeCreateGlobalPrivilege”,”SeAssignPrimaryTokenPrivilege”,”SeLoadDriverPrivilege”,”SeDebugPrivilege”

      The issue I saw was only seen for connections through the fly-out (=alwayson attribute set to false)

      MSFT hasn’t decided yet if they are going to fix it or just apply the workaround posted here.

      Hope this helps someone.

      Reply
  14. Alex Kram

     /  April 17, 2019

    Hi, i have trubleshot with my Always On VPN.
    User tunnel (IKEv2) connection from Windows 10 (1803) is triggered, routes applied, i see it`s status, packets are sended to interface – but no packets return back (zero at “Received”). Network and Sharing center shows my VPN-connection as “Identifying…” for a minute or two, then changed to “Public network”. If i wait 3-5 minutes(or if i reconnect manually) – status changed to “Domain Network” and in same time packets start running in both direction – everything is good now, connection worked.
    When i use SSTP protocol all work fine.
    How i can fix it?

    Reply
    • IF SSTP is working then it makes sense you have a valid network path. I’d suggest looking closely at IKEv2 communication and make sure that UDP ports 500 and 4500 are open and that NAT is configured correctly. Importantly, if you have more than one VPN server you’ll need to ensure that load balancing is configured correctly to ensure that both UDP 500 and 4500 are always delivered to the same server.

      Reply
      • Alex Kram

         /  April 18, 2019

        Richard thanks for your reply.
        I have one server vpn: wan interface looks on the Internet, and lan on my local network. Ports 500, 4500 are open. I use Split tunneling in my configuration.
        I tried the configuration that Microsoft recommends with van interfaces in dmz. But I got the same story.
        Perhaps this is important, my entire infrastructure is located on a VMware server.
        I will be grateful for any advice on this issue, I spent more than a week trying to solve this situation ((

      • If you have two network interfaces, make sure only the external interface is configured with a default gateway and that static routes are configured on the internal interface for any remote internal subnets.

  15. Asgeir Husum

     /  April 26, 2019

    Do you know of any option to use split tunneling like this:
    – Default everyting to VPN server, except
    – Office 365 URL and IPs (Dynamcally updated from O365 REST API…)

    Reply
    • There’s no native way to do this, unfortunately. There are custom solutions available. For example, I know Microsoft Consulting Services (MCS) in the UK offers something like this.

      Reply
      • Ben De Cock

         /  May 8, 2019

        There is a way by just having a correct proxy configuration file.
        Out of the box no, as you need to parse the ret api data into your pac file… although i know msft does do it for services like SfB were they provide a json file for everuthing that needs to be excluded from going over a forwarding proxy.
        So if you can find the data you just need to incorporate it correctly into a pac file.

      • Thanks for the tip!

  16. Dan Isaksson

     /  May 8, 2019

    Hi, as I understand and I would like to have a confirmation that i am not missing anything: It is not possible to separate the routing for the server and the VPN clients? If it is possible it would make life so much easier, for example as of now all internal subnets must be definied in the VPN server routing table. If new subnets are added internally they must be added to VPN server as well. If it was possible to separate this VPN clients could have default gateway pointing internally? Is it possible to have dynamic routing on the VPN server? Many thanks for great articles!

    Reply
    • VPN server and client routing are two different things. Indeed, the VPN server must be configured with internal routes, assuming it has two network interfaces. If it has just one interface it isn’t required (default gateway takes care of everything). VPN clients must be configured to route specific IP subnets over the VPN connection, if required. This does not have to strictly match the VPN server’s configuration. However, the VPN client can’t get to anything the VPN server can’t. so keep that in mind. I’m not sure about using a routing protocol for VPN clients though. I don’t believe that would work in this case.

      Reply
      • Dan Isaksson

         /  May 9, 2019

        Thank you for your answer, I see now that i was not clear in what i meant. I know that we define routes that should go into the tunnel at the client when using split tunnel. I was thinking about that the routing done in the VPN server is shared between the VPN server and the clients terminating there. Sometime it could be useful to have clients have a different default GW than the VPN server.

        Is it supported to configure Always on VPN using only one NIC? In Microsoft documentation i find no information about this. What would be your recommendation to do this setup? Maybe it is best to use NAT for the public IP since clients and the VPN server would share the same subnet?

      • Ok, I understand. Sorry for the confusion. To answer your question, no, there is no way to define a different default gateway for VPN clients. However, it is supported to configure the VPN server with a single network interface. Personally I prefer using two network interfaces, but sometimes using a single NIC can be easier.

  17. sebus

     /  May 17, 2019

    How does one route BACK to the CLIENTS from Internal LAN?

    VPN server
    public interface (with its default route out to Internet) ——- internal interface (LAN IP 10.0.0.x/16)) with nothing in default GW

    VPN Client
    Gets IP (10.0.16.x) from Pool on VPN (I could not get DHCP relay agent to work)

    LAN clients
    DHCP assigned 10.0.10.x-10.0.15.x /16

    I can ofcourse ping Internal VPN server interface, but none of the connected VPN clients

    Reply
    • If your VPN clients are on the same subnet as the internal network (10.0.0.0/16 as you indicated) then routing should not be required. If you are using a different mask than /16 and the VPN client subnet is different from the internal network, then the router on the LAN would need to advertise the route for the VPN client subnet.

      Reply
  18. Hi Richard,

    Thanks again for this awesome blog on Always On VPN.
    I’m setting up Always On VPN for a customer, but have some routing difficulties.

    Just a short info on the environment:
    – Windows Server 2016 running RRAS
    – The RRAS server have 2 network interfaces called “Internal” and “External”.
    – The customer wants to use user and device tunnels using IKEv2.
    – The clients are running Windows 10 (1809) Enterprise.

    The client has 6 subnets:
    – Subnet DMZ / 10.10.10.0/24
    – Subnet A / 192.168.1.0/24
    – Subnet B / 192.168.2.0/24
    – Subnet C / 192.168.3.0/24
    – Subnet D / 192.168.4.0/24
    – Subnet E / 192.168.5.0/24

    The RRAS server is located on the subnet “DMZ” (External) and subnet “A”. The clients get an IP from subnet “B”.

    The clients successfully connect and establish the VPN connection. The client can also reach services/devices on subnet “B”, “C” and “D”. But it can’t reach servers/services on subnet “A”. Clients can ping the interfaces of the RRAS server which have IP’s in the subnets “DMZ” and “A”.

    The route table looks fine. It knows the routes to every subnet, but somehow the RRAS server routes all traffic through its external interface. That means when clients we get a routing triangle (loop). I have tried to create a static route to subnet A through the internal interface, but no dice.

    Have you experienced this before and do you have any tips we could try?

    Kind Regards Alex

    Reply
    • When you look at the properties page in the RRAS management console where you define the IPv4 address assignment for VPN clients, there’s a drop-down list at the bottom of that screen that allows you to select the interface to be used DHCP and DNS. Make sure that is set to the Internal interface (don’t let it select automatically). Let me know if that helps.

      Reply
      • It’s set with the following on the IPv4-tab:
        – Enable IPv4 Forwarding (checked)
        – Static address pool (not DHCP)
        – Enable broadcast name resolution (checked)
        – Adapter set to “Internal”.

        Still no dice.

        Could it be that the “Enable broadcast name resolution” and “Static address pool” doesn’t work together?

      • Did you say you tried adding static routes on one of those servers to point VPN client traffic back to the appropriate VPN server just to test?

      • Yes, I have tried to add an static route on the VPN-server to the internal (subnet A) subnet with the “internal” interface as a gateway. But it still routes the traffic through the “external” (subnet DMZ) interface. The VPN-server routes its own traffic normally through the internal interface.

      • Not sure what’s up then. Sure sounds like a routing issue though.

  19. By the way. The server is running on Hyper-V. The environment have one virtual switch for all VLANs. In Microsofts documentation the following is stated:

    “It is important to: Install two Ethernet network adapters in the physical server. If you are installing the VPN server on a VM, you must create two External virtual switches, one for each physical network adapter; and then create two virtual network adapters for the VM, with each network adapter connected to one virtual switch.” -https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/vpn-deploy-ras

    Altough if the RRAS server is able to route its own trafic, I suspect this have nothing to do with it?

    Reply
    • The requirement for a physical server and two network interfaces is inaccurate. You can deploy RRAS on a virtual machine with one or two network interfaces and those are fully supported scenarios. It’s unusual not to have distinct virtual switches for each VLAN, but as long as they can reach each other it should work.

      Reply
  20. sebus

     /  May 29, 2019

    In IP Pool I have NO option to specify subnet mask. Client gets IP 10.0.16.x & this is all I see. Do I need to assume that is is in fact /24 ?
    I can not even ping VPN client from VPN server itself!

    Reply
    • No need to supply a subnet mask in this case. All clients get a /32 subnet mask. If you can’t ping the client from the server it is connected to, I would ask if the firewall on the client was configured to allow inbound ICMP echo request?

      Reply
  21. sebus

     /  May 29, 2019

    Active Routes:
    Network Destination Netmask Gateway Interface Metric
    0.0.0.0 0.0.0.0 172.19.1.1 172.19.1.2 266
    10.0.0.0 255.255.0.0 On-link 10.0.0.15 266
    10.0.0.15 255.255.255.255 On-link 10.0.0.15 266
    10.0.16.1 255.255.255.255 On-link 10.0.16.1 287
    10.0.16.2 255.255.255.255 10.0.16.2 10.0.16.1 32
    10.0.16.4 255.255.255.255 10.0.16.4 10.0.16.1 32
    10.0.16.5 255.255.255.255 10.0.16.5 10.0.16.1 32
    10.0.16.6 255.255.255.255 10.0.16.6 10.0.16.1 32
    10.0.16.8 255.255.255.255 10.0.16.8 10.0.16.1 32
    10.0.16.9 255.255.255.255 10.0.16.9 10.0.16.1 32
    10.0.16.10 255.255.255.255 10.0.16.10 10.0.16.1 32

    Wht can I do if each client is also its own gateway

    Reply
  22. sebus

     /  May 31, 2019

    That is client, but it has nothing to do with routing in the end, but firewall (but it is not as simply as allow ICMP (ofcourse that is allowed on domain machines): https://social.technet.microsoft.com/Forums/lync/en-US/043842b8-6480-4dbe-8b14-f889d6b361f4/routing-to-vpn-clients

    Reply
  23. sebus

     /  May 31, 2019

    Just testing here: with

    10.0.0.0
    16

    I get in routing table:
    Network Destination Netmask Gateway Interface Metric
    0.0.0.0 0.0.0.0 192.168.88.1 192.168.88.98 35
    10.0.0.0 255.0.0.0 10.0.16.1 10.0.16.9 26
    10.0.0.0 255.255.0.0 On-link 10.0.16.9 26

    No idea why 10.0.0.0 255.0.0.0 appears at all?

    Reply
  24. Hello, we are testing Always On VPN on windows 10 clients (ver 1803), All works as expected. It is a User Tunnel, via SSTP, set up with split routing and Name Resolution Policy table (NRPT), we also have several Route entries in our profile.xml for the many subnets we have here.

    However we have a 3rd party guest network here and laptops with 4G SIM cards in them. If a laptop connected to one of these the AO VPN connects and all works fine. But if the users then put their laptop in a docking bay, which is on the corporate LAN, the Always On VPN stays connected. What is worse in testing the traffic is still routing through AOVPN (I assume because the NRPT has priority).

    The VPN connection FQDN is only accessible from the internet. You can’t even resolve it from the corporate LAN.

    Question: Is this expected behavior? Do users have to manually disconnect? As I recall Direct Access would detect it was on the corporate network and drop the connection.

    Cheers

    Matt

    Reply
    • Hi Matt! I’m currently testing a workaround for this scenario. Can you reach out to me directly so I can provide you with detail instructions please? If successful I will post the results here for others. 🙂

      Reply
  25. Zack

     /  July 10, 2019

    Is this possible through InTune? There is routing options under ‘Split Tunneling’ but they don’t seem to take effect on the client. I don’t get any additional routes on the client.

    Reply
    • Absolutely. If you select the option to enable split tunneling you’ll also have the option to provide specific internal routes using the Destination prefix and Prefix size fields. You can enter them manually or upload them via CSV file.

      Reply
  26. Jason Hall

     /  August 8, 2019

    Is there a way to add the client static routes without recreating the profile? I am using split tunneling and tried using Add-VpnConnectionRoute -ConnectionName “Contoso” -DestinationPrefix “176.16.0.0/16” -PassThru but after running this then running Get-NetRoute – AddressFamily IPv4 | ft -Autosize its not displayed.

    Reply
    • Not to my knowledge. Routes for Always On VPN should be defined in ProfileXML and if they need to be changed you’ll have to remove the connection and re-create it. If you are using Intune (native UI or custom ProfileXML) then removing/re-creating the connection is handled transparently for you. 🙂

      Reply
      • timbo01

         /  August 16, 2019

        Can you confirm that Intune removes/re-creates the routing information when syncing? I have seen the Connection refresh and look like it gets re-created in the Network Connections window – but the routing table is the same as the previous profile that was installed and not the new one??

      • I’ve done some testing in the past and I know that updating ProfileXML does result in those changes being pushed to the client. I don’t recall testing route additions specifically, but I expect they’d work the same way. It may take a period of time of course, but eventually those changes should be implemented on the client.

  27. Tim

     /  August 16, 2019

    How can I add a /32 route to say a new AD Server to an existing VPN Profile via Intune? Uploading a new XML file with the changes and then re-syncing doesn’t update the routes on the existing profile.
    Also, how do we delete a VPN profile from a users PC? removing the user from the AD Group doesn’t delete the profile, neither does deleting the profile entirely from Intune. Help!! (Is this lack of control due to us using a Custom profile (required for crypto) in Intune rather than a VPN profile?)

    Reply
    • If you add a new route to your ProfileXML and publish that using Intune, I would expect that clients will receive the new route when they synchronize their settings. You should not be required to remove the VPN connection and re-create it unless you are using SCCM with PowerShell or PowerShell alone. Also, if you remove the VPN profile from Intune, or remove the user from the group assignment for the VPN profile I would expect it to be removed at some point in the future after syncing settings. If that’s not happening you may need to investigate Intune synchronization more closely.

      Reply
      • Tim

         /  August 19, 2019

        Thanks for your comments Richard, I have just removed a user from the assignment group and the profile was NOT removed from the computer – I then deleted the entire profile from Intune and sync’d the client – again, the Profile was NOT removed. Is this something you can test and confirm that it still works this way? as it’s not the behaviour I am seeing at the moment. Many thanks.

      • Sure sounds like an Intune issue then. I’ll try to do some testing soon and let you know if I have the same experience though.

      • Nat

         /  August 19, 2019

        Just to add I’ve deployed AO VPN with Intune recently and found that any updates to the XML profile were reflected fine when the next sync happened. I can’t recall if we removed any users from the group and whether this removed the profile.

        I do know that for some cloud based services (e.g. AIP) AAD group membership is cached so changes to group memberships are not always reflected straight away (up to 3 hours). Not sure if Intune does anything similar – ?

      • Thanks Nat. I’ve had the same experience, although I don’t specifically recall testing the removal of a profile. I’ll test soon just to validate. No question Intune is slower sometimes than on-premises Active Directory group policy, but that’s to be expected. It should still eventually sync and remove the settings though! Stay tuned. 🙂

      • Tim

         /  August 20, 2019

        I had a test device tunnel (Split tunnelling) with /32 routes setup to AD / SCCM servers and a user tunnel (Forced Tunnel) and discovered that user traffic destined for the AD or SCCM servers still used the Device Tunnel route (I guess it’s because the /32 routes are more specific?) so I am implementing RFC1918 route addressing on both the Device Tunnel and the User Tunnel as we want all traffic to flow via the User Tunnel when the User Tunnel is connected and the Device Tunnel will only handle traffic on pre-login for Group Policy and Manage-Out capabilities. One thing is I haven’t really seen documented is routes being used in a Forced Tunnel scenario – I take it I can still use routes? (despite a VPN Profile template in Intune only allowing routes to be set in a Split Tunnel setup)

      • You are correct. When parsing the routing table, the most specific route always wins. If you’re using a /32 to destination that’s reachable via a different interface with a /24, the /32 is preferred. Same applies for force tunnel configuration. With force tunnel you are essentially creating a 0.0.0.0/0 route. Any other route will be more specific and be preferred, if you create them.

      • Ben De Cock

         /  August 19, 2019

        You might be hitting an issue i found, and hasn’t been fixed yet.(got a workaround though)
        Not the intune part, but still…
        None of the routes get added after adding a route in the profile.
        More details, and the workaround have been posted earlier in this post.
        If it’s the same behaviour please post…. premier support needs more people for thus issue.

      • Tim

         /  August 20, 2019

        All my profiles are alwayson=true – would the issue you found still affect me?

      • I would expect.

  28. Jamie Thatcher

     /  December 10, 2019

    We use force tunnelling and would like to route all internet traffic through our internal network adaptor (the default route on the VPN server is set to the external adaptor), is there any way of doing this without the use of an internal proxy server?

    We need this is because only our internal firewall has the ability to filter internet traffic.

    Reply
    • The quick and easy way to do this would be to move the default gateway to the internal interface. However, for clients to connect to the VPN server from the Internet you would then need to enable source address NAT to the VPN server, which is not recommended. It works, but it introduces some other potential issues. In this scenario it might make more sense to switch to a single network interface instead.

      Reply

Leave a Reply to Matt IOW NHS Cancel reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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: