Always On VPN Windows 10 Device Tunnel Step-by-Step Configuration using PowerShell

Always On VPN Windows 10 Device Tunnel Step-by-Step Configuration using PowerShellWindows 10 Always On VPN and DirectAccess both provide seamless, transparent, always on remote network access for Windows clients. However, Always On VPN is provisioned to the user, not the machine as it is with DirectAccess. This presents a challenge for deployment scenarios that require the VPN connection to be established before the user logs on. To address this issue, Microsoft introduced support for a device tunnel configuration option beginning with Windows 10 version 1709 (Fall creators update).

Want to learn more about Windows 10 Always On VPN? Register for one of my hands-on training classes now forming in cities across the U.S. Details here.

Prerequisites

To support an Always On VPN device tunnel, the client computer must be running Windows 10 Enterprise or Education version 1709 (Fall creators update). It must also be domain-joined and have a computer certificate with the Client Authentication Enhanced Key Usage (EKU) issued by the organization’s Public Key Infrastructure (PKI).

Always On VPN Windows 10 Device Tunnel Step-by-Step Configuration using PowerShell

In addition, only the built-in Windows VPN client is supported for Always On VPN device tunnel. Although Windows 10 Always On VPN user connections can be configured using various third-party VPN clients, they are not supported for use with the device tunnel.

VPN ProfileXML

The Always On VPN device tunnel is provisioned using an XML file. You can download a sample VPN ProfileXML file here. Make any changes required for your environment such as VPN server hostnames, routes, traffic filters, and remote address ranges. Optionally include the trusted network detection code, if required. Do not change the protocol type or authentication methods, as these are required.

Always On VPN Windows 10 Device Tunnel Step-by-Step Configuration using PowerShell

Reference: https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/vpn-device-tunnel-config#configure-the-vpn-device-tunnel

Once the ProfileXML file is created, it can be deployed using Intune, System Center Configuration Manager (SCCM), or PowerShell. In this post I’ll cover how to configure Windows 10 Always On VPN device tunnel using PowerShell.

Client Configuration

Download the PowerShell script located here and then copy it to the target client computer. The Always On VPN device tunnel must be configured in the context of the local system account. To accomplish this, it will be necessary to use PsExec, one of the PsTools included in the Sysinternals suite of utilities. Download PsExec here, copy it to the target machine, and then run the following command in an elevated PowerShell command window.

PsExec.exe -i -s C:\windows\system32\WindowsPowerShell\v1.0\powershell.exe

Always On VPN Windows 10 Device Tunnel Step-by-Step Configuration using PowerShell

Another elevated PowerShell window will open, this one now running in the context of the local system account. In this window, navigate to the folder where you copied the PowerShell script and XML file to. Run the PowerShell script and specify the name of the ProfileXML file, as shown below.

VPN_Profile_Device.ps1 -xmlFilePath .\profileXML_device.XML -ProfileName DeviceTunnel

Always On VPN Windows 10 Device Tunnel Step-by-Step Configuration using PowerShell

To verify creation of the VPN device tunnel, run the following PowerShell command.

Get-VpnConnection -AllUserConnection

Always On VPN Windows 10 Device Tunnel Step-by-Step Configuration using PowerShell

Note: Be advised that the ConnectionStatus is always Disconnected. Hopefully this will be addressed by Microsoft in the near future.

Server Configuration

If you are using Windows Server 2012 R2 or Windows Server 2016 Routing and Remote Access Service (RRAS) as your VPN server, you must enable machine certificate authentication for VPN connections and define a root certification authority for which incoming VPN connections will be authenticated with. To do this, open an elevated PowerShell command and run the following commands.

$VPNRootCertAuthority = “Common Name of trusted root certification authority”
$RootCACert = (Get-ChildItem -Path cert:LocalMachine\root | Where-Object {$_.Subject -Like “*$VPNRootCertAuthority*” })
Set-VpnAuthProtocol -UserAuthProtocolAccepted Certificate, EAP -RootCertificateNameToAccept $RootCACert -PassThru

Always On VPN Windows 10 Device Tunnel Step-by-Step Configuration using PowerShell

Summary

Once the Always On VPN device tunnel is configured, the client computer will automatically establish the connection as soon as an active Internet connection is detected. This will enable remote logins for users without cached credentials, and allow administrators to remotely manage Always On VPN clients without requiring a user to be logged on at the time.

Additional Information

Configure Windows 10 VPN Device Tunnel on Microsoft.com

3 Important Advantages of Always On VPN over DirectAccess

5 Things DirectAccess Administrators Should Know About Always On VPN 

Windows 10 Always On VPN and the Future of DirectAccess

Windows 10 Always On VPN Training and Consulting Services

Leave a comment

336 Comments

  1. Michael de Cler

     /  December 18, 2017

    We are experiencing issues where, once the device tunnel is created, the user profile does not connect when logged on. It tries to connect for about 5 times and then stops. Seems that the devicetunnel is preventing the user tunnel. When we disconnect the devicetunnel on the server the user tunnel becomes online within seconds.

    Secondly, seems that the devicetunnel never disconnects. Even when we reboot the device the tunnel remains. At some point there were 8 (!!) different tunnel open.

    Please advise..

    Reply
    • Unusual for sure. 🙂 Did you use the trusted network detection option for your user tunnel? I’m wondering if the device tunnel might be interfering with it that way. I’ve not seen where there are multiple device tunnels though! I’ll continue to test and let you know what I find, if anything. 🙂

      Reply
    • Azad Sofi

       /  March 6, 2018

      Hi Michael,

      Issue identified was : you had been using the route for management server and DC as same and device tunnel once up was able to reach to internal domain resources which should not happen on device tunnel.

      the change that we did was to create a new subnet/route for management server.

      I hope you are able to work with Always on VPN after we fixed it.

      Regards,
      Azad Sofi
      Support Engineer Microsoft Networking

      Reply
  2. Nico Junge

     /  December 22, 2017

    The device tunnel is not sufficient? An additional user tunnel is needed for the user to access corporate resources? So two profiles have to be rolled out onto each notebook? Did I get this right?

    Reply
    • The Windows 10 Always On VPN device tunnel is designed to enable domain log on without cached credentials, and a few other scenarios. With that, it should be configured with limited access. Yes, a logged on user would have access to whatever is allowed over the device tunnel, but it really shouldn’t be full network access. That would be granted by the user tunnel after authentication takes place. However, if you want to open up the device tunnel to all traffic I guess you could do that and use one tunnel, but I really wouldn’t recommend it from a security perspective. 🙂

      Reply
  3. Hi Richard,

    We are only having the device tunnel enabled (no user profile).

    Everything works alright until we reboot the device after we have applied the VPN profile.

    Nothing shows in the logs, besides it actually says the profile was successful connected. But in “Network Connections” it’s stuck in connecting and the machine doesn’t get any IP.

    I can force the connection and get it to work if I first disconnect, and then reconnect again using utility rasdial.exe in a command prompt:

    rasdial.exe “” /disconnect

    rasdial.exe “”

    We are using the sample XML file (with relevant connection details substituted) found here:

    https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/vpn-device-tunnel-config#configure-the-vpn-device-tunnel

    The profile was made in the “SYSTEM” context, as you pointed out.

    Any ideas?Kind Regards Alex

    Reply
    • Interesting. I’m having issues with the Always On VPN device tunnel as well, but something different. On my test machines the client will connect without issue, but when I restart it will never reconnect. There are errors in the event log indicating related services are failing to start, so I suspect it is a bug. It is likely the same in your case. :/

      Reply
      • Hi Richard,
        Thanks for replying, sounds like the same issue. I think I will open a Microsoft support ticket, and post the details (and a solution) if we succeed to resolve the issue. I will keep you updated.

      • Did this ever get resolved?

      • Not to my knowledge, but Microsoft is aware so I suspect something will be forthcoming. I did some further testing and it appears the issues I was experiencing were only happening on Windows 10 virtual machines. The device tunnel seems to work perfectly on all of my physical Windows 10 devices though. 🙂

      • Thanks. So far it happens on all of my physical devices. Clearly it does talk to the server because a new connection shows up in RRAS. If I disconnect it from the RRAS gui quickly, the client will reconnect and work… if I wait a while before disconnecting, it will just go to disconnected state on the client and never try to reconnect.

        If I have both a User tunnel and a device tunnel configured, the User Tunnel will never connect automatically… but what’s really messed up is that the device tunnel will show the domain name rather than “connecting” … it looks like the tunnel would should be working. But still, it doesn’t work without killing/restablishing the connection.

        The change in behavior when both tunnels are present is curious. I’ve been through everything I can think of three times… nothing I do has any effect other than to break it entirely. 🙂

      • Sounds frustrating for sure. What I might suggest is that you don’t use TrustedNetworkDetection at all, either on the device tunnel or the user tunnel. It would be interesting to see if that clears up your automatic connection issues. If you are concerned with clients connecting to the VPN when they are on the internal network, just make sure they can’t resolve the VPN’s public hostname to an IP address, or black hole it by resolving it to a bogus IP. If you try either of those let me know how it works!

      • J

         /  March 2, 2018

        Thanks for the suggestions, I tried those permutations and a few others. Unfortunately no change. Hopefully Patch Tuesday will bring a present.

  4. Peter Enoch

     /  January 1, 2018

    Hi Richard, the requirements for Always On VPN for the User mode is not Windows 10 Enterprise licenses, is there a reason that Enterprise licenses is needed for Device mode?

    Reply
    • The Windows 10 Always On VPN device tunnel feature is designed to provide pre-logon network connectivity to support domain logons when cached credentials are not available. It was implemented specifically to provide feature parity with DirectAccess, so Microsoft made the decision to restrict it to Windows 10 Enterprise edition.

      Reply
  5. Hi Richard, I am looking to move my RAS environment to Azure as this is where most of my apps now reside. RRAS isn’t currently supported in Azure so my only option to do always-on VPN is use a supported 3rd party product such as F5 APM (I believe). However a lot of development is going into the native Azure VPN Gateway with regards to increasing user limits and authentication methods. Would an always-on device tunnel work to an Azure VPN Gateway?

    Reply
    • Yes, you could deploy a third-party appliance, but obviously that adds cost and administrative overhead. Indeed it should be possible to use the Azure VPN gateway with Windows 10 Always On VPN. It supports IKEv2 and now with RADIUS support I think it should work. It’s not something I’ve tested myself yet, but its on my list. I’ll be sure to post something here once I do.

      Reply
  6. Hi again,

    Is it possible to configure something similar as NPRT in DirectAccess with Always On VPN.

    We are using split DNS in our environment, this will cause the client to lookup resources through the tunnel. We really only want Active Directory, SCCM and similar connections and not web pages etc.

    Kind Regards Alex

    Reply
  7. Matthew

     /  February 5, 2018

    Can Always On VPN with pre-logon device tunnels be configured to connect through an existing Cisco ASA infrastructure instead of setting up RRAS servers for clients to connect through?
    We don’t want to throw away our investment in ASA hardware, but we would like to be able to get rid of the Cisco AnyConnect software and login steps on domain-joined systems.

    Reply
    • As long as you use IKEv2 with machine certificate authentication, and you use the built-in Windows 10 VPN client to establish the connection, then yes it should work. It’s not something I’ve tested myself yet though, but in theory it should work. 🙂

      Reply
  8. Tony

     /  February 16, 2018

    Do you know of any guidance for deploying the Device Tunnel using Intune?. I have successfully deployed the user tunnel this way but it is straight XML

    I can also confirm same issue with User VPN not connecting when the Device Tunnel is connected, in my case if I had my DCs in the routes then User tunnel would not connect if ‘trustednetworkdetection’ was set.

    If I removed the DCs from Device Tunnel then it would connect but no user could authenticate to logon to machine.

    Reply
    • You deploy the device tunnel in Intune just as you would the user tunnel, with the exception that you’ll use the ./Device/Vendor/MSFT/VPNv2/ OMA-URI instead of ./User. Also, if you are using the device tunnel, it is recommended that you not enable the option to use trusted network detection on the user tunnel to avoid the problem of detecting the device tunnel as the internal network. To prevent the user tunnel from establishing itself on the internal network, make sure your clients can’t resolve the VPNs public hostnmame or that they can’t reach the VPN server instead.

      Reply
  9. Tony

     /  February 19, 2018

    Thanks for that Richard, much easier than I thought and it’s working like a charm now. Also the Trusted Network Detection makes perfect sense, our vpn name is not resolvable internal so there was no requirement for it.

    Reply
  10. Tony

     /  February 20, 2018

    Thanks for this Richard, working well for me now.

    Regarding Proxies – In our DirectAccess we specified the Proxy server in the NRPT rule for certain external websites that only allowed access via our internal network . This worked great but it doesn’t seem to work for me using
    in the XML for AlwaysON. Is it the same concept? I see no traffic going to the proxy server which is internal. On DirectAccess we can see the traffic coming from the DIrectAccess servers internal network.

    Reply
    • It should be. There are two places to define a proxy serer – at the connection level and at the namespace level. Try adding the domain in the DomainNameInformation tag and then define your proxy under WebProxyServers. Let me know how that works!

      Reply
      • Tony Wood

         /  February 22, 2018

        Thanks Richard, I have that in the vpn profile xml, but it prevents the page from loading. Does the proxy server need to be external facing? Our current proxy setup with DirectAccess is internal only.

      • No, it should be an internal proxy server reachable over the VPN connection.

  11. Andrew

     /  February 21, 2018

    I assume it is possible to lock down configuration for users so that either you have the tunnel and connect through your corporate infrastructure or you have no internet access at all?

    Reply
    • That’s correct. Keep in mind that when you enable lockdown VPN that it must be a device profile and you can’t have any other VPN profiles configured. And as you noted, the behavior will be such that the user will have no network access at all unless the VPN connection is established.

      Reply
  12. Eric

     /  February 25, 2018

    Can you confirm why we need to run this command? Seems like it bypass NPS authentication by doing this?

    $VPNRootCertAuthority = “Common Name of trusted root certification authority”
    $RootCACert = (Get-ChildItem -Path cert:LocalMachine\root | Where-Object {$_.Subject -Like “*$VPNRootCertAuthority*” })
    Set-VpnAuthProtocol -UserAuthProtocolAccepted Certificate, EAP -RootCertificateNameToAccept $RootCACert -PassThru

    Reply
    • NPS isn’t used when using machine certificate authentication is used. However, this command simply tells the RRAS server which root CA to trust for machine certificate authentication. With out it, you would have to delete all root CAs on the server except your internal CA. Otherwise your VPN server would accept a client authentication certificate from any of its trusted CAs, which includes many public CAs. Not a good idea at all. 🙂

      Reply
  13. Mincey

     /  February 28, 2018

    We have a setup with both a device and user tunnel in operation. It works well, apart from one fairly major issue and I was wondering if a supported solution had been identified. I can see comments above and I am curious if anyone is experiencing the identical issue.

    Firstly, we have tried to set things up with the ‘Trusted Network Detection’ only in the device tunnel config, as had been recommended above. This seems work well when outside of the corporate network, and the user tunnel automatically connects. However, with ‘Trusted Network Detection’ missing from the user tunnel config we can see entries in the event log of repeated attempts to connect to the VPN when the computer is in use on our corporate network. These bursts of activity can be 3-4 minutes apart and seem to continue for as long as the machine is connected to the corporate network.

    Therefore, we would ideally prefer to keep ‘Trusted Network Detection’ in the user tunnel config to prevent the repeated failed attempts at connecting to the VPN. The issue with keeping ‘Trusted Network Detection’ in the user tunnel config is that after a device tunnel has been established and the user logs on then the user tunnel is not automatically connected. The user would have to manually connect to the VPN. Admittedly this isn’t the end of the world, but it isn’t ideal for a large workforce currently using DirectAccess that works automatically, so being cut across to AlwaysOn without automatic VPN connection will appear like a backward step.

    We are attempting a workaround at the moment. It’s very much a ‘work in progress’ but we have had a bit of success. However, we would be very interested in a reliable, supported solution if there happens to be one. So far, any queries to our local Microsoft Support hasn’t provided us with any solution, so hopefully someone here might have the answer?

    Reply
    • You’re not alone with this experience for sure. 😉 Another solution to consider is preventing Always On VPN clients from resolving the VPN public hostname when they are on the internal network. Alternatively, you could black hole those DNS queries to prevent client machines from establishing VPN connections when they are on the internal network. That would solve the issue without the need for enabling TrustedNetworkDetection on either the device or user tunnel.

      Reply
  14. yannara

     /  March 1, 2018

    The challenge seems to be around AOV, that no one cares to run VPN service based on Windows Server. Also, it is uknown what VPN vendors (Cisco, Citrix) do support this type of protocol today.

    Reply
    • That’s not true at all. Many customers have deployed and are deploying VPN servers using Windows Server 2016. In fact, there are some very compelling reasons to do so as I outlined in this recent blog post: https://directaccess.richardhicks.com/2018/01/02/always-on-vpn-and-windows-routing-and-remote-access-service-rras/. The good thing about Windows 10 Always On VPN is that you aren’t locked in to use a Windows server. If you decide you want to implement using a purpose-built security appliance, that’s entirely up to you. In fact, ANY VPN server that supports IKEv2 will work with Always On VPN. Also, any VPN that has a Windows store VPN plug-in available can also be used for Always On VPN. Some popular solutions are SonicWALL, Juniper Pulse, Fortinet Fortigate, Palo Alto Networks, Checkpoint, and F5 APM just to name a few. You definitely have options!

      Reply
      • Tony

         /  March 5, 2018

        I’ve just set this up via Netscaler Load Balancer. While testing failover the device tunnel seamlessly reconnects to the other RRAS server but the user tunnel just disconnects and stays that way until I manually connect. Is there something else I need to configure here?

      • Not sure. If you are successfully getting the device tunnel to failover, I see no reason why the user tunnel wouldn’t do the same, assuming they are using the same protocol. Keep in mind that load balancing IKEv2 presents some unique challenges when the VPN server is behind a NAT. This is because both ports 500 and 4500 must be delivered to the same real server, which is challenging because it is UDP. Most ADCs have a way of dealing with this, but it differs depending on the vendor. You’ll have to refer to their documentation for guidance.

  15. Marko

     /  March 7, 2018

    Hey,
    is it possible to configure a fallback to SSTP when IKEv2 is blocked ?
    Thanks !

    Reply
    • Absolutely! Just specify “automatic” for the NativeProtocolType in your ProfileXML.

      Reply
      • Eric Yew

         /  July 30, 2018

        Can SSTP utilise Machine Certificate? If yes, how would this be configured as the option isn’t there.

      • It cannot. Machine certificate authentication is not supported natively by the protocol.

      • Colin

         /  October 16, 2018

        My experience with this is that setting the profile to “automatic” just uses SSTP even when it the client is fully capable of connecting with IKEv2.

        Have others here had the same experience? It leads me to believe that failback to SSTP from IKEv2 is not possible.

      • That’s correct. Hoping that Microsoft will address this limitation in a future release. 🙂

      • Colin

         /  October 22, 2018

        I’m not sure if this helps or if anyone else can confirm but from my testing if I manually edit the profile xml file and add “Automatic” or “automatic” it favors SSTP. However, if I create a new template profile with Automatic selected in the template, it seems to go to IKEv2 like expected. *shrugs*

  16. Matthew

     /  March 10, 2018

    I see the requirement for clients to establish device tunnels is domain-joined with machine certificates and be running Windows 10 1709 Enterprise.
    We have vendors we would like to provide VPN access to from their corporate laptops that belong to an unrelated, untrusted domain.

    Would those users be able to use out Always On VPN to establish USER tunnels to access our internal LAN/Intranet/File shares etc. from older versions of Windows 10 or even Windows 7 using their built-in Windows VPN settings and user certificates instead of computer certificates?

    Reply
    • The device tunnel was designed to provide feature parity with DirectAccess, hence the requirement for Windows 10 Enterprise edition. That said, you can enable Always On VPN user tunnels for any Windows 10 device. Although user certificates are the recommended best practice for authentication, it is not a hard requirement. You could enable Always On VPN using username/password, although the first connection would not be seamless/transparent. The user would have to enter their credentials the first time, then subsequent connections would not require user interaction. This would easily allow you to provide Always On VPN to users outside your organization.

      Windows 7 is another story. There is no support for Always On VPN in Windows 7 at all. However, you can easily configure Windows 7 clients to establish VPN connections using whatever parameters you choose (certificates, username/password, etc.), it just won’t be “Always On”. The user would have to manually establish the connection each time they needed remote access.

      Reply
  17. Matthew

     /  March 15, 2018

    Will Always On VPN work on Windows 10 Enterprise systems running in “S Mode?”

    Reply
  18. Christian

     /  March 15, 2018

    Hey,
    at first thx for your nice work 🙂 but i still have an Error ID 13806 in the Event Log
    The Certificates are still there, and issued to the Server but the Issuer is my Enterprise Sub-CA
    I have an offline standalone root CA and an Enterprise subordinate CA.

    Can you help me by this?
    Thx a Lot

    Christian

    Reply
    • The certificate can be issued by any CA that is trusted. Make sure that both certificates (server and client) have the Client Authentication EKU. As long as they are issued from a trusted CA it should work (assuming the RRAS configuration is correct too, of course).

      Reply
  19. Johnny M. Forp

     /  March 23, 2018

    I am trying to get a device tunnel with routes/traffic filters to the DC’s and public fileserver (192.168.3.20/32, 192.168.3.21/32, 192.168.3.23/32). If I’m logged in as a user with the user tunnel disconnected, the connection to these device routes works fine. I can communicate with those hosts. If I’m at pre-logon, I’ll have 4-5 connections to the RRAS server from the device tunnel and the connection is not working properly. On my RRAS server each connection states “Total Bytes In: 0” which tells me something is not transmitting back to the client properly. However, once the system logs in, the tunnel works fine.

    Once the user tunnel connects on the same machine (192.168.2.0/23 [possible routing conflict or no? I have same setup using OpenVPN no issues], and 10.10.200.0/23), both of the connections are working fine and ONE of the device tunnels which had “Total Bytes In: 0” consistently shows activity. The other device tunnels remain dormant. I need group policy to apply and network shares to mount on boot.

    Another issue causing me even issues testing is that if I don’t login as a user quickly after a reboot, my NRPT keeps getting corrupted causing all connections to my RRAS server to fail for 30 min. I imagine it’s because the device tunnel tries to connect every 2-3 seconds and something is bugging out (relation to “Total Bytes in: 0”?)

    Overall, I think there’s an issue with the device tunnel but it works fine when testing logged in. Pulling my hair out trying to fix these 2 issues and have spent way too much time on this project. Any ideas?

    Reply
    • I know the Always On VPN device tunnel hasn’t been entirely stable based on a number of reports. You might be encountering some of those issues. In my testing it has been working ok so far, but enough others are complaining that I think something might be up. I’d caution you that if you are using Trusted Network Detection in your ProfileXML, that could be causing some problems, especially if it is specified on both the device tunnel and user tunnel. Would recommend only using it on the device tunnel, if at all.

      Reply
      • Johnny M. Forp

         /  March 23, 2018

        Wish they would get the kinks worked out as I greatly prefer this over some of the alternatives. Thank you for the response!

      • Hopefully soon. 🙂

  20. Sossage

     /  March 29, 2018

    Hi Richard,
    Great guides as usual, thank you.
    We are trying to deploy AlwaysOnVPN via GPO/Powershell/Intune in a corporate environment. We get a couple of issues:-
    1. You say the powershell scripts to import the XML config needs to be run under SYSTEM user? i.e. not user?
    2. Is there a way of configuring a proxy just on the VPN/dial-up connection that actually gets encapsulated in the config file? This never seems to work and we always need to configure manually. We can se ta general proxy, just not specifically on the dial-up connection.
    Cheers.

    Reply
    • Only the device tunnel needs to be deployed under the SYSTEM account. The user tunnel is deployed as the user, albeit with administrative privileges. As for the proxy configuration, you should be able to add that under ./User/Vendor/MSFT/ProfileName/Proxy. You can choose manual or autoconfig. Optionally you can define a proxy server by individual namespace or FQDN under ./User/Vendor/MSFT/ProfileName/DomainNameInformation/WebProxyServers.

      Reply
  21. Andy

     /  April 6, 2018

    Windows 10 1709 with the latest March 2018 updates.

    I have setup the device tunnel on a few physical laptops. It works BUT the device tunnel always crashes after logging on (no matter if there is a user tunnel configured or not):

    The Remote Access Connection Manager service terminated unexpectedly. It has done this 1 time(s). The following corrective action will be taken in 120000 milliseconds: Restart the service.

    Faulting application name: svchost.exe_RasMan, version: 10.0.16299.15, time stamp: 0x9c786b9a
    Faulting module name: msvcrt.dll, version: 7.0.16299.125, time stamp: 0x20688290
    Exception code: 0xc0000005
    Fault offset: 0x000000000005b893
    Faulting process ID: 0x1360
    Faulting application start time: 0x01d3cdbd900eb67c
    Faulting application path: c:\windows\system32\svchost.exe
    Faulting module path: C:\WINDOWS\System32\msvcrt.dll
    Report ID: 7399725d-1cdb-4447-8137-c9fc45e86952
    Faulting package full name:
    Faulting package-relative application ID:

    Fault bucket , type 0
    Event Name: APPCRASH
    Response: Not available
    Cab Id: 0

    Problem signature:
    P1: svchost.exe_RasMan
    P2: 10.0.16299.15
    P3: 9c786b9a
    P4: msvcrt.dll
    P5: 7.0.16299.125
    P6: 20688290
    P7: c0000005
    P8: 000000000005b893
    P9:
    P10:

    Attached files:
    \\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER7EC0.tmp.mdmp
    \\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER8CBC.tmp.WERInternalMetadata.xml
    \\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER8CBA.tmp.csv
    \\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER8CCB.tmp.txt
    \\?\C:\Windows\Temp\WER8CDC.tmp.appcompat.txt
    C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_svchost.exe_RasM_da58269ec0c690daebc26797612e62ba4d950e8_9c1a5be5_cab_10dd8dd3\memory.hdmp

    These files may be available here:
    C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_svchost.exe_RasM_da58269ec0c690daebc26797612e62ba4d950e8_9c1a5be5_cab_10dd8dd3

    Analysis symbol:
    Rechecking for solution: 0
    Report ID: 7399725d-1cdb-4447-8137-c9fc45e86952
    Report Status: 4
    Hashed bucket:

    Is anybody else having this issue?

    Reply
  22. Hi Richard,

    I tried to follow your step by step procedure to implement the VPN tunnel device but it does not work. For information, I tested the solution in virtual environment without Internet connection.
    is it an obligation to have an Internet connection from the client computer?
    the external IP address used on the RAS server is an IP address ‘192.168.100.1’. This is not a public IP address.

    in your comments, tell you to position ./Device/Vendor/MSFT/VPNV2: ……..
    I do not know how to set this parameter

    I do not know how to set this parameter in the XML file, can you give me a concrete example please?

    Thank you very much

    Patrick

    Reply
  23. Hi, Wondering how/where in the XML profile to add NRPT rules? For example, some FQDN’s for things like OWA, and our DMZ Webserver, I wouldn’t want to go through the VPN. How would we add these exceptions?

    Reply
    • You can enable the NRPT by adding the DomainNameInformation element in your ProfileXML. Details here: https://directaccess.richardhicks.com/2018/04/23/always-on-vpn-and-the-name-resolution-policy-table-nrpt/.

      Reply
      • Sounded good in theory. In reality, even with the missing element for the FQDN, I’m still getting internal resolution. I even tried putting the “exceptions” ahead of the elements that include the DNS Server, in the profile, so it would maybe find a match and use external, but no go.
        EXAMPLE

        exception.domain.com

        .domain.com
        192.6.1.X

      • Unusual, because it has worked for me in the past. Are you using the device tunnel also? I’m wondering if perhaps the name resolution request is somehow leaking over the device tunnel.

      • I haven’t been able to get the Device tunnel to work as of yet, so no. But after getting the NRPT working, that will be my next and final task before testing with pilot users.

      • Strange, I removed all the DomainNameInformation DNS related tags out of the profile, and am still getting full internal resolution.

      • That’s to be expected. The VPN connection will be assigned a DNS server by the VPN server. The NRPT is only required if you want need to define specific DNS servers to specific namespaces.

      • So it seems that if I define an external DnsServer tag (1.1.1.1), I will then get external resolution, but for me, simply removing the tag for the specified FQDN results in internal resolution still through the VPN tunnel.

      • That’s odd. Definitely not been my experience. :/

  24. Yikes, what a mess judging from the comments here and elsewhere! Sounds like DirectAccess is still the way to go for the time being…

    Reply
    • I’ll agree that some of this technology isn’t quite fully baked at the moment, but hoping it will get better soon for sure. 🙂

      Reply
  25. ND

     /  April 20, 2018

    Hi Richard,

    Your posts have helped me understand things so many times thank you. I have a question:

    We have implemented always on VPN a few times without issue, however on a recent implementation we found that after having used the makeprofile script to create a VPN profile using VPN_profile.ps1 the clients were auto connecting OK but weren’t able to get to any network resources. (When we created a successful manual connection we did have connectivity to internal resouces). We used the Microsoft Documentation: https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/always-on-vpn-deploy-deployment for configuring the servers and clients.

    We deduced that the issue we were seeing was because of the network configuration we were working on and the fact that when auto connecting we were split tunneling. We ended up finding this article: https://docs.microsoft.com/en-gb/windows/client-management/mdm/vpnv2-profile-xsd and realising we might have to put some routes in to the makeprofile script to feed in to the VPN profile script and profile on the clients to get the connectivity to work. We did this and it worked.

    It is not massively clear from the Always on documentation that this is what you have to do as part of the client config, can you confirm that we are doing the right thing by adding the routes in to the script as your article seems to agree with this? It strikes me if there was a route issue and the VPN clients needed updated routes adding you would have to re run the scripts and deploy the profile again?

    Thank you.
    ND

    Reply
    • Agreed, the Always On VPN documentation on the Microsoft web site is highly unintuitive. 🙂 It’s one of the reasons my Windows 10 Always On VPN hands-on training classes have been so popular (shameless plug!). You are right, there will be times when you need to define routes to remote internal networks in the ProfileXML. Hope that helps!

      Reply
      • Andy

         /  April 23, 2018

        Would you recommend the following as our network team doesn’t tell us about new networks:

        10.0.0.0
        8

        172.16.0.0
        12

        192.168.0.0
        16

      • That would certainly work. 🙂

      • ND

         /  April 23, 2018

        Hi Richard, Thanks for verifying what we already thought was the case. If I was anywhere near Denver or NY I’d be on the training course like a shot! Regards ND

      • Well, if you can get a few of your mates together I’d love to come to the UK and deliver the class. Perhaps it could even be sponsored by Risual? 🙂

  26. ced666

     /  April 23, 2018

    Hi Richard,

    thank you very much for your quick return. Indeed, after simulating the internet network, the device tunnel connection works. Is it possible to configure Full tunneling in tunnel device mode? I configured the ForceTunnel section but it does not work. I want all flows to be routed to the corporate network.

    is it possible to configure this in tunnel device mode?

    For information, the bug declared in the tunnel device mode 1709 after reboot is no longer relevant in the 1803 version.

    Thank you.

    Patrick

    Reply
    • You should be able to specify force tunneling by defining that in the RoutingPolicyType element in your ProfileXML. It’s not something I’ve tested myself, but it should work I would expect. I’ll do some testing myself soon and see what I find.

      Reply
  27. ced666

     /  April 24, 2018

    Hi Richard,
    thank you for your return, I indicated in the configuration file the “RoutingPolicyType” section in ForceTunnel and yet I enter the command get-vpn connection -alluserconnection, I see that the value of the SplitTunneling attribute is always True . I’m still able to access my shares live outside the corporate network.
    Thank you.

    Patrick

    Reply
  28. Hello Richard,
    is it possible in tunnel device mode to pass an Internet connectivity so that the tunnel is automatically mounted in the corporate network without Internet. The idea is to be able to mount a VPN tunnel (device mode) without Internet connectivity. One can very well imagine to impose the VPN tunnel even in his company. Can we use triggering by DNS names, ie trigger the VPN as soon as there is a network connectivity (in the company or outside?)

    Thank you

    Patrick

    Reply
    • I’m not entirely clear about what you are asking, but I think you are looking for something called “LockDown” mode. When LockDown is enabled, the device will not be able to access the internet unless the VPN connection is established. Also, all traffic is tunneled over the VPN (force tunnel). Is that what you were looking for?

      Reply
  29. Matt

     /  May 5, 2018

    Hi Richard,

    Thanks for all your hard work with this stuff, it’s been so helpful.

    I’m posting to bring your attention to a bug in the user tunnel that MS have just confirmed. You may know about it already but I’ve not seen anything on the web about it.

    In Windows 10 1709, when using the always on feature in an IKEv2 user tunnel, the automatic trigger dials the connection under the SYSTEM context. This causes an authentication failure on the NPS due to an incorrect certificate being used. Dialling manually runs in the user context and will connect the tunnel successfully.

    I logged a call with MS and they have confirmed the bug. They say they’re hoping to patch it in June.

    Workaround for now seems to be to use an SSTP tunnel instead, which seems to work.

    Cheers,

    Matt

    Reply
    • Thanks Matt! This tunnel has been known for some time, and in fact Microsoft has resolved it in the latest update, 1803 (RS4). Also, to be clear, the device tunnel only supports IKEv2. You cannot create a device tunnel using SSTP, only user tunnels.

      Reply
      • Tony

         /  May 7, 2018

        Is Matt talking about another issue here as he’s mentioning the user tunnel as opposed to the known device tunnel issue?

        On another note is there a way to get the client to automatically reconnect when they lose connection to the RRAS? It works fine if the internet connection is lost and reestablished but if connection interrupted due to RRAS reboot for example the client doesn’t reconnect either tunnel.

        Thanks Tony

      • I thought he was talking about the device tunnel. I’m not aware of any specific issues regarding the user tunnel. As for automatically reconnecting, I would expect the client to reconnect regardless of the cause. I’ll do some testing when time permits and see if I have the same experience.

    • Mike

       /  May 7, 2018

      I’ve notice since updating to 1803, The user tunnel connects with SSTP instead of IKEv2.

      Reply
      • If you’ve configured NativeProtocolType to be “Automatic”, then the client will first try to establish a connection using IKEv2. If that fails for any reason, it will fall back to SSTP. It would appear that an IKEv2 connection was unsuccessful at some point, resulting in the client connecting with SSTP. Curious though, are you able to manually establish an IKEv2 connection?

      • Mike

         /  May 10, 2018

        Just tried it after the 1803 cumulative update. Yes, I can manually establish an IKEv2 connection.

      • Ok, good. I’d suggest removing the Always On VPN connection and then re-adding it. It should automatically choose IKEv2, assuming it is available. However, understand that the default behavior of the VPN client in Windows is to fall back to SSTP, but then subsequent connection attempts will always be made using the last successful protocol. If that was SSTP, it will be tried first! In reality that means that it will most likely always use SSTP, because it’s hard to conceive of a scenario in which SSTP isn’t available but IKEv2 is. 😉

    • Matt

       /  May 10, 2018

      Hi all,

      I was talking about the user tunnel and it does indeed work with 1803. The problems i am seeing relate to the ‘alwayson’ setting on the user tunnel on 1709. When set to true, on network switch, unlock, or logon It will dial under the SYSTEM context and therefore attempt to authenticate with the machine certificate (not the user PEAP-based cert). If the device tunnel is up, the VPN server terminates the connection as the device is already connected and authenticated with its machine certificate. I logged a call with an MS breakfix team and they confirmed the bug.

      On another note and in response to Mike, i’ve noticed that when the profile is set to ‘automatic’ if the tunnel has to fall back to SSTP for some reason and establishes a connection, it will bump that protocol to the top of its preferred list and use SSTP as its first option on the next connection attempt. I’ve not looked into why this happens yet but any input would be great!

      Matt

      Reply
      • Ok, that’s news to me then. Definitely update us if Microsoft provides a workaround or fix. Also, the behavior you describe where the VPN client always prefers the protocol used during the last successful connection attempt is expected and by design. Not a good design if you ask me, but that’s what it is. 🙂

  30. MaxG

     /  May 7, 2018

    Hello Richard
    We have an IKEv2 deployment which is load balanced behind a Netscaler LB Server. The allowed ports are UDP 500 and UDP 4500, but he have an issue here. The connection will succeed, but there is no traffic in the tunnel and Windows 10 client sets the network as Private profile. If manually update the network profile to be a domain network it will work perfectly. Have you had any issues load balancing with Citrix Netscaler? Any other suggestions?
    Thanks.

    Reply
    • If you can establish a VPN connection one the Domainprofile but not on the Private profile, I would have to assume that the Private profile is blocking outbound VPN connections. I’d look closely at the firewall configuration and see what’s up. If you can connect at all, the load balancer is likely configured correctly. 🙂

      Reply
  31. Hello Richard,

    thank you for your comeback.

    I want to implement the trigger of the tunnel device as soon as a network connectivity is detected not necessarily an Internet connection.
    I set up the LockDown mode, unfortunately the tunnel device does not mount until the NCSI component detects an Internet connection.
    In summary, the Device tunnel is automatically mounted when the NCSI component detects Internet connectivity. Is there a possibility of
    to bypass the Internet detection (NCSI) so that the tunnel is mounted automatically (inside or outside the company)?

    Thanks in advance.

    Patrick

    Reply
    • Not to my knowledge. However, it might be possible to spoof NCSI and point it to itself so that it is always detects an Internet connection. I have no idea what sort of unintended consequences that would bring, but it might be interesting to experiment with!

      Reply
  32. Dan

     /  May 15, 2018

    Hi Richard,
    Are you aware if the Trusted Network Detection bug has been fixed in 1803? I would like to enable Trusted Network Detection for both the user and device tunnels but am currently unable to do so as the user tunnel never connects.
    Thanks

    Dan

    Reply
  33. ced666

     /  May 15, 2018

    Hello Richard,

    I set up a VPN tunnel device connection with LockDown mode. I would like to delete the VPN connection but it is impossible via the get-vpnconnection -alluserconnection | remove-vpnconnection -force. Access is denied and yet I am well connected with pstools with the localsystem account. Do you have an idea ?

    Reply
    • Interesting. I’ve not yet used the lockdown mode yet. However, you should be able to delete the connection once it is stopped. I’d suggest using rasdial.exe [connection name] /disconnect and then using PowerShell to remove the connection. Let me know what happens!

      Reply
      • Mike

         /  May 17, 2018

        I had difficulty deleting the device tunnel as well. I found that rebooting the PC then quickly disconnecting the connection, then delete the connection, finally removed it.

      • ced666

         /  May 17, 2018

        I tried to disconnect the VPN tunnel under Local System but the prompt is no longer responding. Even after disconnecting the network cable, disconnection via the rasdial command is not possible, as well as deletion. Thank you for your help.

  34. Hello,

    did you try to delete a VPN connection in LockDown mode? As stated in my previous posts, even with a card offline, deleting the network card is impossible.
    Do you have an idea ?

    Reply
    • I have not done any testing with lockdown mode. At this point I’ve not come across a requirement for its use.

      Reply
    • ced666

       /  May 22, 2018

      Hello,

      I just ask through the Forum if it is possible to delete a VPN connection ‘Device Tunnel’ which was done in LockDown mode under the LocalSystem context.For my part, I can not delete the VPN connection even when the card physical is disconnected, I have the message “Access Denied.” However, I did try manipulation under the administrator or localSystem context.
      I’m just wondering if you have a procedure to delete a LockDown VPN connection without restoring the machine.

      Reply
      • That’s unusual. However, I have no experience with the lockdown configuration. I’ll do some testing soon though to see if I can replicate your issue. You should be able to delete the connection, of course. How that’s done I’m not certain of right now. Stay tuned!

  35. ced666

     /  May 18, 2018

    Hello,
    Have you ever used the “trustedNetworkDetection” directive? in tunnel device? I read that this and direftive only works with a wireless connection (see link https://docs.microsoft.com/en-us/windows/client-management/mdm/vpnv2-csp).
    Have you managed to run the “trustedNetworkDetection” mode with a network card?
    Thanks in advance.

    Reply
    • Yes, I’ve used the TrustedNetworkDetection element before. I think the use of the term “wireless” in the VPNv2 CSP documentation is misleading though. It should work with any physical adapter on the device, both wired and wireless. When enabled, the VPN compare the string defined in TrustedNetworkDetection to the connection-specific DNS suffix on any physical adapter. If detected, the VPN will not initialize.

      Reply
      • Hello,
        I tested the directive mondomauine.com and I notice that the tunnel is mounted anyway. However, on the physical interface, I have the DNS suffix “.mydomain.com” via the ipconfig command. Do you have an idea ?

      • If your physical adapter has the suffix “.mydomain.com” then your TrustedNetworkDetection element would need to include that information. If it doesn’t match, the VPN connection will be established automatically.

      • ced666

         /  May 22, 2018

        Hello

        I found why the Peripheral Tunnel did not work with the TrustedNetworkDetection directive. In the documentation it is stated that the tunnel is always mounted whatever the situation. That is, the device tunnel is not compatible with the suffix-based trigger.

        The “TrustedNetworkDetection” directive is only functional with the User tunnel mode.

        Can you confirm that?

      • That’s incorrect. TrustedNetworkDetection works for both the user and device tunnels. As long as you correctly configure this setting to match your internal connection-specific DNS suffix VPN tunnels (user and/or device) will not be established.

      • ced666

         /  May 23, 2018

        Hello,

        excuse me for my previous message, there was an error. Let’s summarize.
        My physical adapter has the suffix “mydomain.com”.
        Then my TrustedNetworkDetection element would need to include that information “mydomain.com”, so that should be okay. However, the VPN connection is automatically mounted.
        The tunnel continues to mount despite the DNS suffix that matches with the “TrustedNetWorkDetection” element.

      • That’s correct. It should match exactly. If it does, and the VPN connection still establishes automatically, I’d have to say it’s a bug. In that case, I’d suggest opening a support case with Microsoft to have them investigate.

  36. Raphael Eymann

     /  May 18, 2018

    I’m using Windows 10 1709 with Device Tunnel (Split Tunnel). Everything works as expected only the vpn ip address registration with the internal dns server doesn’t work. In the eventviewer of the client I can see he is contacting the ISP dns servers and not the internal ones. How can I get this to work?

    Reply
    • It is not uncommon to see the client try to register with external DNS servers. However, it will register with internal DNS servers too. If internal registration isn’t successful, the client might not have permission to update it’s DNS record. Have a close look at the event logs both on the client and server. Perhaps they will yield some clue as to why it is failing.

      Reply
      • Raphael Eymann

         /  May 23, 2018

        I had the issue that the ras service was crashing every reboot. So I updated to Windows 10 1803 and the ras service was not crashing anymore. Also the “RegisterDNS” parameter seems to work with Windows 10 1803. The checkbox register dns under ipv4 dns settings is checked now (with Windows 10 1709 it was not checked). So if you use device tunnel – I recommend version 1803 …

      • Good to hear the Register DNS setting is working reliably now! 🙂

  37. Ben Morgan

     /  May 28, 2018

    Hopefully an easy resolution. I have joined 2 x 1803 Windows 10 (VMs both Pro and Ent) to the domain, got a computer certificate on them, created the XML and PS1 files, ran the ps1 file, specifying the xml in the command line (ran as system using psexec -i -s) and the device tunnel shows up connected (great result).

    I then log out and attempt to log in as any other domain user, and it says the domain is not available, yet as soon as I log in with cached credentials, it comes up connected again.

    I have no rules or anything applied (as this is a lab and proof of concept) can’t quite figure out why this will not allow me to authenticate against the domain controller, also doesn’t show up when I click the network symbol on the logon screen, can you shed any ideas or educate me on what I have missed.

    Reply
    • The Device Tunnel does not appear in the UI, so that is normal. However, it should provide pre-logon connectivity to allow users without cached credentials to authenticate. Not sure why it isn’t working for you though. There were some known issues in v1709, but those were resolved in 1803. Curious…do you see the device tunnel going down when you log off? If it is established, it should stay up regardless who is logged on, if anyone.

      Reply
  38. Hi Richard,

    about the tunnel device, where are the logs stored in Windows? I find that there are not many logs for VPN connections. How does troubleshooting work if there are not many logs?

    Reply
  39. I’m having difficulty creating a Device Tunnel with the -AllUserProfile enabled. If I run the Get-VPNConnection in a user context it returns the correct VPN connection settings but it always lists the AllUserConnection as False.

    If I run the same command in the SYSTEM context it returns nothing. If I use the -AllUserConnection parameter it complains about not being able to find it in the phone book.

    I suspect I need to force the -AllUserProfile when creating the connection but can’t find the right parameter. I’d expect to see it here, but it’s not: https://docs.microsoft.com/en-us/windows/client-management/mdm/vpnv2-profile-xsd

    Any clues?

    Reply
    • When you create the device tunnel you need to stipulate the OMA-URI of ./Device/Vendor/MSFT/VPNv2/ and not ./User/Vendor… That’s the most common mistake that I see. If you are doing this with PowerShell, keep in mind you can’t use the same script as you use to provision the user tunnel. There’s a different script for creating the device tunnel, and that script must be run in the context of the local system account.

      Reply
      • Richard,
        I’m using the same configuration as that in the Microsoft example:

        $nodeCSPURI = ‘./Vendor/MSFT/VPNv2’
        $namespaceName = “root\cimv2\mdm\dmmap”
        $className = “MDM_VPNv2_01”

        So do I need to modify this so it reads ‘./Device/Vendor/MSFT/VPNv2’ ?

      • If you’re using the Microsoft example script it should work. It does for me. I have to assume that somewhere else they specify the device and not the user URI. If you’d like I can send you the script I’m using. It’s the same as the Microsoft script though, so I’m not sure how much help it will be. If you’re following the guidance in this post explicitly it should work though.

      • OK, following your example almost exactly (apart from the specific IP addresses) it’s now working for me. Before this, I was using the example whereby the ProfileXML and script was embedded into one PS file. It all worked apart from the AllUserConnection setting. Using the distinct PS1 and XML files has fixed that.
        Thank you Richard.

      • Great to hear. 🙂 Now you’ll have to let me know how your experience goes with the device tunnel. In my experience it has been entirely stable. 😉

  40. Hi Richard,

    I would like to see if it is possible to have in addition to the tunnel device, the user tunnel on the same laptop. Can you send me the .ps1 and .xml script to create the user tunnel? For information, I use Microsoft’s .ps1 and xml script to create the device tunnel in the localSystem context.
    Another question, is it mandatory to have the NAP server when mounting a user tunnel based on machine certificates for IKE?
    I thank you in advance.

    Patrick

    Reply
    • Send me an email and I’ll send you the scripts that I use. They are essentially the same as the Microsoft scripts, just modified slightly. Also, no, NPS is not required if your are performing device certificate authentication on the VPN server with IKEv2.

      Reply
      • ced666

         /  June 5, 2018

        Hello Richard

        Thank you very much

      • ced666

         /  June 5, 2018

        Hello,

        I just send my email address in your personal box.
        If I understand correctly, contrary to Windows 1709, the tunnel device So, can also be installed on the version of Windows 10 pro 1803 ?
        thanks for quick reply

        Patrick

      • No. The device tunnel is supported only on Windows 10 Enterprise edition clients that are joined to a domain.

  41. Colin Pazdzior

     /  June 5, 2018

    Hi Richard,
    First, thanks for the outstanding documentation and articles you’ve provided for years on this site – I’ve used a number of these extensively in the past.

    We’re now starting to roll out AOVPN with both device and user tunnels, but are starting to see that the tunnels don’t reliably attempt to connect. If connected manually, both work perfectly.

    Provisioning for both is through InTune MDM, using custom profile for device tunnel, and a predefined template for the user tunnel, with our EAP section. We’re using Azure Conditional Access on the user tunnel. All of this works perfectly – once the client attempts to connect.

    Initially, when testing just the device tunnel with trusted network detection turned on, it connected more reliably, and seemed to be happier to initiate its auto connection. With the user tunnel though, the device tunnel would disconnect as soon as it connected, presumably due to the trusted network detection. So we have disabled trusted network detection (the vpn server isn’t listed in internal DNS), so the tunnels won’t connect internally.

    This is with W10 1803.

    Any thoughts?

    Thanks,
    Colin

    Reply
    • Thanks Colin! 🙂 In my experience the user tunnel seems to be stable. However, there have been some issues reported when TrustedNetworkDetection is configured on the user tunnel. Is that configured in your deployment? Also, there are numerous issues related to the device tunnel, most of which have been fixed in 1803. However, I am still hearing reports (and experiencing it myself) of issues with unreliable device tunnel connectivity. With that, there may still be some things that are broken with the device tunnel in 1803.

      Reply
      • Colin Pazdzior

         /  June 5, 2018

        Thanks for the prompt reply Richard!

        At the moment, TrustedNetworkDetection is not configured on either (and isn’t accessible to configure on the user tunnel, as I’m using the InTune VPN template – I’d need to use a custom config like with device tunnel for that.

        I may try and turn TrustedNetworkDetection back on for the device tunnel, although the user tunnel connecting was causing it to disconnect; I suppose that actually wouldn’t really be a problem, as the user tunnel provides access to everything the device tunnel does, and then some, so if it’s connected, the device tunnel isn’t really needed. On user logout, the device tunnel should then reconnect itself quietly. Though….the connection change on login isn’t ideal, as it may interrupt gpo processing, etc if connection drops and comes back.

        The other odd thing I noticed is that when the user tunnel deployed, the “connect automatically” checkbox was not checked. Checking this seems to make it connect automatically, at least a few times, but then stops doing it reliably if the machine is moved around different networks. Clicking connect works no problem.

        This seems so close….

      • Thanks for the feedback. Great to understand what others are experiencing. It does still seem that Always On VPN isn’t quite fully baked. 😉 Your’re right though, we’re close! 🙂 I agree, the device tunnel is redundant if you have a user tunnel. However, if you are doing manage out and the device tunnel is registering in DNS the client won’t be reachable. Something to consider. As for the “connect automatically” issue, I’ve not encountered that issue. I’ll keep an eye out for it. Unusual for sure.

  42. Mike Pietrorazio

     /  June 6, 2018

    Can add the device tunnel via PowerShell, and once connected to external network, the device connection shows in VPN server device list, but can’t ping in either direction to/from DC’s. Client status of device tunnel shows “disconnected” 1803. Testing without user tunnel atm.

    Reply
  43. Aaron Silber

     /  June 6, 2018

    Hi Richard,
    Your advice and write-ups are really great. I was wondering if you have tested a Device tunnel with Split tunneling disabled, aka ForceTunnel? I cannot seem to get it to work with the ProfileXML, the PowerShell command (even ran it as the SYSTEM account via PSExec) or unchecking the box in the network card properties.
    Thanks again!

    Reply
    • No, haven’t tested that yet. I haven’t encountered a use case whereby force tunneling is required for the device tunnel. Typically I deploy the device tunnel for access only to a few restricted machines for the sole purpose of authenticating user logons.

      Reply
  44. ced666

     /  June 6, 2018

    Hi Richard,
    unlike Windows 10 1709, Always on VPN tunnel device is only supported for enterprise edition. If I understand correctly, the tunnel device is also supported in professional version since Windows 10 1803?, Is that it?
    Thank you

    Reply
    • That is incorrect. The device tunnel is supported only on Windows 10 Enterprise edition clients that are joined to a domain.

      Reply
  45. Colin Pazdzior

     /  June 8, 2018

    The plot thickens! So, the most reliably we’ve been able to get the user tunnel to connect is to have trusted network detection on the device tunnel (which then disconnects itself once user tunnel connected). Register in DNS set on user tunnel, so machine should be reachable.

    However, there’s now something very, very strange going on that I’m trying to dig down on – user tunnel appeared to work just fine in past, but it actually wasn’t – SMB shares are broken.

    With device tunnel connected, share access (to servers the device tunnel has access to), works properly, no issues at all.

    With just user tunnel connected, shares do not work. Other internal resources are available, everything is pingable, RDP works, etc. SMB 3 shares do not work. They come back usually with “extended security error”. Digging through client logs, under SMBClient\Security, there are a lot of event 31001s listed.

    Content is either

    An attempt to initialize a security context failed.

    Error: The smartcard certificate used for authentication has expired. Please
    contact your system administrator.

    Security status: 0xC000038D
    User name:
    Logon ID: 0xD480C
    Server name: \servername.domainsuffix
    Principal name: cifs/servername.domainsuffix1UWhRGBAAAAAAAAAGAAAAAAAAAAAAAAAAAAQNCkbmeBAAAA

    or sometimes this:

    An attempt to initialize a security context failed.

    Error: The attempted logon is invalid. This is either due to a bad username or authentication information.

    Security status: 0xC000006D
    User name:
    Logon ID: 0xD480C
    Server name: \servername
    Principal name: cifs/servername1UWhRGBAAAAAAAAAGAAAAAAAAAAAAAAAAAAQNCkbmeBAAAA

    There’s something funny about the security context that it’s using; like that Azure CA cert is being presented, or something funny. I’m scratching my head on this one, trying to dig for more. Any thoughts on this?

    Reply
    • Are you using user certificate authentication?

      Reply
      • Colin Pazdzior

         /  June 11, 2018

        For the user tunnel, we’re using Azure conditional auth, so Azure provides a short lived certificate which should be used for the connection… Though I’m not sure how this should affect SMB shares, once the VPN tunnel is up.

      • Colin Pazdzior

         /  June 11, 2018

        Yes, and the tunnel connects successfully – all other resources work, just not SMB shares…

      • Unusual. Authentication is clearly working if the tunnel is established successfully, but sounds like it isn’t quite mapping your credentials to a suitable Kerberos ticket somehow. Why, I have no idea. :/

      • Colin Pazdzior

         /  June 11, 2018

        Haha, that’s kinda what I’d arrived at. Must be missing something. It’s only when connected over the user tunnel though; with device tunnel, no
        problem, and if I immediately take the machine and connect to corpnet directly, shares work. And everything other than smb shares works over user tunnel. Doing something funny….

      • Colin Pazdzior

         /  June 11, 2018

        Huh, so, progress, but also confusion. Tried accessing a UNC share using server FQDN, like \\server.domain.com\share instead of \\server\share (which works on our old vpn, locally, and on user tunnel). FQDN works.

        DFS-n shares don’t work, same error. The AOVPN profile for both device and user tunnels have the same domain.com DNS suffix set.

        Odd….but it looks like not kerberos / signing issues.

  46. Colin Pazdzior

     /  June 14, 2018

    Learned a little bit more. So, from here: https://social.technet.microsoft.com/Forums/sharepoint/en-US/daf53d2a-4d2d-4df9-a799-1200b9e72e23/trouble-with-dnsnetbios-name-resolution-over-vpn?forum=winserverNIS

    Looks like similar issue from the past. Tested what they suggested, removing the cert based credential from credential manager (this is the Azure Confitional Access cert), and the shares work perfectly. So Windows appears to be trying to use this cert to authenticate to the SMB shares. Not sure how to stop it doing that though!

    Reply
  47. Colin Pazdzior

     /  June 20, 2018

    I’ll second that, thanks Jason!

    I’ve been working on this for a few days now, and am still having trouble. Basically, I can’t seem to get the AOVPN xml config to correctly select the client cert I want used for the Kerberos identity check. Have tried many permutations of syntax for the EKU OID and issue hash, and it just doesn’t seem to take the cert. If I use the InTune wizard and create a profile there, it does work – correct cert is selected and shares are accessible. Unfortunately, the tunnel disconnects every time the InTune MDM policy refreshes every few hours, which doesn’t seem to be the case using a custom XML…. Does anyone at MS test this stuff????

    Sample of device compliance section with hash replaced:

    true

    true
    hashherewithoutspacesfromissuingca
    1.3.6.1.5.5.7.3.2

    Same

    Reply
    • Colin Pazdzior

       /  June 20, 2018

      Well that’s didn’t work… OK, XML brackets replaced with hyphens:

      -Enabled-true-/Enabled-
      -SSO-
      -Enabled-true-/Enabled-
      -IssuerHash-hashherewithoutspacesfromissuingca-/IssuerHash-
      -EKU-1.3.6.1.5.5.7.3.2-/EKU-
      -/SSO-
      -/DeviceCompliance-

      Reply
      • Jason Jones

         /  June 21, 2018

        From memory it’s very sensitive about the formatting of the hash value – have you tried explicitly typing the value in without using paste?

    • Colin Pazdzior

       /  July 10, 2018

      So, finally had some time to come back to this.

      Basically, when using Azure Conditional Access with the user tunnel, an ent CA cert needs to be selected based on issuer hash and EKU for use by Kerberos…without this, the Azure CA issued cert will be used, and Kerberos auth will fail with all kinds of funny errors.

      The real difficulty here is that when defining a profile using a config XML, turns out it’s EXTREMELY picky on the capitalization it’s looking for on each of the various nodes, and documentation is not all correct or accurate. When capitalization and syntax is not exact, cert selection does not work – the VPN cert is used and Kerberos is broken.

      Using the built in InTune VPN template worked with Azure Conditional Access, except that on every MDM refresh, the VPN connection definition on the local PC appears to drop, be removed, and rewritten. For this reason it was desirable to use a custom XML, but defining the correct cert proved difficult as indicated above. I finally figured out the capitalization by pulling it out of a reg key when using the InTune template.

      Key bit is the SSO node tags are “Sso” – this format strips formatting, so can’t easily replicate, but basically:

      DeviceCompliance
      Enabled true /Enabled
      Sso
      Enabled true /Enabled
      Eku 1.2.3.4.5.6 /Eku
      IssuerHash ISSUER_HASH_HERE_NO_SPACES_LOWERCASE /IssuerHash
      /Sso
      /DeviceCompliance

      One thing I’m still not super happy about is its auto connection behaviour; the “Connect Automatically” box does not get ticked when the VPN profile is created on the client machine, and when a device tunnel is also present, the user tunnel does not always connect automatically without that box ticked. With it ticked, it does connect promptly, but that box seems to get unticked periodially. Anyone know how to programatically set that?

      Cheers,
      Colin

      Reply
      • Colin Pazdzior

         /  July 11, 2018

        Another point on auto connect behaviour; it really doesn’t seem to be quick to re-establish connections in a few common scenarios…Where it seems to work best is booting a laptop on a non-corp internet connection – this seems to get tunnels reestablished relatively quickly. What does not, is hibernating a laptop (as many of our users routinely do), and resuming on a non-corp connection, or having the machine go to sleep and then wake up on the same connection. Not exactly “Always On” if simple scenarios like this don’t trigger a reconnect. Thinking of adding task scheduler job to add my own connect triggers…

        Thoughts?

        Cheers,
        Colin

      • Same experience here. I’ve considered exploring some type of connection trigger as well. Perhaps run a scheduled task trigger by an event? Haven’t done it, but it might be a viable workaround.

      • Yes, the XML file is sometimes sensitive to case. Jason Jones pointed out that boolean values (true/false) are case sensitive. For example, true works, True does not. Sounds like you found another scenario in which case matters. Thanks for sharing that information! 🙂 As for device tunnel/user tunnel stability, that seems to be a common complaint these days. Hopefully Microsoft is addressing some of these challenges. 🙂

  48. Hi Richard,

    is it possible to launch the IPSEC VPN tunnel without encryption? ie only ensure integrity?
    Thank you

    Reply
  49. ced666

     /  June 22, 2018

    Hello Richard,
    when I try to use the ECP 256 or ECP 384 (DH) crypto suites, I get the following error from the Always On client
    Verifying username and password … failed to find valid machine certificate. Contact your Network Security Administrator about installing a valid certificate in the appropriate Certificate Store.
    Have you ever encountered this problem?

    Thanks in advance.

    Patrick

    Reply
    • Not specifically. You’ve defined the crypto in both the profile XML and on the VPN server as well, correct?

      Reply
    • Jason Jones

       /  June 22, 2018

      Those algorithms are likely looking for an elliptic curve (ECC) certificate as opposed to an RSA one – hence it can’t find any – try testing with a certificate issued from an ECC PKI hierarchy

      Reply
  50. Ian

     /  June 25, 2018

    Hi Richard, great stuff on your site! Quick question, I’ve noticed that the Device Tunnel allows for local users to connect as well as domain users. Do you know of a way to prevent local users access via the device tunnel?

    Ian

    Reply
    • I don’t. VPN doesn’t use AuthIP like DirectAccess does, so anything or anyone that can generate traffic on the interface will be able to access the network. It’s just a limitation of the technology.

      Reply
  51. Hello Jason
    Thank you very much for your answer.
    Indeed, the vpn works with certificates from a PKI ECC.

    I have another question.
    Is it possible from the Windows 10 system to verify the integrity logs of the VPN connection?

    thank you

    Patrick

    Reply
  52. ced666

     /  July 4, 2018

    Hello,

    I tried to implement log tracing when rebooting Windows 10 by following the procedure below:
    https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/example-13–creating-a-global-logger-session
    but no log is put back in the file.
    Do you have an idea?

    I want to trace all the events from system startup until the IPSEC tunnel is established.

    Thank you.

    Patrick

    Reply
    • That’s not something I’ve ever done, so I can’t really offer any advice. If you want to capture network traffic you can use “netsh trace start persistent=yes capture=yes tracefile=c:\nettrace.etl” which would persist through a reboot. Not sure if that helps you or not. You can also enable IPsec auditing which might help as well.

      auditpol.exe /set /subcategory:”IPsec Main Mode” /success:enable /failure:enable
      auditpol.exe /set /subcategory:”IPsec Quick Mode” /success:enable /failure:enable

      Reply
  53. ced666

     /  July 4, 2018

    Hello,

    in the case of a use of a machine certificate issued by a public authority, does it not present a risk for a third party to connect in tunnel device mode from a machine certificate purchased by a public authority declared on the same VPN gateway?
    What is the recommendation on the use of machine certificate, is it recommended to use a private certification authority?

    Thank you

    Patrick

    Reply
    • Yes, absolutely! That’s why using a public certificate is always discourage for machine certificate authentication. You should always use a certificate issued by your internal private CA to ensure only your authorized client devices can connect.

      Reply
  54. Hello Richard,
    is it possible to deploy the tunnel device VPN client configuration via GPO? if not, is there a way to deploy it massively?

    Thank you
    Patrick

    Reply
    • Not natively. However, there’s nothing that prevents you from packaging the PowerShell script and the XML file and deploying that to users.

      Reply
  55. Hello Richard,
    In the XML file, is it possible to declare multiple VPN gateways in the vpn.contoso.com directive, ras.consoto.com>.
    The idea is that if the first gateway does not respond, the second gateway is contacted. I ask this question because in LockDown mode only one profile is allowed.

    Thank you very much.

    Patrick

    Reply
    • You can define multiple VPN servers in the XML file, but they don’t fail over like you would expect. Instead having multiple gateways defined simply allows the user to select a different gateway, if required. If it is the device tunnel (or lock down mode) the user won’t have access to those settings anyway. Your only option is to implement active/passive failover using GSLB like Azure Traffic Manager. Post coming on that soon. 🙂

      Reply
      • Hello Richard
        In the case of LockDownk mode, the VPN tunnel will also need to be mounted when the user connects within his enterprise. In this case, we can very well imagine the use of DNS views so that the VPN gateway is always accessible (external / internal) of the company. What do you think ?
        Patrick

      • There are many limitations associated with LockDown mode, for sure. I was unaware that that it would connect even on the internal network. Is this true if you define the TrustedNetworkDetection element as well? I would expect not, but I’ve never done any testing with LockDown VPN.

  56. Saravanan

     /  July 12, 2018

    Hi Richard,

    we are currently using AutoVPN as our VPN solution. The problem we face here is fail-over. The fail-over between the servers in cluster and as well as site/DC fail-over is not happening until you set the mobility outage time. As Default, the mobility outage time is minimum set to 30 minutes, which is large time to fail over. Since we use UDP ports as our protocols it is connection less protocol which won’t send the reset package to the client who set in failed server.Is there any possibility to set the Network outage time as 2 minutes by powershell script?

    Reply
  57. u3comp

     /  July 13, 2018

    Hi Richard,

    Your post helps me a lot to understand Always On VPN.
    Do you think it is possible to connect VPN with Device Tunnel and then connect another VPN with User Tunnel automatically?
    The Purpose for doing the way is because I would like to implement Device Tunnel connection just for accessing active directory and User Tunnel for authenticating with NPS.

    Reply
    • Yes, absolutely. Device tunnel and user tunnel are not mutually exclusive. That’s a common deployment scenario in fact. Often the device tunnel is deployed with limited access only to facilitate remote logon without cached credentials. Once the user is authenticated a user tunnel is established that allows more access.

      Reply
      • u3comp

         /  July 17, 2018

        The 1st connection(device tunnel) works fine thanks to you.
        Have you tried set up the connection you mentioned above?

        I was wondering how 2nd connection(user tunnel) can automatically get triggered after the 1st connection.

      • The two tunnels are completely independent of each other and will use their own logic to determine when to connect, depending on how you configure them. Each will connect automatically any time unless you’ve defined TrustedNetworkDetection, in which case it will not connect if any connected physical interface (non-virtual interface) has the DNS suffix you define as internal. If not, both tunnels should come up. However, I am hearing reports that’s not entirely stable though. :/

  58. Hello,

    I have some difficulty understanding the following directive
    true
    What exactly is it on the VPN interface? Can you give me a concrete example because I have trouble understanding the concept.
    I know we are in ForceTunnel mode, the “DisabledClassBasedDefaultRoute” directive must be false.

    I thank you in advance for the explanation

    Patrick

    Reply
  59. Colin Pazdzior

     /  July 20, 2018

    Hi Richard,
    Continuing the auto-connect behaviour conversation from above- I’ve been working on this and have what I think is fairly decent logic worked out for both device and user tunnel connections.

    Basically, GPO added vbs and ps1 files, scheduled task calls vbs to call the ps1 (to ensure no popup box visible in user session). Ps1 checks to see if any physical adapter is on my corp domain and if NOT and vpn NOT connected, uses rasdial to connect.

    The scheduled task has a few triggers, depending on whether the one for device or user tunnels, thinks like logon, resume from sleep, etc. Those retry every 5 minutes for 15. Also a catch-all that runs every half hr or hr.

    The scripts all seem to work fairly well, and the device tunnel is now rock solid on reconnecting itself automatically.

    The problem is with the user tunnel; script logic is all good. The problem is that, specifically with the Azure Conditional Access piece, the way the W10 client works is that it checks to see if there is a valid Azure cert (1 hr validity), and if not, goes out and gets a short lived cert from Azure, which is then presented to my local server infrastructure on the connect. This is all good.

    Using rasdial does not seem to trigger the critical first step of fetching a cert from Azure if there isn’t a valid one. So my logic only works if a manual connect has been done in the last hour and a valid cert is already present.

    Question is, is there another way to programmatically call the VPN connection in W10 such that the first Azure/cert bit happens?

    Cheers,
    Colin

    Reply
    • I’m not aware of any programmatic way to initiate a VPN connection other than using rasdial.exe. Perhaps someone knows of a way to do it with PowerShell?

      Reply
  60. Bonjoru Richard,

    is it mandatory to use a NAP server as part of a User tunnel.
    Is it possible to interconnect the VPN gateway directly to the Active Directory for the account base?
    Thank you very much.

    Patrick

    Reply
    • Strictly speaking, no. However, it would require that the RRAS server be joined to the domain. You’d also lose support for some of the more secure authentication protocols like PEAP.

      Reply
    • Jason Jones

       /  July 25, 2018

      More crucially, Windows 10 has no NAP agent so that’s the primary challenge! 😉

      Reply
  61. ced666

     /  July 27, 2018

    Hi Richard,

    is it possible to enter in a single Powershell script the powershell script and xml file provided by Microsoft here https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/ vpn-device-config-tunnel # configure-the-vpn-device-tunnel

    with the goal of deploying it more easily by GPO in the computer startup.

    Thank you in advance for your help.

    Patrick

    Reply
  62. Terry

     /  July 27, 2018

    Hello,

    We are testing this and always get error 633 Modem is Already in Use. Would you happen to have any solution. This is on a clean image. Using IKEv2 encryption.

    Reply
    • Sorry, no idea what could be causing that issue. That’s an error message I’ve not yet encountered myself. :/

      Reply
    • ced666

       /  July 30, 2018

      Hello Terry,
      strongly agree, the LockDown mode does not cover all situations. All access must be mandatory via a VPN gateway (internal or external to corporate).
      The intermediate solution that I found is to set the Windows firewall to block all outgoing traffic on public and private profiles except the streams required for the establishment of the VPN tunnel. Using Always On VPN alone is not enough to handle the traffic and it’s really a shame compare to other VPN solutions.

      Patrick

      Reply
  63. Jochen

     /  July 30, 2018

    Hi Richard,
    do you have an idea / “Best Practice” how to immediately deny computers the right to continue to establish a VPN Connection?
    Thank you very much.
    Jochen

    Reply
    • You could revoke certificates used by computers and/or clients, but that doesn’t happen instantly because revocation information is often cached. It is recommended that you create a security group of blocked users/computers and then create an NPS policy that denies access to the VPN instead.

      Reply
      • Andy

         /  July 31, 2018

        I thought NPS only applied to user certificates? NPS seemed to have no role in blocking computer certificate/device tunnel?

      • You are correct. Device tunnel machine certificate authentication happens on the VPN server, so that might be more of a challenge. 🙂 You’ll probably have to revoke the machine certificate and wait for revocation caches to expire, or go through the process of manually flushing them. Details here: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee619754%28v%3dws.10%29.

      • Jochen

         /  July 31, 2018

        How can I include an NPS in a Always on VPN device tunnel with certificate authentication? I thought the NPS is not involved in the connection process when RAS “machine certificate authentication for VPN Connections” is enabled?

      • That’s correct. NPS is not involved at all on the device tunnel. The machine certificate used for device tunnel authentication is evaluated on the VPN server only.

  64. Rob F

     /  July 30, 2018

    I found this article really helpful during my initial testing. What I’m running into now is a problem with captive portals. When I connect to the internet through a captive portal, it takes over 10 minutes for the device tunnel to come up.
    Is there some kind of setting that can used to recognize when CP is in effect? Or speed some process for connecting?

    Thanks.

    Rob

    Reply
    • Not that I’m aware of, unfortunately. :/ However, the issue you describe could be unrelated to captive portals. There are numerous reports of tunnel instability, especially when the device tunnel is deployed in conjunction with the user tunnel. Have you ever noticed the device tunnel not coming up for a period of time when accessing the Internet over a connection that does not use a captive portal? I ask because I see this behavior all the time, even on 1803. On my test machine it is not uncommon for the device tunnel not to come up for long periods of time, sometimes up to 15-20 minutes. It eventually comes up though.

      Reply
      • Rob F

         /  July 30, 2018

        I haven’t seen it take that long to connect when using non captive portal. It’s usually only taking a few seconds. It’s a small sample size, one machine on two networks for non captive. It’s two for two with long connection times on CP networks.
        I’m going to be testing another machine this evening and tomorrow so I might get a different result.
        I don’t think there’s any user tunnel configuration in place. I’ve followed the instructions on this page only. Is there a user tunnel that should be configured after the device tunnel connects?

      • That’s up to you, really. The device tunnel was really designed to support limited network access to support pre-logon connectivity. The main use case is to enable users to logon without cached credentials. That doesn’t mean you can’t use the device tunnel for full access, it’s just that it wasn’t really designed for that. The user tunnel is the primary avenue of access and it supports better authentication protocols than does the device tunnel. Documentation here: https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/vpn-deploy-client-vpn-connections.

      • Rob F

         /  July 31, 2018

        I’ve tried to follow those instructions for the user tunnel. Each time I get to entering the data for the new tunnel, powershell ise just exits. I can’t see why it’s happening. No problem creating the .xml but the powershell script is never created.

      • Unusual. Does it work outside of ISE, in a regular (elevated) PowerShell command window?

  65. conradebel

     /  August 3, 2018

    Hi Richard.

    I’ve deployed the AlwaysOn VPN device tunnel via PowerShell and machine cert auth and it works great. However, the device tunnel VPN doesn’t show up in the VPN device list. I do see it when listing all the VPNs via PowerShell, and the VPN does have the -AllUserConnection flag set to true.

    Do you know if there is a way to make the device tunnel show up in this VPN device list? I can foresee scenarios where the device tunnel isn’t connecting, and users would need to manually connect/disconnect the device tunnel, or at least see the current state of the tunnel. Direct Access has the client connectivity assistant to surface this sort of information (in Win7 at least). Have you encountered this before? Any ideas?

    By the way, this was a great article! Thanks for sharing!

    Reply
    • That’s by design. You won’t see the device tunnel in the UI because the profile is created in the context of the system account. No real way to get around that, honestly. 🙂

      Reply
  66. Ryan Messer

     /  August 6, 2018

    I seem to get this when running the Set-VPNAuthProtocol cmdlet
    Set-VpnAuthProtocol : Cannot process argument transformation on parameter ‘RootCertificateNameToAccept’. Cannot convert the “System.Object[]” value of type
    “System.Object[]” to type “System.Security.Cryptography.X509Certificates.X509Certificate2”.

    Reply
    • That’s odd. Instead of using the subject name, try using the certificate thumbprint instead.

      $Thumbprint = “cert_thumbprint_here”
      $RootCACert = (Get-ChildItem -Path cert:\LocalMachine\root | Where-Object {$_.Thumbprint -eq $Thumbprint})
      Set-VpnAuthProtocol -UserAuthProtocolAccepted Certificate, EAP -RootCertificateNameToAccept $RootCACert -PassThru
      Restart-Service RemoteAccess -PassThru

      Let me know if that helps!

      Reply
  67. Ryan

     /  August 6, 2018

    I can’t seem to get this working past the point of the same error I see a lot advertised with no real resoloution. I get the rasclient 13806 error which translates to IKE failed to find a valid machine certificate. I’ve got the error both on the client and server so at least I know it gets that far.

    My client has a client EKU certificate with its hostname as the subject and my RRAS server has machine certificate configured and has a certificate that has server and client authentication EKU issued by the same trusted CA. I’ve run the powershell command to set the accepted CA but get the same IKE failed to find machine certificate error. What I can’t acertain as both server and client log it is where the error originates from or how to fix it as I’ve tried lots of things.

    Any help much apricated.

    Reply
    • Sounds like you have everything in place, but does the computer certificate on the RRAS server have the public hostname (not the RRAS server’s hostname) listed in the subject field? Also, when you set the root certificate to accept on the RRAS server, did you specify the root certificate (not an issuing certificate)? Also, do both server and client have the root (and any intermediate) certificate installed?

      Reply
  68. bartpasmans

     /  August 14, 2018

    Hi Richard,

    I’m having some difficulties regarding the device tunnel. I’ve used the device xml mentioned and adjusted it accordingly. But when the device tunnel is setup there is no connection initially between the VPN server and the client. (ping fails)

    After about 5 minutes while running ping in endless mode i suddenly get a reply. Disconnecting and reconnecting again sometimes also solves the issue.

    Any clues on this one?

    Reply
    • Common complaint. If you are using TrustedNetworkDetection you might try removing that to see if it works any better. Also, if you’re not fully up to date, I’d strongly recommend that you do that before trying anything else. Your best chance of success is using Windows 10 1803 with all the latest updates. Many issues similar to the one you describe have been resolved in the latest release.

      Reply
      • bartpasmans

         /  August 15, 2018

        Hi Richard,

        Thanks for the reply! I got all the updates and are not using the TrustedNetworkDetection. But Still it’s giving me a headache 😦

      • Bummer. At this point you can either open a support case with Microsoft and perhaps they might have a private fix, or you can wait for the next release and hopefully those issues are solved then. :/

      • bartpasmans

         /  August 15, 2018

        Hi Richard,

        I’ve opened a support case! Will inform you (hopefully) about the solution!

      • Ok, keep me posted!

  69. Holger

     /  August 14, 2018

    Hi Richard,
    from the security perspective it is not possible to divide the two tunnels to filter behind or on the ras machine. The second point I see is that the configuraitons of both tunnles are solely client related and not double checked by the server. What is your opinion compared to other VPN solutions?

    Thanks, Holger

    Reply
    • You can implement traffic filter rules on both tunnels separately if you like. That would allow you to define different access rules for each tunnel. Both tunnels (device tunnel and user tunnel) are authenticated and authorized, albeit differently. The device tunnel uses device certificate authentication which is validated by the VPN server. The user tunnel can use a variety of different authentication schemes, most commonly (and recommended) would be Protected EAP (PEAP) with client certificates which is validated by the NPS server (running on the VPN server or on a separate server, depending on the configuration).

      Always On VPN is a decent solution compared to other VPN solutions, but often third-party solutions offer more in the way of security and performance. When I’m helping customers implement a mobility solution to meet their needs we look at many alternatives, both Microsoft and third-party. The choice of which solution to use depends entirely on the requirements of the customer of course. Sometimes it’s Always On VPN, sometimes it’s a third-party. 🙂

      Reply
  70. I think what gets me most about this product is the lack of documentation. Sure, there are plenty of sample scripts out there but little reference material. For example, I’m currently trying to figure out the TrafficFilter and Route settings in the sample ProfileXML. I can’t find a helpful reference for these anywhere on the net. All I want to do is to restrict the device tunnel access to certain hosts. It’s so frustrating. Anyone?

    Reply
    • Agreed. Some of the “examples” are really poor too. I’m trying to rectify some of that by publishing articles here, so hopefully that’s helpful. As for routing, I published an article on that topic recently. You can find it here: https://directaccess.richardhicks.com/2018/07/23/always-on-vpn-routing-configuration/.

      I’ve not yet written anything about traffic filtering though, so perhaps I’ll post something on that soon. It’s a powerful feature, but surprisingly not commonly implemented. And you’re right, the Microsoft documentation is entirely intuitive. 😉

      Reply
  71. Marc Bauer

     /  August 16, 2018

    I have a question about device tunnel where I have not found a single answer somewhere. I need to do software updates to computers via active directory GPOs. In a local network this deployment works fine. With DirectAccess it seems not working yet. How about Always On VPN?

    Reply
    • Should work as long as the client has connectivity to the internal network, either with the device tunnel or user tunnel. 🙂

      Reply
      • Marc Bauer

         /  August 24, 2018

        Sure – I had internet connection. With DirectAccess the login worked fine, all drives exist and so on. So in general the direct access network connection works fine.

        With “user tunnel” software deployment cannot work as software is installed via GPO on system boot up only.

        Has someone tested it with “device tunnel”? I cannot as I have no VPN gateway that supports device tunnel, but I wish I do not waste my time implementing it just to find out that it still does not work. Note – with Direct Access it does not, but I expected it to work. So I wasted the time already there 😦

      • In theory it should work, but I don’t think I’ve validated this specific scenario. I’ll do some testing and let you know what I find. 🙂

  72. Hello Richard,
    for DeviceTunnel i must configure the VN Server in RAS Console for Windows Authentication. I want also use a UserTunnel with PEAP. For this, i must configure the VPN Server in RAS Console for RADIUS Authentication. When i have configure RADIUS Authentication, also still work the DeviceTunnel? What i must configure on the NAS Server?

    Reply
    • Device tunnel authentication always happens on the RRAS VPN server, even if you have configured RADIUS authentication. The only thing required for device tunnel authentication is to enabled machine certificate authentication on the RRAS server. Once that’s done, device tunnel tunnel connections will have their machine certificate validated by the VPN server, and user tunnel connections will be forwarded to the configured NPS server for authentication.

      Reply
      • Thorsten Frohberg

         /  September 5, 2018

        Thank you for your answer. Another question is what i must configure on the Default Gateway from VPN Server ? My clients can connect to the Server, but can’t use internal ressources. I think it needs a static route for the VPN Client Subnet on the gateway. My problem is, my gateway works in a Cisco ACI (Application centric Infratsructure) and its configured as ARP Proxy. I can’t configure static routes.

      • If your VPN server has two network interfaces, the internal interface will be configured with an IP address, subnet mask, and internal DNS servers. The external interface will be configured with an IP address, subnet mask, and default gateway. No DNS servers should be configured on the external interface. Since the internal interface does not have a default gateway, you will need to add static routes to any remote internal subnets as required. More details here: https://directaccess.richardhicks.com/2013/06/19/network-interface-configuration-for-multihomed-windows-server-2012-directaccess-servers/

      • Thorsten Frohberg

         /  September 7, 2018

        When i have a reverse proxy on internal site, then its not need the default gateway on external adapter, or?

      • Depends on how your reverse proxy is configured. If it is NATing the client’s public IP address, then no, you won’t need a default gateway on the external interface. Generally speaking, this configuration (source NAT) is not recommended because it obscures logging on the VPN and/or NPS server (all requests come from the same NAT IP address) and it negatively affects scalability on the VPN server (inbound TCP connections aren’t as effectively distributed among processor cores).

  73. Hello,
    I’m trying to find out how to remove an Always On Device tunnel VPN connection in LockDown mode. Currently, it is impossible to delete this connection even in the localsystem context.
    What is the procedure to follow please. I found no solution except to reformat the laptop.

    Thank you

    Patrick

    Reply
    • I honestly don’t know! I’ve never used lockdown mode or even tested it. Assuming that terminating the connection with rasdial.exe and then removing the connection using PowerShell isn’t working?

      Reply
      • Eric Yew

         /  September 13, 2018

        After spending 5 hours trying to remove the lockdown mode VPN profile, i finally resolved the issue. For those who come across this issue, the following should remove it:
        -make sure the VPN is disconnected. As lockdown mode prevents you from disconnecting it, easiest way is to disable WiFi and LAN
        -then run powershell with system:
        .\PsExec.exe -s C:\windows\system32\WindowsPowerShell\v1.0\powershell.exe
        **make sure -i is removed as it will not work as -i tries to make a connection to itself to open a new window and will fail.
        -run the following command:
        $obj = Get-CimInstance -Namespace $namespaceName -ClassName $className
        Remove-CimInstance -CimInstance $obj

        That worked for me. Hope it helps.

      • Eric Yew

         /  September 13, 2018

        would be helpful if i provided the parameters:
        $namespaceName = “root\cimv2\mdm\dmmap”
        $className = “MDM_VPNv2_01”

      • Hello

        I was able to remove the Lockdown connection like this without disabling any network interface.
        1- \ PsExec.exe -i -s C: \ windows \ system32 \ WindowsPowerShell \ v1.0 \ powershell.exe

        and I execute:

        2- Get-CimInstance -Namespace “root \ cimv2 \ mdm \ dmmap” -ClassName “MDM_VPNv2_01” |
        Remove-CimInstance -CimInstance

        The VPN connection is first disconnected and then deleted.

        Patrick

      • Awesome. 🙂 Thanks for the tip!

  74. Hello,

    I’ve successfully created a working user(using roughly https://4sysops.com/archives/always-on-vpn-network-configuration-and-security/ ) and device(big thanks for creating this guide Richard!) VPN.

    Now, I have some questions regarding security. What I really want is the following(which is also the recommended way of doing this – however, I can find very little information on this topic):
    – Restrict the device tunnel to allow just enough traffic so that a user can authenticate + some management things.
    – After authentication, the user tunnel becomes active, so the active user session is then able to connect to more internal network resources.

    My question is: how do I do this in a good way? In my case, both tunnels are getting an similar IP from DHCP(ipv4 forwarding ), so at the (perimeter)firewall level, I can’t do much(as there is no way of differentiating between tunnels).
    I’m a novice with Routing and remote access. Can someone give me some pointers here?

    Thanks in advance!

    –Mark

    Reply
    • I would suggest you configure the device tunnel to use host routes that point to your domain controllers. You can follow the guidance for configuring IP routing here: https://directaccess.richardhicks.com/2018/07/23/always-on-vpn-routing-configuration/.

      Reply
      • Hello Richard,

        Thank you for your response. You mean with a of 32 , so that the device Tunnel can not connect to other hosts(only those with routes defined)? I’m going to try that. Thank you!

        Is there any other way of restricting Access for the device Tunnel? Or is it possible/better to create really separate Tunnels(with 2 RRAS servers for example) so that I have more control over it with firewall rules?

        Sorry for my stupid questions.

        Thank you in advance,
        –Mark

      • Correct. It is possible to enable traffic filters for the device tunnel (and for the user tunnel for that matter) to restrict access to specific ports and/or applications, but that gets difficult to manage and it also breaks manage out. When you enable a traffic filter, all inbound access to the machine is denied. Alternatively, you could put a firewall between the VPN server and your LAN and enforce restrictions there if you like.

  75. assy

     /  September 12, 2018

    Hello, and thank you for many good advices and tutorials Richard.
    We’ve set up both DeviceTunnel and UserTunnel, and they both seem to work as expected. Exept one thing, dns search suffix for internal domain and dns lookup fails, which means the the computer cannot comunicate with the domain, internal resources arent available (unless you use the ip address directly) etc.
    Any idea what is wrong?

    Reply
    • If you haven’t done so, you’ll need to add your internal DNS suffix to the profile XML. That will ensure that VPN connections use your internal DNS suffix when performing queries.

      Reply
      • assy

         /  September 13, 2018

        For the user-tunnel, I’ve added the DnsSuffix under the DomainNameInformation. This is my VPN_Profile.ps1 script : https://pastebin.com/f97B9Rfk
        The tunnel connects just fine, but dns-queries does not seem to work, internal a-records wont resolve.

        For the device-tunnel, I cant seem to find any documentation on where to put a DnsSuffix.This is my profileXML_device.xml and VPN_Profile_Device.ps1 files :
        https://pastebin.com/pknPJMKi
        https://pastebin.com/rVFDLNsy

      • For the user tunnel, you have DnsSuffix listed in two locations. The first entry is correct, but you need to remove the second one from under DomainNameInformation. As for the device tunnel, the XML syntax is the same. DnsSuffix is below VpnProfile. The VPNv2CSP reference is your friend here. It includes all of the parameters and settings you’ll need to define your ProfileXML. Also, see the VPNv2CSP ProfileXML XSD for examples too.

  76. ced666

     /  September 13, 2018

    Hi Richard,

    is it possible in tunnel device mode to store the private key ie the computer certificate on a USB key or a smart card?

    There is no documentation on this subject.

    Patrick

    Reply
  77. Simon Brunner

     /  September 13, 2018

    Great article! Did you ever deploy an device tunnel vpn profile with sccm? Any tips or instruction? Thanks!

    Reply
    • I have not. I don’t have any experience with SCCM. However, I’ll look for some documentation and post that when I have it.

      Reply
    • Thorsten Frohberg

       /  September 19, 2018

      The best way for me to deploy with SCCM, is as PowerShell Script with Compliance Baseline. But that works only for the DeviceTunnel, for the UserTunnel you need a Application or Package.

      Reply
  78. Hello Richard,

    i use your guide to create a VPN Profile for DeviceTunne. When i execute my script as local admin, it works fine and create the VPN profile. When i execute my script as local system by psexec, then i become a failure “Unable to create DeviceTunnel profile: “A generic error has occurred for which no more specific error code is available.” and the VPN Profile are not created. The error come by this command: “$null = $session.CreateInstance($namespaceName, $newInstance)”

    have you a idea?

    Reply
    • I would suspect there’s an issue with your ProfileXML. That’s really the only time I’ve seen that error.

      Reply
    • Thorsten,

      Is it a connection you’ve created before and then deleted? I had a similar experience whereby I couldn’t create one with a particular name. I kept getting the same unhelpful error. It turned out that the system still had a previous connection with the same name in the registry but it wasn’t displayed in the Network Connections list. I had to search through the registry and manually delete it before I could create a new connection with the same name.

      I found parts of it in:
      Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections
      and
      Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\Config
      There may well be other occurrences. You’ll have to search.

      The only other time I’ve seen this is when (as Richard said) there’s a problem with your ProfileXML. In particular, I was caught out by using the wrong case for the word ‘True’. For me it had to be all lower case. e.g. true
      I could hardly believe it at the time, but it has to be the correct case. I notified Microsoft and they very kindly added it as a note on their documentation.

      Hope some of that helps.
      Andy.

      Reply
  79. Thorsten Frohberg

     /  September 15, 2018

    Hello Richard,
    i will Deploy DeviceTunnel and the UserTunnel under LOCAL SYSTEM with Powershell Script by SCCM Compliance Settings. When i do this, then i have two VPN AllUserConnections. Is this supportet ?
    Another question, when i set in the User XM Profile Domain Informations, then it’s added automatically NetworkTrustedDetection with the DomainName in the WMI VPN Profile. How i can prevent it? The last question, can i use the DNSSuffix XML Option for a DNSSuffix Search list, i mean add more as one DNSSuffix separeted by comma?

    Reply
    • Only the device tunnel should be configured in the system context. The user tunnel is always created in the context of the user. TrustedNetworkDetection is only added if you’ve specified that in your ProfileXML. I’m not aware that it is added automatically. More than one DNS suffix can be included by creating a comma-separated list, according to the VPNv2CSP.

      Reply
      • I only add the Domain Information like this:

        ‘ + $DomainName + ‘
        ‘ + $DNSServers + ‘

        After create the VPN Profile, i can see in the wmi the trustednetworkdetection entry

        Get-WmiObject -Namespace root\cimv2\mdm\dmmap -Class MDM_VPNv2_01

        TrustedNetworkDetection : “exactly the same like DomainName under DomainNameInformation. ”

        I have no TrustedNetworkDetection Information in the Profile. When i delete the DomainNameInformation from the profile XML and recreate, then it also deletes the TrustedNetworkDetection from the wmi.

        Another question: Only add the DomainInformation in the UserTunnel for route all traffic to this domain by the UserTunnel isn’t enough, right? I must also add the Network Route? In my Lab, without the Network Route in the Usertunnel, it doesn’t work. But when i must add the Route, for what i need the DomainnameInformation?

      • Interesting. Perhaps the trusted network is implied? I’ll have to do some testing and see if I have the same results. And yes, the domain name information is only used for routing DNS queries to specific name servers. You must still have routes specified for network traffic to be able to reach its destination. 🙂

  80. Ian Burnell

     /  September 17, 2018

    Starting to test Device Tunnels. Seems good. Couple of issues
    1. How does the user know it is connected? – with user tunnel you see the VPN connection – with machine although working fine nothing seems to be visible for user other than a smooth logon!
    2. ForceTunnel. Couple of other people have asked this. I can only get the profile to create with profilexml set to splittunnel. Set it to ForceTunnel and the VPN Profile will not create. It will create an entry if you change the DisableClassbased routing to false but it doesn’t appear to connect on the VPN server. If we leave as split tunnel there’s no filtering on user access to bad websites and downloading viruses onto company laptop

    Reply
    • There is no good way for the user to know if a device tunnel is established. To be honest, it isn’t really necessary as the device tunnel is for pre-logon connectivity or for manage out. The user doesn’t really need to know (and shouldn’t really care!) if the device tunnel is up. As for split/force tunnel, both should work for the user tunnel. I’m not certain if it will work (or if it is even necessary) for the device tunnel however.

      Reply
  81. Simon42

     /  September 19, 2018

    Hello

    I have a functioning Device Tunnel. However I will not automatically connect before windows logon (like DA). The device tunnel will not be connected until I logon with a user.

    Is this not possible or am I doing something wrong ? 🙂

    Reply
    • Have to assume something is wrong. The device tunnel most certainly can be established before the user logs on. Are you creating the device tunnel in the context of the system account?

      Reply
  82. Hello Richard,

    i have now configure both Tunnels without trusted network detection, and the public vpn name is blocked from internal DNS. I deploy the device Tunnel as LOCAL SYSTEM, and the UserTunnel with SCCM Package per User. The UserTunnel is set as Force Tunnel, the DeviceTunnel is set as Split Tunnel with Routes to the DC, internal DNS Server and SCCM ManagementPoint. The first Thing is, the User Tunnel is set to automatic, but always start as SSTP. I want to prefer it as IKEv2 and only as Backup SSTP. When i set the connection type to IKEv2, then it works as IKEv2, not ports are blocked. Another thing is, when i start the UserTunnel, then the DeviceTunnel are disconnect, and connect automatically again and disconnect the Usertunnel again. Thats like a PingPong Game. Without deployed DeviceTunnel, the UserTunnel works well, and without deploeyd the userTunnel, the deviceTunnel works well.

    What is worng with my Setup?

    Reply
    • The behavior of IKEv2 with SSTP fallback is broken and does not work as advertised. In fact, if you define your native protocol type in ProfileXML today it will always use SSTP first. Hoping that will be addressed in a future release of Windows. As it stands today, IKEv2 means IKEv2, “automatic” means SSTP. :/ As for your device tunnel/user tunnel issue, that’s a known issue that’s being looked at by Microsoft as we speak. You’ll need to be running Windows 10 1803 with the most recent cumulative update (September 2018) to have the best chance of success.

      Reply
  83. Ian Burnell

     /  September 20, 2018

    Also having issue with Proxy. On user connection can set Proxy pac file and works fine. Same setting for machine is only set for Administrator – blank for user. How can I get round this?

    Reply
  84. Simon Brunner

     /  September 21, 2018

    Hi Richard, one more question. When deploying the Profile with Powershell and XML File, everything is working fine. But under Settings -> VPN I can’t see any VPN Profile. The additional Adapter is visible. But the user can’t see if he is connected or not. Any guessing?

    Reply
    • Expected behavior. The device tunnel is for the machine, not the user. No need for the user to monitor its status, so it doesn’t appear in the UI. It still appears in the Network Connections control panel app though.

      Reply
  85. Hi Richard,

    just to tell you that I tried to implement the element in the XML file for a tunnel device connection.
    The tunnel continues to establish even when I am connected in the internal network.
    Does the directive work well? I am with the version of Windows 10 1803.
    I feel that this direction does not work. I do not understand why the tunnel is always mounted even when I’m connected inside the network.
    internaldomain.com

    Thank you

    Reply
    • If you configure the TrustedNetworkDetection element matching the internal DNS suffix used by your domain then it should work. It’s not there by default, so make sure it’s present and let me know what happens. 🙂

      Reply
      • Hello,

        as I told you, using the mydomain.com element, the tunnel is always mounted even when I’m on the internal network.

      • As long as the DNS suffix is defined correctly and matches the suffix used on your internal domain it should work. I’ve not seen a scenario where it doesn’t yet. Are you certain the TrsutedNetworkDetection element is defined in the correct location in your ProfileXML?

      • Hello Richard,
        I am sure: TrusteedNetworkDetection element is good defined in the correct location in my Profile XML::

        Example:

        mydomain.com
        ….
        …..
        …..

        mygateway
        ….
        ..


        Another question ?

        is the LockDown mode compatible with the trustedNetworkDetection element?

        I guess the LockDown mode goes past the posture detection (internal or external Enterprise)

        Thank you

        Patrick

      • I’m not sure about LockDown mode and TrustedNetworkDetection. I’ve done no testing at all with LockDown mode to this point.

  86. Ian Burnell

     /  October 13, 2018

    Hi Richard. Piloting 1803 with Device Tunnel – working well. Couple of questions.
    1. We have Corporate Wi-Fi that kicks in when user takes device off ethernet. Sometime AOVPN is kicking in – is this a timing issue? because it shouldn’t be connecting on the Corporate network
    2. Debate about 2FA/security given the tunnel is formed before login. Is a Bitlocker pin plus NT logon considered secure enough – its not strictly 2FA. Concern is over if the device is stolen with a machine link into the Corporate network

    Reply
    • Shouldn’t connect if trusted network detection is configured correctly. However, there are currently a number of issues with this feature that preventing it from working correctly, and this could be another one. :/ As for 2FA, ultimately you have to decide if device certificate and boot PIN are sufficient for your requirements. I do seem to recall that it was acceptable for DirectAccess to use this configuration without traditional OTP/MFA to meet CPA requirements. I’d think the same would apply to Always On VPN too.

      Reply
  87. Nikodemus

     /  October 18, 2018

    Hi,
    I’m using AlwayOnVpn user tunnel and want to check the box for “register in dns”. Manually it works, yes. But how can I get the box checked via the .ps script. For example “ForceTunnel” works just fine to get the box checked for full tunnel.
    I’m using SCCM to deploy the script.
    Please help!

    Reply
    • You’ll need to define the RegisterDNS element in your ProfileXML to force client registration in DNS.

      Reply
      • Nikodemus

         /  October 26, 2018

        Thanks! Working fine.
        But I also need to check the box beneath; “use this connection’s dns suffix in dns registration”. Is there any definition to set this as well? Or how can it else be done..

      • I’m not aware of any way to do that using ProfileXML. If you specifically need that setting you’ll likely have to use PowerShell and/or WMI to enable it after configuration.

      • Colin

         /  October 29, 2018

        My experience is that the device tunnel registers the correct IP only sometimes. It doesn’t seem consistent at all. One time it is the tunnel IP, other times it is the NAT’d IP the client is getting from its own router/gateway. Frustrating.

      • Yes, there are a number of known issues with Always On VPN tunnel stability and operation. If you’ve not already done so, try updating to Windows 10 v1809. There have been a number of improvements for Always On VPN in this latest release.

      • Colin

         /  October 29, 2018

        As soon as 1809 comes back I will give it a shot. I plan on reviewing many of the stability issues/bugs with premiere support this week. I really hope they can address them.

      • I can tell you they are being worked on. Let me now how you get on. 🙂

      • Nikodemus

         /  November 5, 2018

        Sorry but cannot get this working with powershell/wmi.
        I have tried different ways but no luck. Anyone that have managed to change the value “use this connection’s dns suffix in dns registration” with help of powershell/wmifor for the AlwaysONVPN user tunnel??

  88. Matt

     /  October 22, 2018

    I have questions about providing AOVPN access to users logged into computers not joined to our domain.
    Can laptops be configured with Powershell without local administrator access to the Windows 10 device?
    If we have external partners with hundreds of Windows 10 pcs that need access to limited resources inside our network, what are the best options to deploy the configuration and the user certificates? We won’t be able to manage their devices with Intune since we don’t control them.
    Can we send their IT departments the config settings for them to deploy to the authorized users with their SCCM?

    We would also need a secure way to deploy the user certificates to these external users.

    I assume devices joined to foreign domains won’t be able to authenticate with device certificates and we will need to create domain user accounts for the users and assign them user cents.

    Reply
    • Users must have local administrative rights to run the PowerShell script and create a VPN profile. You can deploy Always On VPN to non domain-joined devices, but that’s typically done using Intune or third-party MDM. You can also provision client certificates to users, but they’ll need an account in your ms Active Directory or Azure Active Directory. There’s no way to provision machine certificates using Intune (today anyway), but in theory you could create these certificates and export them as PFX and deploy them that way. Probably won’t scale very well, but it would work.

      Reply
      • Matt

         /  October 23, 2018

        So, the profile settings can’t be configured within their user profile so system level access isn’t required? If not, I guess the users without admin access won’t be able to connect.
        The users will have user accounts on our domain even if they don’t have a device joined to our domain.
        Maybe there is some way to bulk create user certificates for external users with PowerShell then distribute the certs to the users in a secure way. Unfortunately, we cannot install and manage Intune or any other MDM on other company’s computers.

      • The device tunnel runs in the context of the system account and requires administrator rights to configure. However, users can certainly access the device tunnel after they log in. However, users would also need administrator rights to create the user tunnel too, which is why it is recommended to use Intune or SCCM. The question is…if these computers don’t belong to you and you don’t manage them, why the need for “always on” VPN? Seems like it would be better to grant ad-hoc VPN access and use an MFA solution such as Azure MFA or DUO to protect logins rather than certificates. Just a thought. 🙂

  89. Simon Brunner

     /  October 23, 2018

    Hi,
    we deployed the Always On VPN Environment as described in Microsoft article. As soon as we connect with a client (device tunnel or user tunnel) the routing is completely messed up. Suddenly all internal ressources like file servers, are addresses with the public IP-Address from the RAS Server. We have the same setup in a different environment in place with no problem. Any guessing what causing the problem?
    Regards

    Reply
    • Hard to say. Best practice is to disable the default class-based routing and define your own specific routes in your ProfileXML. If you are using DHCP, ensure that you have selected the internal interface on the RRAS server.

      Reply
      • Simon Brunner

         /  October 24, 2018

        Is it possible that its only working when we have a non routable domain (like *.local)? because the on who is working has a local domain, the other one has a public routable domain name.

      • It should work with any domain, public or private.

  90. Steve

     /  November 13, 2018

    Great steps, the only problem I seem to be having is automating the deployment of the device tunnel profile? I’m running in to problems with the script passing the steps from the command prompt, in to the PS window (opened using psexec -i -s)? I’ve done the following..
    @echo off
    psexec.exe -i -s PowerShell.exe -noexit -command ”
    ‘.\Add VPN.ps1’ -xmlFilePath ‘.\Device Tunnel VPN Profile_RemovedTrafficFilter.xml’ -ProfileName Test_Device_VPN”

    If anyone is able to help…… I’ll give you a big kiss!!!

    Reply
    • Steve

       /  November 13, 2018

      finally got it working. I’m sure I did this to start with…. obviously not!

      set dir=”%CD%”
      psexec.exe -i -s PowerShell.exe -command “&’%dir%\Add VPN.ps1′ -xmlFilePath ‘%dir%\Device Tunnel VPN Profile.xml’ -ProfileName TEST_Device_VPN'”

      Reply
      • Steve

         /  November 15, 2018

        The above worked when you ran it from an elevated command prompt, but didn’t when you ‘double clicked’ the bat file. The below does though…

        @echo off
        pushd %~dp0
        set “dir=%CD%”
        .\PsExec.exe -i -s PowerShell.exe -command “&’%dir%\Add VPN.ps1′ -xmlFilePath ‘%dir%\Device Tunnel VPN Profile_RemovedTrafficFilter.xml’ -ProfileName ‘ISS_Device_VPN'”

        Is there a way you can modify the profile without having to remove and re-add the modified file?

        Thanks

      • Not really. There are some settings that can be changed/updated after the VPN profile is configured using PowerShell, but the ProfileXML can only be applied once. If you want to make changes to your XML configuration, you will have to remove the connection and recreate it.

      • Colin

         /  November 19, 2018

        SCCM helps with this if you use it.

        Create a new PowerShell script to call the device tunnel script and at the beginning of the new script add some more powershell code to find the existing device tunnel, disconnect it with rasdial, then remove the profile. Follow that code with the command to install the profile again with the settings/xml file.

        SCCM caches the package so even if they lose connectivity or can’t get the new package with the updated xml, they can click re-install through the software center and it will just reinstall the previous one to get them back up and running while you troubleshoot why they didn’t get the new one. But if everything is configured correctly they should be able to get the new xml file through the updated revision of the package when the client checks in. This is if you want them to manually update their profile to the new one.

        If you want to force the new one out, delete the existing deployment and create a new one. This should force it out.

  91. Some Guy

     /  November 13, 2018

    So with Device Tunnel, how to restrict what/who can connect to the VPN server?

    From my reading, it looks like anybody who owns any Client Authentication cert signed by the enterprise CA could manually configure a VPN client to connect to the VPN server using that cert.

    So are people setting up and maintaining a separate enterprise CA dedicated just for VPN certs? Or are people just accepting the fact that a RRAS server configured for Device Tunnel has essentially no access-control whatsoever?

    Reply
    • It is strongly recommended that the device tunnel authentication certificate be issued by a private, internal certification authority (CA). The majority of organizations who are deploying Always On VPN already have an internal private CA deployed, or they deploy one in support of the project. It is not recommended to use a public CA for device tunnel authentication because, as you noticed, pretty much anyone could connect. 🙂

      Reply
      • Some Guy

         /  November 19, 2018

        Yeah but my concern is that using a private CA does not fix that. Anyone who has a private internal CA is very likely to already be using “Client Authentication” certs for something unrelated to AO-VPN and/or has users/devices that have permission to request “Client Authentication” certs for something unrelated to AO-VPN. It would be inappropriate to blindly allow all these users/devices to connect to the VPN.

        The directions in this article (and also Microsoft’s documentation) will leave your RRAS server wide open to connections from anyone/anything that has a “Client Authentication” cert from the enterprise CA, regardless of whether that user/device is actually supposed to be allowed to connect. It’s starting to feel like I’m the only person on the Internet who seems to care about this gigantic hole. 😦

        Well, since my original comment, I discovered that it is possible to use a custom EKU instead of “Client Authentication”. Then you can restrict enrollment permission on the cert template having this EKU. It strikes me as completely reckless that people are not doing this, and completely irresponsible of Microsoft to be providing instructions that don’t cover this. Here’s how:

        On the server, use the Set-VpnAuthProtocol cmdlet and set the -CertificateEKUsToAccept parameter to the numerical version of your custom EKU. The cmldlet will warn that it’s not a valid EKU, but it works nonetheless. This makes the RRAS server require the custom EKU instead of “Client Authentication”.

        On the client, we run into a little stumbling block thanks to Microsoft’s failure to completely finish implementing the AO-VPN feature. The schema for ProfileXML allows you to specify the custom EKU under but it doesn’t work. The schema documentation says it is “for future use.” It has said that since several versions ago. (Thanks, Microsoft!)

        So the workaround is after deploying the ProfileXML to the client, use the Set-VpnConnection cmdlet and set the -MachineCertificateEKUFilter parameter. This controls which local certificate(s) the client will look at when deciding which one to use for VPN login. Hopefully Microsoft will one day get off their butts and finish their ProfileXML implementation so that this can be configured within the XML instead of having to run a separate PowerShell cmdlet.

        I think there needs to be much greater awareness of this because most people are probably not aware that it is a bad idea to implement an RRAS VPN server with no access control. !!!

      • A private key drastically reduces your exposure for sure, but I agree, within the context of your organization’s PKI you could have issued client authentication certificates for other purposes and someone could use that to access the VPN. I’m not sure I would categorize it as a “gigantic” hole, but it certainly does allow for the possibility of rogue access. This is why it is essential, IMO, to deploy the device tunnel only when absolutely necessary, and to limit access over the device tunnel. That said, you bring up an excellent point that you can provision certificates with a custom EKU to further restrict access. An excellent idea for sure. 🙂

      • Colin

         /  November 20, 2018

        Isn’t access somewhat restricted further for devices where the end user does not have administrative rights?

        If they cannot install a device profile, they cannot connect the device?

        Still seems like Microsoft needs to address this though.

      • Some Guy

         /  November 21, 2018

        Well, the goal is to prevent rogue devices from being able to connect. I don’t know about you, but I don’t have the ability to control who has administrative access to rogue devices. That’s what makes them rogue.

        It only needs to be a device profile for the purpose of getting the always-on-even-when-logged-out functionality on the client. The RRAS server doesn’t know or care if the client is using a device profile, a user profile, an iPhone, Android, Linux client, etc. All RRAS cares about is that the client presents a “Client Authentication” certificate. The actual client that’s connecting could be any VPN software on any kind of device as long as you can get the cert+key to it.

        So anyone/anything who legitimately has a “Client Authentication” cert+key (or has the permission to enroll for one) could take that cert+key and configure any VPN client to use it.

      • Agreed. This illustrates clearly why it is important to follow certificate issuance best practices and ensure that certificate keys are always stored on a TPM. 🙂

      • Colin

         /  November 23, 2018

        I’m surprised that Microsoft is OK with this. Perhaps it will be enhanced in the future to allow for additional authentication/restrictions.

      • I’m not. Windows Server RRAS still uses 3DES encryption for IKEv2 by default. 😉 I doubt very seriously they’ll make any changes to this. RRAS just isn’t that important to Microsoft in the grand scheme of things. :/

      • Colin

         /  November 26, 2018

        Doesn’t Microsoft view Always On VPN as an eventual replacement for DirectAccess? If they do, I would hope they would at least consider improving these basic areas. Or do they perhaps view Always On VPN utilizing third-party VPN solutions as the future and not RAS?

        I haven’t seen any information regarding a third-party VPN deployment using Always On VPN. Even with a third-party VPN, I imagine the device tunnel (IKEv2) issue would remain the same.

      • Indeed Microsoft probably envisions the use of third-party devices for VPN connections a better choice over RRAS. Any documentation for implementing Always On VPN with third-party infrastructure would of course be produced by those third-parties.

  92. Jonas

     /  November 21, 2018

    I have just set up a device tunnel, for a customer who was on DirectAccess. Now the issue is, that all the users who was using DirectAccess does not seem to be able to create a AlwaysON Device Tunnel.
    .I Can create the Device tunnel with the same Powershell script, on another PC, which has not been using Directaccess.

    Info
    The Powershell script Runs fine, and does not generate a error, but no tunnel is created, no adapter is created, and “get-vpnconnection -alluserconnection” shows noting

    Do anyone know what this might be?

    Reply
    • Perhaps it’s an issue with the NRPT? If you are using split DNS, you will need to exclude the VPN server’s public hostname from the NRPT. Other than that I think it should work. 🙂

      Reply
    • Steve

       /  November 22, 2018

      Hi Jonas, Is the script run from an elevated command prompt, using psexec to launch powershell as system account?

      Reply
  93. Hi Richard,

    when using the TrustedNetworkDetection element, in the XML configuration file, what exactly is the VPN client asking for to determine that it is on the internal or external network of the enterprise? is it a ping or DNS query?
    I thank you in advance

    Reply
    • When TrustedNetworkDetection is defined, the VPN client looks at the DNS suffix for any/all physical network connections (Ethernet, Wi-Fi, etc.). If the defined DNS suffix is recognized on any physical interface the VPN connection will not be established.

      Reply
  1. Deleting an Always On VPN Device Tunnel | Richard M. Hicks Consulting, Inc.
  2. Always On VPN RasMan Device Tunnel Failure | Richard M. Hicks Consulting, Inc.
  3. Always On VPN Certificate Requirements for IKEv2 | Richard M. Hicks Consulting, Inc.
  4. Deploying Windows 10 Always On VPN with Microsoft Intune | Richard M. Hicks Consulting, Inc.
  5. Deploy Always On VPN Profile Device Tunnel with GPO – Remove-Item
  6. Deploy Always On VPN Profile Device Tunnel with GPO – Remove-Item.com
  7. Always On VPN Device Tunnel Missing in Windows 10 UI | Richard M. Hicks Consulting, Inc.

Leave a 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: