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

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

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

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 )

w

Connecting to %s

%d bloggers like this: