When 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.
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.
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
ND
/ July 23, 2018Good post thanks for clarifying. Discovered this a while ago this post would have saved some time as the MSFT docs aren’t totally clear.
ced666
/ July 24, 2018Hello 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
Richard M. Hicks
/ July 24, 2018That is expected and by design. Local networks will have a higher priority in the VPN client’s routing table. If you want to prevent the client from accessing any local resources at all you’ll have to enable lockdown mode.
https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/always-on-vpn/always-on-vpn-enhancements#security
MrHaggis
/ July 27, 2018I agree, Forced tunnel isnt really a true forced tunnel, or feature comparable with other VPN solutions that manipulate the routing table to block access to local subnets.
Using lockdown mode isnt really an option for us as we only want to use the vpn when away from the office, not when connected to the network, and lockdown will block all access unless the vpn is connected from what i can tell from its description here. https://docs.microsoft.com/en-gb/windows/security/identity-protection/vpn/vpn-security-features#lockdown-vpn it seems more suited to devices that will only ever access corporate resources via a VPN, not ones that occasionally use the VPN when away from the main network.
Any ideas how to get a forced tunnel, that disallows access to local network subnets when the user tunnel VPN is connected?
Thanks
Patrick
/ July 25, 2018Hello,
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
Anders
/ August 21, 2018FYI, 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 🙂
Richard M. Hicks
/ August 25, 2018Thanks for bringing that to my attention! I’ve updated the post accordingly. 🙂
David Oliver Elgh
/ September 6, 2018Hi.
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
Richard M. Hicks
/ September 6, 2018You 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.
Marlon Rivera
/ November 15, 2018Is 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.
Richard M. Hicks
/ November 17, 2018I’m not aware of any way to set the route metric using ProfileXML. The routes you configure would, by design, have a lower metric as the expectation is that you’re intending to route that traffic over the VPN tunnel. If you want to exempt some traffic from going over the VPN tunnel, I’d suggest trying to use the DomainNameInformation element to include/exclude traffic. Details here: https://directaccess.richardhicks.com/2018/04/23/always-on-vpn-and-the-name-resolution-policy-table-nrpt/.
Gregg Hartness
/ April 10, 2020According to https://docs.microsoft.com/en-us/windows/client-management/mdm/vpnv2-csp this functionality was added in 1607. I didn’t see information on what XML tag to use in any documentation I could find, so I tried the obvious “Metric” and it seems to work. This allows us to put essential routes (DC and DNS) in an IKEv2 device tunnel config and and have the same ones in an SSTP user tunnel config with a lower metric and thus avoid a routing conflict. It will prefer the device tunnel when both are active, but preserve basic access in a situation where the device is at a location that blocks IKE traffic.
Richard M. Hicks
/ April 10, 2020Interesting. Typically this isn’t required because if you are using host routes on the device tunnel (recommended) then there won’t be any routing conflicts. If the device tunnel is up, any traffic to domain controllers will use the device tunnel even if the user tunnel has a similar route, because the device tunnel route is more specific. If the device tunnel is down and the user tunnel is up, there’s nothing to worry about because those routes won’t exist anyway.
Dekor
/ May 12, 2020Greg, can you confirm format used for the XML tag for metric? Think we’ve hit this issue, we need 10.0.0.0/8 to be routed via the user tunnel but this overlaps with our dc’s in device tunnel which sit in that class. So seeing issues at times where device seems to be confused whether to use User or Device tunnel to reach DC’s. If I can set the route in user tunnel to have lower metric this will solve so many issues I hope!
Gregg Hartness
/ May 14, 2020Dekor, the XML tag is just METRIC. However, it doesn’t work the way a typical metric does. The value you put inside the tag is a number to add to the base metric for VPN-based routes of 25. In our case, we put the number 5 in so the route metric became 30 (base 25 + modifier 5). If you don’t specify a metric it will be 26 (base 25 + implied modifier 1). Beause of all that you will actually have to do the reverse of what you said and set the device tunnel entries to have a higher metric as there is no way that I know of to lower a metric (only to increase it).
Just this week we discovered a new bit of info. We deployed our AOVPN configs via SCCM/MECM as applications using the powershell scripts provided by Microsoft. If you want to use the built-in VPN deployment bits in MECM or Intune, you can’t leverage the metric settings as the wizards don’t let you configure it.
Richard M. Hicks
/ May 14, 2020To be clear, there is no provision for changing the interface metric in XML or Intune. Using XML you can configure the metric for individual routes, but again, not the interface. The only way to do that is by editing the InterfaceMetric setting in rasphone.pbk. A script to do this can be found here: https://github.com/richardhicks/aovpn/blob/master/Update-Rasphone.ps1.
WADDAH
/ December 13, 2018I 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?
Richard M. Hicks
/ December 18, 2018Routing 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.
Tavid
/ January 7, 2019I 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 🙂
Richard M. Hicks
/ January 7, 2019VPN 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.
Tavid
/ January 8, 2019Glad 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!
Richard M. Hicks
/ January 8, 2019In 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. 🙂
lonblu
/ March 9, 2019I 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)?
Richard M. Hicks
/ March 9, 2019No, 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.
lonblu
/ March 9, 2019Also by removing the static routes, still no route addition. Force Tunnel mode works fine though, and also if I add a route manually.
Richard M. Hicks
/ March 9, 2019If 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.
lonblu
/ March 9, 2019It 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.
Richard M. Hicks
/ March 9, 2019Did you also set DisableClassBasedDefaultRoute to “true” in your ProfileXML?
lonblu
/ March 9, 2019Positive. 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
Richard M. Hicks
/ March 10, 2019Sorry…the formatting gets lost here sometimes.
Can you send me your entire ProfileXML via email?
Sergey
/ April 2, 2019Hi 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
Richard M. Hicks
/ April 2, 2019Could 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.
Sergey
/ April 3, 2019Thank. I found the issue. It was routing on local network.
Ben De Cock
/ April 12, 2019Just 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
Richard M. Hicks
/ April 12, 2019Unusual for sure. This is the first report I’ve heard. Will be listening closely for others.
Ben De Cock
/ May 8, 2019Ok 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.
lonblu
/ April 12, 2019I think it has to do with previously defined routes, like those distributed with Dhcp option…try reset those.
Richard M. Hicks
/ April 13, 2019As 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, 2019A 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.
Richard M. Hicks
/ July 15, 2019Thanks Ben. Definitely helpful! 🙂
Alex Kram
/ April 17, 2019Hi, 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?
Richard M. Hicks
/ April 17, 2019IF 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.
Alex Kram
/ April 18, 2019Richard 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 ((
Richard M. Hicks
/ April 18, 2019If 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.
Asgeir Husum
/ April 26, 2019Do 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…)
Richard M. Hicks
/ April 26, 2019There’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.
Ben De Cock
/ May 8, 2019There 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.
Richard M. Hicks
/ May 9, 2019Thanks for the tip!
Dan Isaksson
/ May 8, 2019Hi, 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!
Richard M. Hicks
/ May 8, 2019VPN 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.
Dan Isaksson
/ May 9, 2019Thank 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?
Richard M. Hicks
/ May 9, 2019Ok, 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.
sebus
/ May 17, 2019How 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
Richard M. Hicks
/ May 17, 2019If 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.
Alex Ø. T. Hansen
/ May 21, 2019Hi 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
Richard M. Hicks
/ May 21, 2019When 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.
Alex Ø. T. Hansen
/ May 22, 2019It’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?
Richard M. Hicks
/ May 23, 2019Did 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?
Alex Ø. T. Hansen
/ May 23, 2019Yes, 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.
Richard M. Hicks
/ May 23, 2019Not sure what’s up then. Sure sounds like a routing issue though.
Alex Ø. T. Hansen
/ May 22, 2019By 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?
Richard M. Hicks
/ May 23, 2019The 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.
Alex Ø. T. Hansen
/ May 23, 2019Then I’m out of ideas. Is it worth a try to separate the v-switch and VLANS?
Richard M. Hicks
/ May 23, 2019Not a bad idea. Would at least eliminate that configuration being a source of the problem.
sebus
/ May 29, 2019In 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!
Richard M. Hicks
/ May 30, 2019No 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?
sebus
/ May 29, 2019Active 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
Richard M. Hicks
/ May 30, 2019Is that the routing table from the server or client?
sebus
/ May 31, 2019That 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
sebus
/ May 31, 2019Just 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?
Richard M. Hicks
/ June 7, 2019Not sure. Assuming you’ve disabled default class-based routes, correct?
Matt IOW NHS
/ June 14, 2019Hello, 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
Richard M. Hicks
/ June 14, 2019Hi 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. 🙂
Zack
/ July 10, 2019Is 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.
Richard M. Hicks
/ July 14, 2019Absolutely. 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.
Jason Hall
/ August 8, 2019Is 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.
Richard M. Hicks
/ August 13, 2019Not 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. 🙂
timbo01
/ August 16, 2019Can 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??
Richard M. Hicks
/ August 16, 2019I’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.
Tim
/ August 16, 2019How 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?)
Richard M. Hicks
/ August 16, 2019If 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.
Tim
/ August 19, 2019Thanks 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.
Richard M. Hicks
/ August 19, 2019Sure 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, 2019Just 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 – ?
Richard M. Hicks
/ August 19, 2019Thanks 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, 2019I 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)
Richard M. Hicks
/ August 20, 2019You 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, 2019You 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, 2019All my profiles are alwayson=true – would the issue you found still affect me?
Richard M. Hicks
/ August 20, 2019I would expect.
Jamie Thatcher
/ December 10, 2019We 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.
Richard M. Hicks
/ December 15, 2019The 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.
Mathias
/ December 22, 2019Hi Richard, amazing blog. I’ve learned a lot from you. Thanks for that :).
I’ve DeviceTunnel (computers authenticated by device certificate) working really great, i can reach internet and all of my company resources. I also have working UserTunnel with a user certificate authentication inside DeviceTunnel, which right now works the same like DeviceTunnel.
I need to limit DeviceTunnel connectivity, only to a certain servers like AD, Fileservers, SCCM and couple others.
Because of security reasons,( my SECOPS guys are pain in the a… ) i would like for user to use UserTunnel, to be granted access to number of specified servers.
Can UserTunnel have other subnet than DeviceTunnel. Or maybe i can use AD Groups and NPS for limiting user access.
Many thanks in advance for a response.
Regards
Matthias
Richard M. Hicks
/ December 24, 2019You have numerous options. The device tunnel and user tunnel can have different levels of access. In fact, best practice is to restrict the device tunnel to only those servers that are required to support domain authentication. Certificate services infrastructure (issuing CAs, CRL, and OCSP servers) and perhaps management servers (WSUS, SCCM, etc.) might be acceptable too. You can restrict access using host routes or traffic filters, and you can do this on both device tunnel and user tunnels.
Mathias
/ December 24, 2019Many thanks for the reply. I’ve read in the official documentation of device tunnel. That traffic filters block, inbound traffic and breaks manageability. Did they fixed that or is it still true.
In your opinion what is better and demands less maintenance.
Can you point me to some documentation on Host Routes routing or traffic filters on AOVPN.
I’m new to the networking scene, so i have a lot to learn.
Many thanks in advance, and Merry Christmas.
Richard M. Hicks
/ December 24, 2019Traffic filters are difficult to manage and yes, they break manage out functionality. Not sure when/if Microsoft is going to fix that. You can restrict access using host routes which are essentially routes to specific individual IP addresses with a prefix size of /32. Have a look at this example device tunnel ProfileXML on my GitHub. Merry Christmas! 🎄
Mathias
/ December 24, 2019Great, thanks again for your help. 🙂 Now i know how to limit DeviceTunnel. My SecOps will be happy.
I don’t know if understand the concept correctly. I can use NPS policies to limit user access to certain services on the UserTunnel. The best from for me, and helpdesk would be RBAC based on AD groups. Is this possible, or do i need to configure it, the same way it is done in DeviceTunnel.
Richard M. Hicks
/ December 24, 2019Always On VPN (device tunnel or user tunnel) doesn’t have any native RBAC, but you might be able to leverage Azure Active Directory Conditional Access to do something like that. Details here: https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/overview.
Nik
/ January 4, 2020Hi Richard, I had similar issue to the some replies above, e.g. “lonblu”
My ProfileXML seems okay but routes for the split tunnel do not show up.
The tunnel itself works fine so if I add a route manually on the client (route add…) it works as expected.
Any updates what would be a reason?
Are that routes entirely client-based and do not assume any interactions with a server while VPN connection activated? I try to set AOVPN without Windows-based server part and it works well but routes for a split tunnel. Could be this a reason?
Richard M. Hicks
/ January 4, 2020If the routes you define in ProfileXML aren’t showing up on the VPN interface on the client I can only suspect that there is a syntax error in your XML. Either the route elements aren’t properly nested or there is a typo in one of the associated tags. Have a close look at that and let me know what you find.
Nik
/ January 7, 2020No luck. I grabbed both script and ProfileXML from your GitHub and repeated everything from the scratch. This is not particular machine issue too – routes do not show up on different machines with different Windows 10 builds installed. DisableClassBasedDefaultRoute=true does not work too: I still have default class-base route for the VPN subnet (which is useless in my case).
Question: should “DisableClassBasedDefaultRoute=true” be reflected in VPN settings GUI as a checked respective checkbox (Networking-IPv4-Advanced)? In my case, checkbox is not set. If I manually check this checkbox, I do not receive default class-based route as expected (but still have no custom routes).
I have the only hypothesis: and , the only sections that differ from your examples, make a difference. Perhaps some specific settings prevent to add custom routes. Another guess: my hardware router which is used as IKEv2 server (ZyWall) can push some payload that overrides ProfileXML settings. I’ll keep trying.
Richard M. Hicks
/ January 8, 2020That’s quite strange. Something is definitely weird there for sure. If your ProfileXML includes the DisableClassBasedDefaultRoutes = True, then yes, the UI should reflect that. I would be curious to know if, after you deploy your ProfileXML using the script, if the same settings appear afterward. You can view the ProfileXML for a configured VPN connection using the PowerShell script found here: https://github.com/richardhicks/aovpn/blob/master/Get-VPNClientProfileXML.ps1. Would be interesting to see if the settings make it there at all.
Nik
/ January 12, 2020Hi Richard, I setup Windows-based VPN server and learned that is not server-related problem. I also tried Get-VPNClientProfileXML.ps1 and found that it returns NativeProfile section content only. Some settings outside this section, e.g. “TrustedNetworkDetection” indeed there because it works but the script does not withdraws it.
I also found that ProfileXML settings ultimately translate to the rasphone.pbk entries where I can control them directly. So, my ProfileXML does not create “Routes” entries there but Add-VpnConnectionRoute cmdlet does! They do show up in rasphone.pbk and work. I’m almost sure that the problem is in my ProfileXML xsd file that is incorrect or absent, probably because of faulty DirectAccess setup that was installed in my domain and which probably generated client GPO that made xsd file corrupted since seems all my domain-joined PCs are affected.
I was only able to locate VpnProfileSchema.xsd file that does have different syntax for the routes (i.e. “DestinationPrefix” instead of “Address”) but this does not work either, probably because this xsd is not intended to use with VPNv2 CSP. Microsoft site refers https://docs.microsoft.com/ru-ru/windows/client-management/mdm/vpnv2-profile-xsd to the EapHostConfig.xsd. That is odd (looking on its name…) and content of this file on my PC is totally different.
Could you please advise the name, location and content of “actual” xsd file that is used to parse ProfileXML content?
Richard M. Hicks
/ January 13, 2020My script might only work when using the native profile. I’ll have to look at that and see how to make it work with the plug-in profile. However, glad you were able to identify it as an issue with ProfileXML though. For the record, the CSP is documented here: https://docs.microsoft.com/en-us/windows/client-management/mdm/vpnv2-csp. The XSD is documented here: https://docs.microsoft.com/en-us/windows/client-management/mdm/vpnv2-profile-xsd. That’s mostly developer stuff though, but the native and plug-in profile example sections are helpful.
Native profile example: https://docs.microsoft.com/en-us/windows/client-management/mdm/vpnv2-profile-xsd#native-profile-example
Plug-in profile example: https://docs.microsoft.com/en-us/windows/client-management/mdm/vpnv2-profile-xsd#plug-in-profile-example
I also have sample XML files on my GitHub as well: https://github.com/richardhicks/aovpn
paddy berger
/ January 7, 2020Hi,
I have successfully connected the VPN, can ping ips and fqdns, can also RDP to servers, however cannot browse network folders via ip or fqdn. Any ideas?
Thanks
Richard M. Hicks
/ January 8, 2020Have to assume it is authentication related. Does your user certificate have a valid UPN included in the Subject Alternative Name field? Do all of your domain controllers have a Kerberos Authentication certificate installed? Details here: https://directaccess.richardhicks.com/2019/05/20/always-on-vpn-clients-prompted-for-authentication-when-accessing-internal-resources/.
Paddy Berger
/ January 9, 2020Hi Richard, a step closer.
So I have now put KDC on domain controllers and can now access without the domain suffix. Also dfs lists users folder, but can now access whereas before I get authentication error. Only issue left is that I cannot see all folders in DFS. Just to make it a little clearer, we created a parallel PKI on SHA2 and used this for the user, vpn, etc certs. This was not on the DC as we didn’t want to hit the complete domain with the new certs incase of any problems. So now, all machines have the old and new pki root cert, issuing cert, however not all machines have computer cert for new pki. So could possibly be missing something?
Richard M. Hicks
/ January 9, 2020All of your domain controllers would need to have the Kerberos Authentication certificate, no doubt. After that it should work. I’m not that familiar with DFS though, so there could certainly be something there that prevents this from working and I’m not aware of it.
Paddy Berger
/ January 7, 2020Update: I can access everything apart from DFS name spaces or servers without the fully qualified domain name.
Paddy Berger
/ January 10, 2020Hi Richard, all working now.
Thanks for the help on the Kerberos cert, that resolved half the issue. With DFS Namespace, that is now working too. Was linked to have offline files service on, turned that off and now all is working correctly
Cheers
Richard M. Hicks
/ January 10, 2020Glad you were able to get it sorted out!
Andy Cippico
/ January 30, 2020This is more of a sounding-off than a tech question:
I’ve had AlwaysOn VPN running well for some time now but never looked at tying down the Device tunnel routes until now. I’ve successfully done that using the Route entries in the XML file and adding all the AD DCs. I’m finding that the client authenticates fine but of course the GPO to map network drives doesn’t run because I’ve not added any file server IPs to the routes. It just sits there and holds the login process up until it times out.
Now, I could just add each file server’s IP into the XML file but they tend to change over time and new ones are added as new offices are established. I’m using SCCM and you’d think that would handle this better – but it doesn’t. Is Intune the only tidy way to achieve device tunnel updates for every client?
Richard M. Hicks
/ February 3, 2020Interesting observations regarding the device tunnel. Indeed, restricting device tunnel access is recommended because the tunnel is not as strongly authenticated as the user tunnel. Providing full internal network access to any device that has a machine certificate is a potential risk. Also, the device tunnel exists only to provide pre-logon connectivity anyway, so the idea of limiting access to domain controllers is generally accepted. It is not uncommon to also include certificate services infrastructure over the device tunnel (issuing CAs, CRL servers, OCSP servers, etc.) and other systems management servers (SCCM, WSUS, etc.). Management servers and/or workstations can be included to enable manage out scenarios. I’m puzzled though as to why your logon script is having issues with device tunnel access. That’s usually done in the context of the user, so network access would be provided by the user tunnel, not the device tunnel. The only thing that would require device tunnel access would be startup scripts.
And yes, Intune is the way to go for managing Always On VPN profiles, both device tunnel and user tunnel. Managing them with SCCM makes things more difficult. Specifically, as you’ve learned, SCCM has no way to update an Always On VPN profile after it has been deployed. You must remove the connection entirely and re-create it. Not the case when using Intune though. You’d just make changes to the settings in the UI or upload a new ProfileXML and everything is taken care of for you.
Thoughts?
Mathias
/ February 3, 2020Hello again, many thanks for the help you’ve already have provided.
I have question about DeviceTunnel XML.
I’ve read on MS Docs, that with the ForceTunnel you cannot define own routes.
“VPN V4 and V6 default routes (for example. 0.0.0.0/0) are added to the routing table with a lower metric than ones for other interfaces. This sends traffic through the VPN as long as there isn’t a specific route on the physical interface itself.”
I would like to have ForceTunnel, also Disabled Class Based Routing, and a list of defined routes. Is there any other solution to achieve this
When i try to do this using device.xml
ForceTunnel true
xx.xxx.xxx.x
32
I get General error when i’m trying to import this .xml using .ps1 script from MS.
Regards
Matthias
Richard M. Hicks
/ February 3, 2020That’s correct. Force tunnel, by definition, means that all client traffic comes over the VPN tunnel. You have to choose one or the other, force tunnel or specific routes (split tunnel). These options are mutually exclusive.
Matthias
/ February 3, 2020As always thank you for your replies. As i was suspecting, you can’t have a cake and eat it. My security team would like to close up everything 😉
Fortunately, as it turned out. Now i can have split tunnels, as long i have Usertunnels, i wish they said that to me 2 days ago. I’ve tried whole day to make forcetunnel work with the defined routes.
Regards
Matthias
Seth Allums
/ March 9, 2020Hi Richard!
We have somewhat of a strange issue. We’ve managed to get device tunnels set up and functioning. In our profile xml, we have disabled class based routing and have the following routes set up:
10.0.0.0
8
172.16.0.0
12
The client is able to reach any of our internal subnets – 10.x.x.x – (they are pingable) and browse any server’s web pages within those subnets, however, the client is not able to browse any of the websites (connection time-outs) from servers that reside in our DMZ (172.20.x.x), yet they can ping those servers and receive responses just fine. Our AOVPN server resides in the DMZ (multi-homed with a 172.20.x.x address and 10.x.x.x address), and we have followed best practices of having the gateway reside on the DMZ (external) address with no DNS entries, and the internal NIC 10.x.x.x has no gateway, but does have DNS entries, and a static route has been created on the AOVPN server.
The only workaround we have is not a pleasant one (modify the client’s hosts file with external IP entries for our DMZ servers) which works, but won’t be sustainable for us moving forward.
It’s odd that we can ping the servers in the DMZ, but not browse the sites. Have you ever seen something similar to this?
Richard M. Hicks
/ March 11, 2020Hi Seth. Just for clarification here, the clients are attempting to access resources in the DMZ, which is the same subnet as the VPN servers external interface, correct?
Seth Allums
/ March 11, 2020Yes sir. That is correct.
Richard M. Hicks
/ March 12, 2020That’s odd. If you can ping it, routing should be working. I’m assuming the firewall allows this traffic? Might be worth having a look at the firewall logs to verify. Also, I’d suggest taking a network trace to see what’s happening on the wire. That will tell you if the TCP traffic ever makes it to the target server, and if it does, where it is going from there.
Joe
/ March 10, 2020Hello, thanks for the article. We are having an issue with adding our routes to our XML. We have ~60 routes and when we add all of them the XML does not import the server information. If we limit it down to 5 routes it imports fine. Is there a limit to the size of the XML?
Richard M. Hicks
/ March 10, 2020I am not aware of any limit to the number of routes you can configure in ProfileXML. However, I’m sure I’ve implemented more than 5 routes in the past at least once. Is it possible to summarize any of these routes to reduce the number?
Gustav
/ March 12, 2020Hello Richard and thank you for this awesome blog that has helped us alot of times in the past!
We’re running a Windows Server 2016 AOV-solution with split-tunnel and policies via Intune. Everything was working great untill we ran out of IP-addresses and had to add another IP-scope. We’ve followed Microsoft Best practice during implementation (DMZ, one internal interface, one external etc).
The network connection for clients that get an IP-address from the new scope doesn’t work. It looks like the AOV-server doesn’t know where to send the traffic.
The original scope is a 172.16.X.0/24 and the new scope that we’ve added is a 192.168.X.0/24 (that’s why I found this page). So we’ve added below to ProfileXML (not formatted like this):
DisableClassBasedDefaultRoute: True
Route, Address: 172.16.0.0 (prefixsize 12)
Route, Address: 192.168.0.0 (prefixsize 16)
Get-Netroute shows a correct route to both network scopes like the ones you’ve posted above (both on client and on AOV-server).
Still the same problem so we’re thinking that we need to do some additional configuration on the AOV-server besides just adding the new scope and restarting the server.
Been searching for documentation regarding this but seems hard to find. Perhaps you can shed some much appreciated light?
1. Is it possible to add a new scope to a running configuration without removing and reconfiguring everything?
2. Is it possible to have scopes on separate class subnets?
2a, If yes, shouldn’t it be one PPP adapter RAS (dial in) for each network scope? We only have one for the 176.16 scope.
Best regards,
Gustav
Richard M. Hicks
/ March 12, 2020If you were assigning addresses to VPN clients from 172.16.X.0/24, and now you are also assigning address from the 192.168.X.0/24, did you also add corresponding routes on your core network? I suspect that perhaps your clients are able to reach internal hosts, but those hosts might not have a route pointing the traffic back to the VPN server.
FYI, it is recommended that a VPN server be configured to assign client address from the same contiguous subnet. However, it you want to assign addresses from multiple subnets I think it will work as long as the internal routing is in place. I’m not certain about this though, as it’s not something I’ve ever done. 🙂
Matt
/ March 13, 2020Thanks for the great information in your articles – If we have multiple VPN servers (not on domain) can they share a static IP address pool or is it best to create a separate pool for each server (maybe two ranges right next to each other)?
Richard M. Hicks
/ March 18, 2020Each server will need to have a separate, unique address pool to assign to VPN clients. This will make internal routing much easier as you can route specific VPN client subnets back to the correct VPN server.
trotterd
/ March 17, 2020Hi Richard, I hope you are well.
I work on a AOVPN setup with currently 3 RRAS VPN servers and 1 NPS server. The company is wanting to add an extra two VPN servers to allow for more capacity to cope with home working and the current COVID-19 outbreak.
The comms team said that they can change the /19 address range that the VPN servers and clients use to a /18 address range.
FYI, we use Split Tunnel and have “DisableClassBasedDefaultRoute” set as true.
What I am wondering is, in the AOVPN XML profiles for Device and User tunnels that we deploy using SCCM and PowerShell. The first route defined is the VPN IP Address Pool for connecting clients. The internal NIC of the three RRAS servers is configured low down on this network range also: –
Route
Address 10.100.64.0 /Address
PrefixSize 19 /PrefixSize
/Route
I am assuming I will need to update this route in the profiles and re-deploy to this: –
Route
Address 10.100.64.0 /Address
PrefixSize 18 /PrefixSize
/Route
But I don’t understand why this route is configured. On a test client, I deployed the Device and User tunnel with this route removed and all connectivity seemed to still work.
So I am wondering if I am missing the point for the reason for this route to be configured within the profiles and if it is removed, what is likely to break.
There is also discussions of deploying more servers but using a different network range for them and leave the existing range as is on current. So I am thinking I would need to add that new network range as an additional route in the profiles, but again, I don’t quite understand if they are required at all.
I did inherit this and don’t have access to the original person who configured the profiles.
Thanks in advance
Dave
Richard M. Hicks
/ March 18, 2020You do not need to add the VPN client subnet(s) as routes in your ProfileXML. That’s of course why it still worked when you didn’t add them. 🙂 The only routes you need to add are for internal subnets that must be reachable over the VPN. 🙂
trotterd
/ March 19, 2020Hi Richard, thanks very much for the swift reply and confirmation on what I thought. Much appreciated.
Regards
Dave
Gareth Wilson
/ March 18, 2020Hi Richard, great blogs on the whole AOVPN stuff, far clearer than microsofts own blogs about it !
What i was wondering and i cant find any information on it, is with other AOVPN vendors such as pulse secure etc you can allocate certain IP ranges/addresses to certain groups of users (so admin users get certain ip addresses etc that have enhanced access within the LAN) is there any way to achieve this with the microsoft AO VPN solution ?
Thanks in advance
Richard M. Hicks
/ March 18, 2020Not easily. You can assign a specific IP address to an individual user using Active Directory or NPS policy, but those options don’t scale well and really only work when you have a single VPN server.
Nik
/ March 19, 2020Hi Richard. Earlier we discussed an issue when routes from the ProfileXML do not show up in my environment. It’s still an issue but I found a detour by adding to the VPN profile deployment ps1 script a line “Add-VpnConnectionRoute -ConnectionName $ProfileName -DestinationPrefix $Route -CimSession $Session -PassThru” and populate it with respective values. It does work. Technically, that command leads to the same changes in rasphone.pbk as ProfileXML causes so the only difference is that I have to maintain VPN information in two places (ProfileXML and script) instead of single ProfileXML. Not a big deal. However, after few weeks of production I found that some VPN clients sometimes loose their routes, probably while reboots. I investigated rasphone.pbk of such clients and found that routes entries become empty (i.e. NumRoutes=0 and no Routes= entry). I feel that this “new” problem has the same root as lack of routes from a ProfileXML.
Whether you eventually would learn something new about this stuff, I would appreciate for a feedback.
Richard M. Hicks
/ March 20, 2020That’s quite unusual. I’ve not encountered this myself, and I haven’t had any customers report the same. Not sure what’s up, but it will be interesting to see if anyone has the same experience.
francisadu1
/ March 23, 2020Hi Richard, we would like to move clients to a different subnet as we are running out of IP on our current DHCP and cannot expand our IP range . any ideas on how to achieve this . we are running a device tunnel. Our clients will be in a different subnets than our network resources. Is there any way to specify routes for clients so they can reach network resources from different subnet. Would it require .xml file modification?
Richard M. Hicks
/ March 23, 2020You can define any subnet you want to assign IPv4 addresses to your clients. No routing changes are required on the client. However, you will have to configure routes in your core network to ensure that VPN client traffic is delivered back to the correct VPN server.
Ant
/ April 3, 2020Hi Richard,
Once deployed, is the only way to update the network traffic that can route over the device tunnel by updating the profile.xml and deploying this again to machines? For example if we wanted to add an additional IP/Network to reach over the AOVPN?
Thanks
Richard M. Hicks
/ April 3, 2020I believe so, yes. If you are using Intune you would simply upload an updated XML file and your clients will eventually get updated. If you are using SCCM with PowerShell you will have to remove the VPN connection completely and re-create it.
FYI, it might be possible to simply add routes after the device tunnel is provisioned using PowerShell and the Add-VpnConnectionRoute command. Not something I’ve tried, but it might work. I’d have to do some testing to ensure the routes persist and that they don’t overwrite existing routes though.
Justin
/ April 6, 2020Hi Richard, Thanks for another great post! I would like to know whether split tunneling is less secure than forced tunneling when using AOVPN? My understanding is that it would be because your VPN is accessible via the public internet. I’m currently using forced tunneling in production but it does require a lot of resources. I’m curious to know if split tunneling would be an option but need to justify the security before I can roll it out.
Richard M. Hicks
/ April 6, 2020Tough to answer. Being “secure” is subjective, really. The choice to use force tunneling vs. split tunneling (the subject of an upcoming post by the way!) is really a design choice. Typically force tunneling is deployed because organizations want to monitor and control Internet traffic on their managed devices when they are in the field. However, as you have learned, there’s a heavy price to pay for this. A better alternative is to enable split tunneling, then implement a solution that allows visibility/control of Internet traffic without having to backhaul the traffic over the VPN. Solutions such as Zscaler and Cisco Umbrella are popular and handle this quite well.
I’ll cover this topic in much more detail later, but hopefully this helps. 🙂
Justin
/ April 7, 2020Hi Richard, thank you for your prompt response. I look forward to your future post on the subject! I have used Zscaler in the past and it works well! The only other issue I have now realized is that some of our external providers use IP whitelisting to access their resources, this wouldn’t be possible with split tunneling as each user would get a public IP from their ISP. Thank you for all your great posts and responses they have helped me tremendously with AOVPN projects. I’m now deploying my 3rd solution and would have been lost without your help!
Richard M. Hicks
/ April 7, 2020Great to hear! It is possible to selectively tunnel specific domains over the VPN tunnel, but depending on what the resource is, sometimes it is easy, sometimes not. For example, if you want to route foo.example.net over the tunnel and it resolves to a single IPv4 address, that’s easy. Just include the route in the VPN connection’s routing table. If it resolves to a bunch of address and they consonantly change, it’s more difficult. If they are on IPv6 and your internal network doesn’t support that, it doesn’t work.
Justin
/ April 8, 2020Thanks Richard, appreciate the feedback!
Ivotou
/ April 8, 2020Hi Richard,
Is there a way to separate IP pools per user group in RRAS server, with this Covid-19 outbreak, we would like work at home users to get an IP address from the respective VLANS, it is not practical to have many RRAS servers for each user group, we are having around 40 groups, we could use one large pool but it is not benefitial for ous use case.
Another thing what are the benefit of having MS always on vpn with 3rd party firewall, if we can configure the 3rd aprty VPN hardware without any always on dependency?
Last question if we have RRAS server it will be very hard to do whitelisting do we need a firewall sitting behind the RRAS server, internet – MS RRAS gateway > firewall?
Thanks
Richard M. Hicks
/ April 8, 2020Separate IP pools for users/groups? Not easily. There is a way to assign users a specific IP address using Active Directory or NPS, but neither of these options scale very well.
The benefits of using a non-Microsoft VPN server or firewall are many. They are typically more robust and offer better security features (access control, granular policy enforcement, etc.). You can configure Always On VPN in Windows 10 to use some of these solutions as well. Details here: https://directaccess.richardhicks.com/2019/01/17/always-on-vpn-and-third-party-vpn-devices/.
To answer your last question, yes, if you want to do any sort of network access control you will need to have a firewall between the VPN server and your LAN. Again, it is possible to enforce some IP restrictions using NPS, but that’s not generally recommended.
Ivotou
/ April 9, 2020Thank you Richard for you fast response, appreciate that.
Yes there is an option as well in NPS we implemented for VLAN Assignment, that works with 802.1x, unfortunately there is no way we could do that to work with RRAS.
In fortinet there is an option, we create groups in AD for each client “min 50 in each site” , account, then on fortinet using ldap server, we create local groups in fortinet, each local group will be mapped to an AD group, that will give us a separate profile for each group, we could then easily implement policies, access list, filtering, dhcp scopes to each profile – group.
With the current Covid-19 outbreak the whole old VPN thinking has been changed, it will not be feasible and practical to assign a large pool in DHCP for the whole accounts, or scale out many servers for each client, it will add complexity, management overhead.
I hope MS will think about these caveats. It will be near to impossible to convince the higher management to approve always on VPN while we already have 3rd party VPN gateways. But if the options above are possible that will make it very easy to pass. If you have any workaround will more than glad.
Thank you again
Richard M. Hicks
/ April 10, 2020RRAS is sufficient for many deployments, but if it doesn’t meet your specific requirements then using a third-party firewall for Always On VPN is a better choice. I’ve deployed Windows 10 Always On VPN using a variety of third-party devices including Cisco, Palo Alto, and Fortinet. There are other solutions availble such as NetMotion Mobility that can provide even more granular control based on users, groups, devices, configuration, health, and much more.
victor bassey
/ April 19, 2020Hello Richard, I have a requirement to deploy both user and device tunnel using the forced tunnel approach. The challenge is my vpn gateway is only resolvable via external dns lookup. when the device tunnel connects,the user tunnel cannot come up due to inability to resolve DNS. i am unsure if i should be adding DNS records for the VPN server in my internal dns?
Also what is the best practice for using trusted network detection when deploying both user and device tunnel, they seem to conflict with each other.
Richard M. Hicks
/ April 20, 2020The general recommendation is to avoid using force tunnel whenever possible. If for some reason you have to use it though, it should be configured only on the user tunnel, not the device tunnel. If you can’t avoid using force tunnel on the device tunnel for some reason (there’s some question about supportability here to, be advised) then the user tunnel will always resolve names over the device tunnel. In that case you’ll need to have the public FQDN in your internal DNS resolving to a public IP.
victor bassey
/ April 23, 2020Thanks Richard.
Stuart
/ April 29, 2020Richard do you have any articles on setting up a full tunnel? I can’t find a decent one anywhere and I’m having a lot of problems with routing to different subnets.
Richard M. Hicks
/ April 29, 2020If by “full tunnel” you mean “force tunnel”, no. I typically discourage the use of force tunneling and try to avoid it as much as possible. However, to configure force tunneling you simply configure the RoutingPolicyType to ForceTunnel. If you do this, make sure you don’t define any routes as that will break the configuration.
Rob Nunley
/ April 30, 2020Hi Richard, thanks so much for your posts. I am trying to spin up a new environment for AOVPN (RRAS, NPS and CA Servers). Your website has helped greatly!
I am using device and user tunnels and they both connect. When only the device tunnel is connected, I can get out to the internet but cannot access any internal resources ie cannot ping DCs. Those addresses are configured in my ProfileXML. When I connect the user tunnel I still cannot access internal resources and internet access is cut off as well. The RRAS server has two NICs, LAN/DMZ, and is able to access all internal resources.
I am using split tunnel and I Disable Class Based Default Route is set to true.
Thanks!
Richard M. Hicks
/ April 30, 2020If you’ve disabled the default class-based route, did you also specify the routes you want to use for the internal network?
Rob Nunley
/ April 30, 2020My Profile includes:
10.0.0.0
8
Richard M. Hicks
/ May 1, 2020The formatting gets lost when you try to type brackets in the comments, sorry. 😉 Anyway, if you are routing 10.0.0.0/8 over the tunnel, that traffic then should go over the tunnel. Try running Test-NetConnection -Port 445 [name of internal server] and see what it reports.
Rob Nunley
/ May 6, 2020Thanks Richard! Turned out to be a VLAN problem. Thanks again!
Dragan
/ May 4, 2020So i have a strange issue, your routing helped to define split tunneling.
I can ping FQDN and nbname to all server and i can ping internal domain.
when I try to access share it gives me popup for credentials:
system could not contact domain controller
if I enter credentials it works.
I looked at firewall logs and nothing. I changed from split too full and stil the same…… I
Richard M. Hicks
/ May 4, 2020This post might be helpful. 🙂
https://directaccess.richardhicks.com/2019/05/20/always-on-vpn-clients-prompted-for-authentication-when-accessing-internal-resources/
Dragan
/ May 4, 2020Thank for this at least I know I looked at the wrong place. just one more info please. the certs are OK and have the extended values needed.
Could the problem be that there are multiple certs issued to the same server with different extended values (they use different cert templates) and NPS and DC is the same server and it is CA?
Richard M. Hicks
/ May 5, 2020It’s certainly possible. 🙂
Frank Nies
/ May 13, 2020Hi Richard,
We have implemented an Always On VPN solution and all works well except for one issue:
When startrting up the client laptop and logging in, the connection is established automatically, just like it is supposed to do.
However I am not able to reach any resources. I cannot even ping any Ip address on the VPN network. Not even the RAS servers interface.
Only after disconnecting and reconnecting the VPN connection I can reach all resources.
Is this a local routing issue, or is there a problem on the RAS server.
Any advice is highly appreciated.
Richard M. Hicks
/ May 14, 2020Not sure what’s up to be honest. If you can disconnect/reconnect and it works, it would seem that the client and server configurations are both correct. There have been some reported issues with RRAS not routing clients, but that typically requires a restart of the server, not the client.
Scott
/ May 18, 2020HI Richard, I am trying to implement the SetMetric script from your GitHub page. The tests run fine, until they don’t for some users. The VPN Connection appears to be deleted from the GUI, however rasphone.pbk still has the information pertaining to our VPN Profile. I cannot reinstall the VPN script you provided. It fails saying that is unable to install the VPN profile because “A general error occurred that is not covered by a more specific error code”.
The only workaround i have is to rename rasphone.pbk to .old and then rerun the scripts.
Any ideas why the file gets some sort of lock or corruption when trying to set the VPN Metric, but only occasionally?
SET MyDirectory=%~dp0
SET PowerShellScriptPath=%~dp0SetVPNMetricLangan.ps1
PowerShell -NoProfile -ExecutionPolicy Bypass -Command “& ‘%PowerShellScriptPath%’ -ProfileName ‘Company_VPN’ -InterfaceMetric 1”
Richard M. Hicks
/ May 18, 2020So you get the error message “A general error occurred that is not covered by a more specific error code” when you try to provision a new profile? Not when you are running my script Update-Rasphone.ps1, correct?
P.
/ June 5, 2020Very nice guide, however… where can one create (or find?) and edit this ProfileXML file?
Richard M. Hicks
/ June 8, 2020I have a few sample ProfileXML configuration files in my GitHub here: https://github.com/richardhicks/aovpn.
Chris
/ June 13, 2020Thanks very much for the guide, very helpful!
If anyone else has an issue with their routes not being injected as expected, I had this problem today and my issue was that I was editing the profile.xml file then running the PowerShell script to apply my changes, but the routes did not appear.
I did not realise that the script has it’s own profile xml settings within!
E.g. the script ignores the profile.xml file when run manually, and uses XML settings stored in the script itself.
As soon as I modified the contents within the script I could re-run it, VPN was recreated and my routes were injected as expected.
Hope this helps!
calaggan
/ June 15, 2020HI Richard, many thanks for sharing know.
I need to use FQDN fo route the traffic throught my vpn.
i’v setting NRPT table .
Exemple
.whatismyipaddress.com
172.16.5.149
172.16.5.149 is my internal lan dns
This URL is resolve by my internal DNS, its good, but all rest of the traffic passed by my home connection.
I need to route the traffic for one or few url by my vpn but just by URL not IP.
It’s possible ?
Steve
Richard M. Hicks
/ June 18, 2020If you want to route FQDNs over the tunnel you will ultimately have to know what IP address they resolve to, and then include those routes in your VPN client’s routing table. If it is an internal resources that’s pretty easy. If it is an external (public) resource then you’ll have to know all of the IP addresses they use and add them to your route configuration on the client.
Panos
/ June 16, 2020Is there any way to remove access to local lan for user force tunnel?
Thank you
Richard M. Hicks
/ June 18, 2020Not with Always On VPN. Non-Microsoft solutions like NetMotion Mobility do this by default. Always On VPN seems to allow it by default and provides no way to disable it unfortunately.
Gordon Loots
/ June 17, 2020Hi Richard,
in our environment we found this configuration works well:
Configuring the RRAS server to assign IPv4 addresses from a static pool
Add the DHCP role on the RRAS server
Create a scope that matches the static pool range
Add DHCP option 121 to the scope and define the required routes
Configure RRAS with a DHCP Proxy interface set to “Internal”
Add the DMZ Back interface IP address as the DHCP server in the RRAS DHCP Proxy properties
This results the clients being placed into the desired subnet (the static pool) and the required routes are setup on the clients and configured to use the tunnel interface.
This has enabled us to support Windows 7 clients as well as Windows 10. We had an issue with defining routes using CMAK for Windows 7 clients as the route injection required elevation from the user at runtime.
Hope this helps anyone else struggling to support legacy clients as well as Always On with RRAS.
Richard M. Hicks
/ June 18, 2020Indeed it is possible to use DHCP to assign options such as static routes even when RRAS is configured to use static address pool assignment. The configuration is similar to what you’ve described, although I would advise against installing the DHCP role on the VPN server. It is best to use the DHCP relay agent instead. I’ll do a blog post on the proper configuration soon. 🙂
Matt
/ June 23, 2020Hello Richard,
What’s best practice for updating the routes on existing vpn clients? We’re adding a new subnet that clients need access to. We’ll say 192.168.140.0/24. Do I need to push out a new VPNProfile.ps1 file to all the users with
192.168.140.0
24
I am hoping there’s an easier way as deploying the new VPNProfile.ps1 by sccm will disconnect them for a sec while it installs the new configuration
Thank you much,
Matt
Richard M. Hicks
/ June 23, 2020You’ll have to run the Add-VpnConnectionRoute command on all of your clients with the new route.
https://docs.microsoft.com/en-us/powershell/module/vpnclient/add-vpnconnectionroute/
Matt
/ June 24, 2020Ah Perfect. Thank you, Richard!
Justin
/ June 25, 2020Thanks Richard! This worked like a BOSS! Love you work, thanks for all your great posts!
Richard M. Hicks
/ June 29, 2020👍😁
Syed
/ June 26, 2020Hi Richard,
We use split tunneling in our setup, there is a requirement to route certain public hosted URL traffic via VPN tunnel. The website resolves to several different IP addresses based on the region and CDN location. Is there way to define these routes in profilexml where IP addresses keep changing, may be just by FQDN name entry alone. I tried by using Proxy IP:port Number. But this did not work. Can you please advise?
Richard M. Hicks
/ June 29, 2020You can do this (I call it “selective tunneling”) but you must know any/all IP addresses for the resource and they can’t change. You can add their public IP addresses to the routing table on your VPN clients, but if they do change in the future you’ll have to go back and update your client configuration again with the new information.
Syed
/ July 1, 2020Thanks for your response Richard.
There are just too many IP addresses for each URL and configuring every one of them appears to be challenging from operations & management point of view.
Beside adding everything upfront, is there any other alternate option? such as defining just the domain FQDN and using webproxyserver element to route the traffic through proxy?
Richard M. Hicks
/ July 1, 2020Yes, you could certainly force the traffic on-premises using a proxy server. That option seems to be hit-or-miss though, but I’ve had people report success with it.
Andy Wallace
/ July 27, 2020Am i right in my assumption that you should not have overlaping subnets when it comes to user and device tunnel? We have one subnet added to both our device an user tunnel, they both end up with the same metric. Should i try the metric statement in the device tunnel config to ensure they are not the same.
Richard M. Hicks
/ July 28, 2020There’s no need to have unique subnets for device tunnel and user tunnel connections. It shouldn’t be a problem if they have the same metric.
Chris
/ August 24, 2020Hi Richard,
If I want to connect from LAN to a VPN Client (DHCP Range configured via RRAS Server with internal/external Interface) do I just need to route the DHCP Networkrange to the internal interface of the RRAS Server?
Will that work?
Richard M. Hicks
/ August 25, 2020It depends. If you are using a unique IP address pool, yes. If you are using DHCP or an address pool with addresses from the same subnet as the VPN server’s internal network interface, no.