Windows 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. For example, pre-logon connectivity is required to support remote logon without cached credentials. To address this issue and to provide feature parity with DirectAccess, Microsoft introduced support for a device tunnel configuration option beginning with Windows 10 version 1709 (Fall creators update).
Learn Windows 10 Always On VPN today! Register for an upcoming Always On VPN Hands-On Training class. More 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) or later. 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).
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.
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
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
To verify creation of the VPN device tunnel, run the following PowerShell command.
Get-VpnConnection -AllUserConnection
Note: In Windows 10 releases prior to 1903 the ConnectionStatus will always report Disconnected. This has been fixed in Windows 10 1903.
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
Limitations
Using PowerShell to provision an Always On VPN device tunnel is helpful for initial testing and small pilot deployments, but it does not scale very well. For production deployments it is recommended that Microsoft Intune be used to deploy Always On VPN device tunnel.
Deploy Device Tunnel with Intune
Guidance for deploying an Always On VPN device tunnel using Microsoft Intune can be found here. You can also view the following demonstration video that includes detailed guidance for provisioning the Always On VPN device tunnel using Microsoft Intune.
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
Deploy Windows 10 Always On VPN Device Tunnel using Microsoft Intune
VIDEO: Deploying Windows 10 Always On VPN Device Tunnel using Microsoft Intune
Windows 10 Always On VPN Device Tunnel Does Not Connect Automatically
Windows 10 Always On VPN Device Tunnel Does Not Appear in the UI
Windows 10 Always On VPN Hands-On Training
Michael de Cler
/ December 18, 2017We 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..
Richard M. Hicks
/ December 20, 2017Unusual 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. 🙂
Azad Sofi
/ March 6, 2018Hi 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
Nico Junge
/ December 22, 2017The 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?
Richard M. Hicks
/ December 27, 2017The 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. 🙂
Alex Ø. T. Hansen
/ December 22, 2017Hi 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
Richard M. Hicks
/ December 27, 2017Interesting. 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. :/
Alex Hansen
/ December 27, 2017Hi 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.
J
/ February 27, 2018Did this ever get resolved?
Richard M. Hicks
/ February 28, 2018Not 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. 🙂
J
/ February 28, 2018Thanks. 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. 🙂
Richard M. Hicks
/ March 1, 2018Sounds 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, 2018Thanks for the suggestions, I tried those permutations and a few others. Unfortunately no change. Hopefully Patch Tuesday will bring a present.
Peter Enoch
/ January 1, 2018Hi 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?
Richard M. Hicks
/ January 2, 2018The 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.
Peter Enoch
/ January 8, 2018Hi Richard, thanks for your reply. That is typically Microsoft 🙂
alexanderfray
/ January 10, 2018Hi 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?
Richard M. Hicks
/ January 10, 2018Yes, 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.
Alex Hansen
/ January 22, 2018Hi 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
Richard M. Hicks
/ January 27, 2018Absolutely. You’ll define them using the ./User/Vendor/MSFT/VPNv2/ProfileName/DomainNameInformation URI. 🙂
Alex Hansen
/ January 27, 2018Also for a device tunnel?
Isn’t “./User” for a user deployment rather a device, or am I wrong?
Richard M. Hicks
/ January 27, 2018Yes, if this is for a device tunnel then you’ll use the ./Device path. 🙂
Miljan
/ October 6, 2020Where I suppose to add this URI? In the configuration script or in XML?
Thanks in advance
Richard M. Hicks
/ October 13, 2020You can configure this natively in the Intune UI or in ProfileXML if you are using PowerShell. The URI is not defined in the XML, it is the location where the XML file is loaded. That’s handled by the PowerShell script you use to install the profile with.
Matthew
/ February 5, 2018Can 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.
Richard M. Hicks
/ February 5, 2018As 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. 🙂
Tony
/ February 16, 2018Do 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.
Richard M. Hicks
/ February 16, 2018You 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.
Tony
/ February 19, 2018Thanks 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.
Tony
/ February 20, 2018Thanks 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.
Richard M. Hicks
/ February 20, 2018It 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!
Tony Wood
/ February 22, 2018Thanks 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.
Richard M. Hicks
/ February 24, 2018No, it should be an internal proxy server reachable over the VPN connection.
Andrew
/ February 21, 2018I 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?
Richard M. Hicks
/ February 24, 2018That’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.
Eric
/ February 25, 2018Can 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
Richard M. Hicks
/ February 26, 2018NPS 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. 🙂
PJ
/ February 21, 2023I ran the command for the RRAS server to use when accepting the client cert. Is there an additional command needed to specify which cert the RRAS server should send to the client for authentication? This cert is in the proper place on the RRAS cert store. And in the Authentication Methods on the Security tab of the RRAS properties, the only box I have checked is “Allow Machine cert auth for IKEv2”, but nowhere have I identified that cert specifically.
Richard M. Hicks
/ February 27, 2023No, that should be all that’s required.
Mincey
/ February 28, 2018We 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?
Richard M. Hicks
/ February 28, 2018You’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.
yannara
/ March 1, 2018The 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.
Richard M. Hicks
/ March 1, 2018That’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!
Tony
/ March 5, 2018I’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?
Richard M. Hicks
/ March 10, 2018Not 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.
Marko
/ March 7, 2018Hey,
is it possible to configure a fallback to SSTP when IKEv2 is blocked ?
Thanks !
Richard M. Hicks
/ March 10, 2018Absolutely! Just specify “automatic” for the NativeProtocolType in your ProfileXML.
Eric Yew
/ July 30, 2018Can SSTP utilise Machine Certificate? If yes, how would this be configured as the option isn’t there.
Richard M. Hicks
/ July 31, 2018It cannot. Machine certificate authentication is not supported natively by the protocol.
Colin
/ October 16, 2018My 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.
Richard M. Hicks
/ October 20, 2018That’s correct. Hoping that Microsoft will address this limitation in a future release. 🙂
Colin
/ October 22, 2018I’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*
Richard M. Hicks
/ October 23, 2018Odd!
Richard M. Hicks
/ October 23, 2018Odd!
Matthew
/ March 10, 2018I 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?
Richard M. Hicks
/ March 10, 2018The 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.
Matthew
/ March 15, 2018Will Always On VPN work on Windows 10 Enterprise systems running in “S Mode?”
Richard M. Hicks
/ March 21, 2018I have no idea. I expect it will though. I’ll have to test it out sometime soon I guess. 🙂
Christian
/ March 15, 2018Hey,
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
Richard M. Hicks
/ March 21, 2018The 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).
Johnny M. Forp
/ March 23, 2018I 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?
Richard M. Hicks
/ March 23, 2018I 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.
Johnny M. Forp
/ March 23, 2018Wish they would get the kinks worked out as I greatly prefer this over some of the alternatives. Thank you for the response!
Richard M. Hicks
/ March 23, 2018Hopefully soon. 🙂
Sossage
/ March 29, 2018Hi 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.
Richard M. Hicks
/ March 29, 2018Only 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.
Andy
/ April 6, 2018Windows 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?
Richard M. Hicks
/ April 6, 2018Known issue. Microsoft is working to resolve as we speak. Hoping to have a fix included in RS4. Stay tuned!
Patrick
/ April 12, 2018Hi 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
Richard M. Hicks
/ April 14, 2018The client machine would need to be connected to the Internet for this to work. If you are testing in a lab environment you’ll need to spoof the Internet as described here: https://blogs.msdn.microsoft.com/canberrapfe/2012/10/09/fake-internet-connectivity-for-your-lab-tricking-ncsi/.
Regarding the OMA URI for the VPN settings, that’s something you would use if you were deploying the ProfileXML using MDM. No need to worry about that if you are using the PowerShell to deploy the profile.
Mike Pietrorazio
/ April 17, 2018Hi, 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?
Richard M. Hicks
/ April 23, 2018You 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/.
Mike Pietrorazio
/ April 23, 2018Sounded 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
Richard M. Hicks
/ April 24, 2018Unusual, 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.
Mike Pietrorazio
/ April 24, 2018I 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.
Mike Pietrorazio
/ April 24, 2018Strange, I removed all the DomainNameInformation DNS related tags out of the profile, and am still getting full internal resolution.
Richard M. Hicks
/ April 24, 2018That’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.
Mike Pietrorazio
/ April 25, 2018So 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.
Richard M. Hicks
/ April 27, 2018That’s odd. Definitely not been my experience. :/
Wes Lazara
/ April 20, 2018Yikes, what a mess judging from the comments here and elsewhere! Sounds like DirectAccess is still the way to go for the time being…
Richard M. Hicks
/ April 21, 2018I’ll agree that some of this technology isn’t quite fully baked at the moment, but hoping it will get better soon for sure. 🙂
ND
/ April 20, 2018Hi 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
Richard M. Hicks
/ April 21, 2018Agreed, 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!
Andy
/ April 23, 2018Would 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
Richard M. Hicks
/ April 23, 2018That would certainly work. 🙂
ND
/ April 23, 2018Hi 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
Richard M. Hicks
/ April 23, 2018Well, 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? 🙂
ced666
/ April 23, 2018Hi 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
Richard M. Hicks
/ April 23, 2018You 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.
ced666
/ April 24, 2018Hi 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
Richard M. Hicks
/ April 24, 2018Odd. I’ll do some testing myself soon and see what I come up with.
Patrick
/ April 30, 2018Hello 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
Richard M. Hicks
/ May 3, 2018I’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?
Matt
/ May 5, 2018Hi 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
Richard M. Hicks
/ May 5, 2018Thanks 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.
Tony
/ May 7, 2018Is 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
Richard M. Hicks
/ May 10, 2018I 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, 2018I’ve notice since updating to 1803, The user tunnel connects with SSTP instead of IKEv2.
Richard M. Hicks
/ May 10, 2018If 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, 2018Just tried it after the 1803 cumulative update. Yes, I can manually establish an IKEv2 connection.
Richard M. Hicks
/ May 10, 2018Ok, 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, 2018Hi 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
Richard M. Hicks
/ May 10, 2018Ok, 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. 🙂
MaxG
/ May 7, 2018Hello 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.
Richard M. Hicks
/ May 10, 2018If 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. 🙂
Patrick
/ May 9, 2018Hello 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
Richard M. Hicks
/ May 10, 2018Not 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!
Dan
/ May 15, 2018Hi 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
Richard M. Hicks
/ May 16, 2018Haven’t done any testing as of yet. Hope to do so soon. I’ll keep you posted!
Dan
/ May 17, 2018Thank you
ced666
/ May 15, 2018Hello 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 ?
Richard M. Hicks
/ May 16, 2018Interesting. 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!
Mike
/ May 17, 2018I 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, 2018I 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.
ced666
/ May 18, 2018Hello,
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 ?
Richard M. Hicks
/ May 21, 2018I have not done any testing with lockdown mode. At this point I’ve not come across a requirement for its use.
ced666
/ May 22, 2018Hello,
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.
Richard M. Hicks
/ May 22, 2018That’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!
ced666
/ May 18, 2018Hello,
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.
Richard M. Hicks
/ May 21, 2018Yes, 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.
ced666
/ May 22, 2018Hello,
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 ?
Richard M. Hicks
/ May 22, 2018If 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, 2018Hello
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?
Richard M. Hicks
/ May 22, 2018That’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, 2018Hello,
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.
Richard M. Hicks
/ May 23, 2018That’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.
Raphael Eymann
/ May 18, 2018I’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?
Richard M. Hicks
/ May 21, 2018It 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.
Raphael Eymann
/ May 23, 2018I 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 …
Richard M. Hicks
/ May 23, 2018Good to hear the Register DNS setting is working reliably now! 🙂
Ben Morgan
/ May 28, 2018Hopefully 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.
Richard M. Hicks
/ May 30, 2018The 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.
Patrick
/ May 31, 2018Hi 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?
Richard M. Hicks
/ May 31, 2018In the Windows Event Viewer in Windows Logs/Application. The event source will be RasClient.
andychips
/ June 1, 2018I’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?
Richard M. Hicks
/ June 2, 2018When 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.
andychips
/ June 4, 2018Richard,
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’ ?
Richard M. Hicks
/ June 4, 2018If 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.
andychips
/ June 4, 2018OK, 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.
Richard M. Hicks
/ June 4, 2018Great 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. 😉
ced666
/ June 4, 2018Hi 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
Richard M. Hicks
/ June 5, 2018Send 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.
ced666
/ June 5, 2018Hello Richard
Thank you very much
ced666
/ June 5, 2018Hello,
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
Richard M. Hicks
/ June 8, 2018No. The device tunnel is supported only on Windows 10 Enterprise edition clients that are joined to a domain.
Colin Pazdzior
/ June 5, 2018Hi 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
Richard M. Hicks
/ June 5, 2018Thanks 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.
Colin Pazdzior
/ June 5, 2018Thanks 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….
Richard M. Hicks
/ June 5, 2018Thanks 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.
Mike Pietrorazio
/ June 6, 2018Can 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.
Richard M. Hicks
/ June 8, 2018Is your client running Windows 10 Enterprise edition?
Mike Pietrorazio
/ June 8, 2018Yes, it’s Enterprise.
Richard M. Hicks
/ June 8, 2018Ok, just making sure. 🙂 Not sure what’s up really. Have a close look at routing tables and metrics. Easy to get tripped up there.
Aaron Silber
/ June 6, 2018Hi 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!
Richard M. Hicks
/ June 8, 2018No, 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.
ced666
/ June 6, 2018Hi 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
Richard M. Hicks
/ June 8, 2018That is incorrect. The device tunnel is supported only on Windows 10 Enterprise edition clients that are joined to a domain.
Colin Pazdzior
/ June 8, 2018The 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?
Richard M. Hicks
/ June 8, 2018Are you using user certificate authentication?
Colin Pazdzior
/ June 11, 2018For 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.
Richard M. Hicks
/ June 11, 2018You’ve published the Azure root certificates in your on-premises Active Directory? https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/vpn-deploy-cond-access-root-cert-to-on-premise-ad
Colin Pazdzior
/ June 11, 2018Yes, and the tunnel connects successfully – all other resources work, just not SMB shares…
Richard M. Hicks
/ June 11, 2018Unusual. 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, 2018Haha, 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, 2018Huh, 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.
Colin Pazdzior
/ June 14, 2018Learned 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!
Jason Jones
/ June 15, 2018When using VPN CA, you need to configure the VPN profile to use a separate certificate for Kerberos Authentication, otherwise SSO will use the Azure AD short lived certificate as the Kerberos identity. Check out the following VPNv2 CSP parameters: VPNv2/ProfileName/DeviceCompliance/Sso/Enabled, VPNv2/ProfileName/DeviceCompliance/Sso/IssuerHash and VPNv2/ProfileName/DeviceCompliance/Sso/Eku and/or the example here: https://docs.microsoft.com/en-us/windows/client-management/mdm/vpnv2-profile-xsd#xsd-for-the-vpn-profile
Richard M. Hicks
/ June 15, 2018Thanks Jason! 🙂
Colin Pazdzior
/ June 20, 2018I’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
Colin Pazdzior
/ June 20, 2018Well 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-
Jason Jones
/ June 21, 2018From 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, 2018So, 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
Colin Pazdzior
/ July 11, 2018Another 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
Richard M. Hicks
/ July 13, 2018Same 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.
Richard M. Hicks
/ July 13, 2018Yes, 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. 🙂
Patrick
/ June 21, 2018Hi Richard,
is it possible to launch the IPSEC VPN tunnel without encryption? ie only ensure integrity?
Thank you
Richard M. Hicks
/ June 21, 2018Not to my knowledge. I can’t really think of a use case where encryption wouldn’t be needed though.
ced666
/ June 22, 2018Hello 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
Richard M. Hicks
/ June 22, 2018Not specifically. You’ve defined the crypto in both the profile XML and on the VPN server as well, correct?
Jason Jones
/ June 22, 2018Those 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
Ian
/ June 25, 2018Hi 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
Richard M. Hicks
/ July 4, 2018I 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.
Patrick
/ July 4, 2018Hello 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
ced666
/ July 4, 2018Hello,
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
Richard M. Hicks
/ July 4, 2018That’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
ced666
/ July 4, 2018Hello,
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
Richard M. Hicks
/ July 4, 2018Yes, 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.
Patrick
/ July 6, 2018Hello 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
Richard M. Hicks
/ July 10, 2018Not natively. However, there’s nothing that prevents you from packaging the PowerShell script and the XML file and deploying that to users.
Patrick
/ July 9, 2018Hello 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
Richard M. Hicks
/ July 10, 2018You 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. 🙂
Patrick
/ November 6, 2018Hello 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
Richard M. Hicks
/ November 9, 2018There 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.
Saravanan
/ July 12, 2018Hi 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?
u3comp
/ July 13, 2018Hi 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.
Richard M. Hicks
/ July 13, 2018Yes, 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.
u3comp
/ July 17, 2018The 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.
Richard M. Hicks
/ July 20, 2018The 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. :/
Patrick
/ July 18, 2018Hello,
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
Richard M. Hicks
/ July 24, 2018Have a look at this article and let me know if it answers your question. 🙂
https://directaccess.richardhicks.com/2018/07/23/always-on-vpn-routing-configuration/
Colin Pazdzior
/ July 20, 2018Hi 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
Richard M. Hicks
/ July 20, 2018I’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?
Ron
/ March 26, 2019Would you please be so kind to share the powershell script with us ?
I’m having the same issue with the VPN connection not being reconnected after a sleep or hibernate.
Richard M. Hicks
/ March 26, 2019You can find this and other useful Windows 10 Always On VPN PowerShell scripts on my GitHub here: https://github.com/richardhicks/aovpn. Enjoy!
Ron
/ March 26, 2019We are using the device tunnel only configuration and there is still this bug where the connection status is always disconnected.
I’m looking for the script that Colin mentioned that checks if any physical adapter is on my corp domain and if NOT and vpn NOT connected, uses rasdial to connect.
I don’t see this script in the repository, I only see scripts for creating new connections. Or is there an easier solution to determine the connection state of the VPN tunnel ?
Richard M. Hicks
/ March 26, 2019Sorry…I thought you were asking about my configuration scripts. 😉 You’ll have to ask Colin about sharing his script. I don’t have it.
Colin
/ March 26, 2019I found the experience to be improved by setting the network adapters to not go to sleep for power mgmt.
Richard M. Hicks
/ March 26, 2019Interesting. How exactly is that configured? PowerShell? Registry?
Colin
/ March 26, 2019It is a bit of a pain because each device can be different with different adapters and different names etc.. Automating it would take some effort and if your org doesn’t standardize on a few models it could be a big PITA.
It helps to do it at the time of OS deployment as a standard build.
Ron
/ March 26, 2019Colin are you still using the powershell script triggered by the scheduled task in the case of the vpn doesn’t reconnect automatically ?
Andy Chips
/ March 27, 2019Re. turning off power management on the network adapter:
I used to think this was a useful workaround until I realised that it shouldn’t have to be this way! Microsoft should just FIX THE UNDERLYING ISSUE!
I don’t consider AlwaysOn to be a credible VPN solution yet, despite all Microsoft’s promotion. With the help of Richard’s book I trialled DirectAccess before this and it just worked. I also thought it was simpler to implement than AlwaysOn. The problem we had was with Manage Out to clients and general slowness due to the SSL encryption. That’s why I started down the AlwaysOn route. I do have to admit that when it works, it’s great.
Owen
/ June 28, 2019Hi, I have literally just finished writing a script to do this. I intend on using task scheduler to trigger the script on various event IDs such as network change, waking from sleep etc etc. I will test it thoroughly on Monday but my preliminary tests look like it’s pretty sound. It’s the weekend now for me (in UK) and beer awaits. Here’s the script I just wrote: https://github.com/ozthe2/AOVPN/blob/master/Start-AOVPN
Once I’ve tested it thoroughly on Monday I’ll also post a step-by-step howto on my blog.
Richard M. Hicks
/ June 28, 2019Great, thanks for sharing! Let me know how your testing goes. Also, enjoy a pint for me! 🍺😁
owen
/ July 12, 2019The script I wrote appears to work rather well. I used a combination of Sapien PowerShell Studio and vbscript to hide the cmd window that pops up when reconnecting using rasdial. One strange issue we are seeing is (unrelated to my script) that sometimes AOVPN status is ‘connected’ but cannot access company resources until we disconnect and reconnect. I’ve updated my script to mitigate against this and I’ll post the revised script over the weekend. Have you seen this issue Richard? We are only using the user tunnel at the moment.
Richard M. Hicks
/ July 14, 2019I am aware of a known with with Windows Server and RRAS (all supported versions) where clients can’t connect via VPN until the server is restarted (restarting the RemoteAccess service is not sufficient). However, that affects all clients. Sounds similar to what you’re seeing, but likely isn’t the same issue.
PATRICK
/ July 24, 2018Bonjoru 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
Richard M. Hicks
/ July 24, 2018Strictly 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.
Jason Jones
/ July 25, 2018More crucially, Windows 10 has no NAP agent so that’s the primary challenge! 😉
ced666
/ July 27, 2018Hi 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
Richard M. Hicks
/ July 29, 2018Certainly. Just replace the XML variable with the actual XML for your connection. 🙂
Terry
/ July 27, 2018Hello,
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.
Richard M. Hicks
/ July 29, 2018Sorry, no idea what could be causing that issue. That’s an error message I’ve not yet encountered myself. :/
ced666
/ July 30, 2018Hello 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
Jochen
/ July 30, 2018Hi 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
Richard M. Hicks
/ July 30, 2018You 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.
Andy
/ July 31, 2018I thought NPS only applied to user certificates? NPS seemed to have no role in blocking computer certificate/device tunnel?
Richard M. Hicks
/ July 31, 2018You 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, 2018How 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?
Richard M. Hicks
/ July 31, 2018That’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.
Rob F
/ July 30, 2018I 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
Richard M. Hicks
/ July 30, 2018Not 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.
Rob F
/ July 30, 2018I 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?
Richard M. Hicks
/ July 30, 2018That’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, 2018I’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.
Richard M. Hicks
/ July 31, 2018Unusual. Does it work outside of ISE, in a regular (elevated) PowerShell command window?
conradebel
/ August 3, 2018Hi 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!
Richard M. Hicks
/ August 7, 2018That’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. 🙂
Ryan Messer
/ August 6, 2018I 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”.
Richard M. Hicks
/ August 7, 2018That’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!
Karsten Hentrup
/ June 28, 2019I used the “machine-auth”-PowerHELL really often in lots of customer Always on VPN Installation. No Problems at all. But this week: BANG, same error as Ryan describes!
Background: we had 2 identically root-ca-certificates in Computer trusted root store.
Solution was, add [0] at the end of the second line! like:
$RootCACert = (Get-ChildItem -Path cert:\LocalMachine\root | Where-Object {$_.Thumbprint -eq $Thumbprint})[0]
Richard M. Hicks
/ June 28, 2019Good catch! Thanks for the tip on the workaround too. 🙂
Ryan
/ August 6, 2018I 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.
Richard M. Hicks
/ August 7, 2018Sounds 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?
William
/ March 9, 2020Exact same issues here too Ryan, I know its been a while but did you manage to fix it?
William
/ March 11, 2020Just for anyone who finds this… turns out it was the VPN server certificate. I had selected the wrong cryptography for it and which was set to use ECDH (DH Being diffie-Hellman which has limited use?). I remade the cert with RSA keys and it worked.
Richard M. Hicks
/ March 11, 2020Good to know! 🙂
bartpasmans
/ August 14, 2018Hi 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?
Richard M. Hicks
/ August 14, 2018Common 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.
bartpasmans
/ August 15, 2018Hi Richard,
Thanks for the reply! I got all the updates and are not using the TrustedNetworkDetection. But Still it’s giving me a headache 🙁
Richard M. Hicks
/ August 15, 2018Bummer. 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, 2018Hi Richard,
I’ve opened a support case! Will inform you (hopefully) about the solution!
Richard M. Hicks
/ August 18, 2018Ok, keep me posted!
James
/ March 27, 2019Having the exact same issues as you bartpasmans, and wondering if any progress with your support case with MS, i’ve just updated to 1809 and still is the same thing, continuous ping once connected only starts replying after 5 mins, i have tried on several other machine, some have this issue some dont. I built 2 exact same laptops with the exact same build. ! had this issue the other didn’t. I have no idea where to look
Holger
/ August 14, 2018Hi 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
Richard M. Hicks
/ August 14, 2018You 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. 🙂
andychips
/ August 15, 2018I 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?
Richard M. Hicks
/ August 15, 2018Agreed. 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. 😉
Marc Bauer
/ August 16, 2018I 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?
Richard M. Hicks
/ August 18, 2018Should work as long as the client has connectivity to the internal network, either with the device tunnel or user tunnel. 🙂
Marc Bauer
/ August 24, 2018Sure – 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 🙁
Richard M. Hicks
/ August 25, 2018In 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. 🙂
Thorsten Frohberg
/ August 31, 2018Hello 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?
Richard M. Hicks
/ September 4, 2018Device 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.
Thorsten Frohberg
/ September 5, 2018Thank 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.
Richard M. Hicks
/ September 6, 2018If 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, 2018When i have a reverse proxy on internal site, then its not need the default gateway on external adapter, or?
Richard M. Hicks
/ September 7, 2018Depends 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).
Patrick
/ September 7, 2018Hello,
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
Richard M. Hicks
/ September 7, 2018I 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?
Eric Yew
/ September 13, 2018After 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, 2018would be helpful if i provided the parameters:
$namespaceName = “root\cimv2\mdm\dmmap”
$className = “MDM_VPNv2_01”
Richard M. Hicks
/ September 15, 2018Thanks Eric!
Patrick
/ September 17, 2018Hello
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
Richard M. Hicks
/ September 22, 2018Awesome. 🙂 Thanks for the tip!
Mark (@yomark1)
/ September 10, 2018Hello,
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
Richard M. Hicks
/ September 11, 2018I 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/.
Mark (@yomark1)
/ September 11, 2018Hello 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
Richard M. Hicks
/ September 12, 2018Correct. 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.
assy
/ September 12, 2018Hello, 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?
Richard M. Hicks
/ September 12, 2018If 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.
assy
/ September 13, 2018For 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
Richard M. Hicks
/ September 15, 2018For 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.
ced666
/ September 13, 2018Hi 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
Richard M. Hicks
/ September 15, 2018You could easily store the private key on the TPM. Guidance can be found here: https://directaccess.richardhicks.com/2018/02/12/directaccess-and-always-on-vpn-with-trusted-platform-module-tpm-certificates/.
ced666
/ September 17, 2018thank you Richard,
in your procedure, tell you for a tunnel user profile. Does this work for the tunnel device also for the storage of certificates on TPM chip or smart card or USB Key?
Richard M. Hicks
/ September 22, 2018Not sure about storing the private key on a USB drive, but it certainly supports storing the key on a TPM.
Simon Brunner
/ September 13, 2018Great article! Did you ever deploy an device tunnel vpn profile with sccm? Any tips or instruction? Thanks!
Richard M. Hicks
/ September 15, 2018I have not. I don’t have any experience with SCCM. However, I’ll look for some documentation and post that when I have it.
Thorsten Frohberg
/ September 19, 2018The 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.
Thorsten Frohberg
/ September 13, 2018Hello 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?
Richard M. Hicks
/ September 15, 2018I would suspect there’s an issue with your ProfileXML. That’s really the only time I’ve seen that error.
andychips
/ September 18, 2018Thorsten,
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.
Thorsten Frohberg
/ September 15, 2018Hello 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?
Richard M. Hicks
/ September 15, 2018Only 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.
Thorsten Frohberg
/ September 17, 2018I 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?
Richard M. Hicks
/ September 22, 2018Interesting. 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. 🙂
Ian Burnell
/ September 17, 2018Starting 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
Richard M. Hicks
/ September 22, 2018There 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.
Simon42
/ September 19, 2018Hello
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 ? 🙂
Richard M. Hicks
/ September 22, 2018Have 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?
Thorsten Frohberg
/ September 19, 2018Hello 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?
Richard M. Hicks
/ September 22, 2018The 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.
Ian Burnell
/ September 20, 2018Also 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?
Richard M. Hicks
/ September 22, 2018Best results I’ve had are defining the proxy in ProfileXML. Trying to do it outside of this produces mixed results.
Simon Brunner
/ September 21, 2018Hi 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?
Richard M. Hicks
/ September 22, 2018Expected 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.
Patrick
/ September 25, 2018Hi 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
Richard M. Hicks
/ September 27, 2018If 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. 🙂
Patrick
/ October 2, 2018Hello,
as I told you, using the mydomain.com element, the tunnel is always mounted even when I’m on the internal network.
Richard M. Hicks
/ October 4, 2018As 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?
ced666
/ October 9, 2018Hello 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
Richard M. Hicks
/ October 13, 2018I’m not sure about LockDown mode and TrustedNetworkDetection. I’ve done no testing at all with LockDown mode to this point.
Ian Burnell
/ October 13, 2018Hi 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
Richard M. Hicks
/ October 20, 2018Shouldn’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.
Nikodemus
/ October 18, 2018Hi,
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!
Richard M. Hicks
/ October 20, 2018You’ll need to define the RegisterDNS element in your ProfileXML to force client registration in DNS.
Nikodemus
/ October 26, 2018Thanks! 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..
Richard M. Hicks
/ October 29, 2018I’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, 2018My 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.
Richard M. Hicks
/ October 29, 2018Yes, 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, 2018As 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.
Richard M. Hicks
/ October 29, 2018I can tell you they are being worked on. Let me now how you get on. 🙂
Nikodemus
/ November 5, 2018Sorry 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??
Matt
/ October 22, 2018I 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.
Richard M. Hicks
/ October 23, 2018Users 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.
Matt
/ October 23, 2018So, 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.
Richard M. Hicks
/ October 29, 2018The 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. 🙂
Simon Brunner
/ October 23, 2018Hi,
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
Richard M. Hicks
/ October 23, 2018Hard 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.
Simon Brunner
/ October 24, 2018Is 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.
Richard M. Hicks
/ October 29, 2018It should work with any domain, public or private.
Steve
/ November 13, 2018Great 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!!!
Steve
/ November 13, 2018finally 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'”
Steve
/ November 15, 2018The 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
Richard M. Hicks
/ November 17, 2018Not 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, 2018SCCM 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.
Some Guy
/ November 13, 2018So 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?
Richard M. Hicks
/ November 17, 2018It 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. 🙂
Some Guy
/ November 19, 2018Yeah 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. !!!
Richard M. Hicks
/ November 20, 2018A 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, 2018Isn’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, 2018Well, 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.
Richard M. Hicks
/ November 23, 2018Agreed. 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, 2018I’m surprised that Microsoft is OK with this. Perhaps it will be enhanced in the future to allow for additional authentication/restrictions.
Richard M. Hicks
/ November 23, 2018I’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, 2018Doesn’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.
Richard M. Hicks
/ November 29, 2018Indeed 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.
Jonas
/ November 21, 2018I 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?
Richard M. Hicks
/ November 21, 2018Perhaps 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. 🙂
Steve
/ November 22, 2018Hi Jonas, Is the script run from an elevated command prompt, using psexec to launch powershell as system account?
Pat666
/ December 6, 2018Hi 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
Richard M. Hicks
/ December 8, 2018When 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.
HayDog Tech
/ December 21, 2018Thanks for your article here. I have added the device tunnel and it correctly only shows when I run Get-VPNConnection -AllUserConnection.
The XML has true in it. However, the device never automatically connects the tunnel. There are no events from RASClient in the Application log. This is despite restarting.
If I launch a command line under the SYSTEM context and run rasdial I can successfully connect the device tunnel. This stays connected when using Switch User in Windows and shows in RRAS as the computer name and not a user so I am confident this is a device tunnel.
As a workaround I have had to create a scheduled task that runs rasdial every two minutes when a network connection is active.
Have you ever seen this behaviour?
HayDog Tech
/ December 21, 2018That should say that the XML has AlwaysOn true in it. I can’t put the full syntax as it is blocked by the comment parser.
Richard M. Hicks
/ December 21, 2018Odd. Do you have TrustedNetworkDetection defined? That’s the only time I’ve seen an Always On VPN connection not establish automatically, assuming AlwaysOn is set to True. If TrustedNetworkDetection isn’t configured correctly it can cause this issue.
HayDog Tech
/ January 4, 2019Thanks for the reply, TrustedNetworkDetection is not defined. After some other tests I am doing I may try defining that to see if it kicks it in to gear as this would certainly be needed for the production setup. Also am waiting for another device to be tested with from another location just in case it’s something specific about my lab.
Ortaç
/ January 26, 2019hi,
we have problem about auto-trigger functions. User can connect manually always on vpn but after restart client, client can not connect automatically.
Local domain: test.com
Vpn server: vpn.abc.com (for remotely access)
TrustedNetwork: test.com
DNS suffix search list: test.com
Richard M. Hicks
/ January 26, 2019Could be caused by any number of things. I would try removing the TrustedNetworkDetection element and testing again. There have been reported cases where this isn’t working as expected.
Ortaç Demirel
/ January 29, 2019No change. I think DA work more stable.
Richard M. Hicks
/ January 29, 2019I think many would agree with you. 😉
Colin
/ January 29, 2019My experience with the device tunnels on 1809 with 2019 server is that they are flaky.
On a clean boot they will connect 99% of the time but many times after the initial connection they will just disconnect and never connect again until they reboot or the sometimes when the network is disconnected/reconnected.
I personally have not had any trouble with TrustedNetworkDetection though.
I don’t know of any way to improve the stability of the device tunnel outside of waiting for MS to do it.
All that said, I am looking at device tunnels right now that have been connected for a solid month… 700+ hours.. 300+ hours etc..
This is likely due to us setting the network adapters to not use power saving so the connections don’t die due to Windows power management. I set this on wired and wireless adapters.
Microsoft still has a lot of work to do with AOVPN. Bet hey, it is free if you own the licensing for the clients and servers. The alternatives are the much slower and less flexible MS Direct Access or the crazy expensive Netmotion Mobility option. Choose your poison 🙂
Richard M. Hicks
/ January 31, 2019Excellent summary. Indeed, Microsoft does have some work to do with stabilizing Always On VPN, especially device tunnel/user tunnel coexistence. No doubt NetMotion and other third-party mobility solutions have additional costs associated with them, but if you want free I guess you get what you pay for. 😉 Also, I would argue that “free” in this case really isn’t free when you factor in the administrative overhead and lost productivity for users. :/
Colin
/ February 1, 2019I agree with you. It isn’t always an easy translation when getting budget items approved.I think Netmotion has an awesome product but I take issue with the pricing. They appear to be the only game in town and that is likely what allows them to proceed how they are. If another company decides to develop a competing product I would expect to see the price go down. I understand you have a relationship with them so I don’t want this to come across in a negative way, I just experienced a little bit of sticker shock.
Richard M. Hicks
/ February 1, 2019No question they have a unique feature set that is without equal. As far as the cost is concerned, maybe you should have reached out to me. I’m sure I could have gotten you a better deal, especially if you purchased the licenses through me. 🙂 Let me know if you’re still interested. Would love to see if I could do better for you. 🙂
Also, you’re observations aren’t negative in any way at all, really. I work with a lot of different vendors not just NetMotion, and they all have their own associated costs. Many of them end up being even higher than Mobility when you include the appliance(s) (physical or virtual), maintenance and support, and user/device licenses. 🙂
Ortaç Demirel
/ February 2, 2019I recieve some informations from event records:
Autotrigger: auto trigger Config registry content completed with Error = 2
Autotrigger: auto trigger module initialization completed with Error = 13
Autotrigger: [AlwaysOn VPN], profile got deactivated
Richard M. Hicks
/ February 9, 2019I know that Microsoft has been struggling to ensure stability/reliability for device tunnel/user tunnel coexistence. I would expect this is related. I can only suggest that you give Microsoft support a call and have them troubleshoot. If it is a bug it won’t cost you anything.
Matt
/ March 3, 2019Is device tunnel required for pre-login authentication?
For instance if a user was sent a replacement laptop without cached credentials or if the user forgot their password and the helpdesk reset it for them.
If there is a way to manually launch a user tunnel from the login screen, then we could live without the device tunnel and not have any IKEv2 requirements.
Richard M. Hicks
/ March 3, 2019Correct. The device tunnel provides domain connectivity that allows a user to log in without cached credentials. Also, with a domain controller accessible pre-logon, password sync issues aren’t a problem.
Some Guy
/ March 3, 2019IIRC, from at least NT4 to Windows 7, if you created a dial-up connection, which includes VPN connections, as an “all users” connection (i.e., owned by SYSTEM account) then the Windows login screen would give the user a checkbox to “login over a dial-up connection.” Basically it would dial a RAS connection prior to logging into the domain/machine and it would use the typed credentials for both. I wonder if that functionality is still lurking around possibly accessible through APIs or registry magic.
Richard M. Hicks
/ March 3, 2019I remember doing that myself many years ago. Haven’t tried it in ages though.
Pascal
/ January 29, 2019Hello Richard
My VPN works like charm while using non elliptic curve DHGroup/PFSGroup (Server 2016, Win10 1803). But when I try to switch to ECP256 or ECP384, the connection fails.
I analyzed it on the network layer and captured the packets using wireshark. There I can see that the IKE SA Initiation and IKE Authentication work and the client sends its next packet encrypted “Client Hello” using TLS 1.2. The Server responds with an ACK and a Reset. The client then tries to send the “Server Hello” again and again using TLS1.1, TLS 1.0 and SSLv3 with the same result (server sends ACK, RST).
Any idea what the cause could be?
Thank you in advance and best regards
Pascal
Richard M. Hicks
/ January 29, 2019Do you have a certificate installed that uses ECDSA keys?
Matt
/ February 1, 2019We mostly need AOVPN so laptops keep reporting in to our centrally-managed antivirus, WSUS and SCCM and so that uses can always sign in with an active connection to a domain controller to change their password instead of using cached credentials. We would also like manage-out functionality push software and configuration updates and provide remote assistance whenever the user turns on the laptop to surf the web and check email instead of waiting for users to only occasionally connect to our VPN to get to internal resources.
If users need to access our intranet, file shares or other internal resources, we would then have them sign into Cisco AnyConnect VPN after they’re signed into Windows.
Since AOVPN seems unstable when device and user profiles need to work together, I may want to instead try rolling it out with only device tunnels configured.
Will this work and be more stable than trying to get AOVPN to reliably work with user and device tunnels?
Richard M. Hicks
/ February 1, 2019In my experience, using a single tunnel (device or user tunnel) seems to be fairly stable. I’ve never tried mixing Microsoft and third-party VPN connections though, so you’ll have to test it out and see how it works. 🙂
Rkast
/ February 4, 2019Hi Richard,
Great content which we used setting up AOvpn. Unfortunately we hit a performance problem. When vpn is connected with force tunneling we only get 10mbps where remote wifi is a 1gbit connection. Rras server has only 20 connections, CPU is 10% and ram is 5%. WAN nic of rras show spikes 50mbps during a day. So nothing really special of some doet. Any guidance?
Richard M. Hicks
/ February 9, 2019Is this for the device tunnel or user tunnel? If it is for the user tunnel, which VPN protocol are you using?
Rkast
/ February 11, 2019This is for user tunnel. We use default TechNet setup so its Ikev2. When not using force tunnel internet speed is fast, but if we use force tunnel and traffic passes throug our internal proxy internet is slow. Internal clients go throug same proxy and they are fast. Any guidance?
Richard M. Hicks
/ February 11, 2019Not sure what’s up. I’d suggest conducting some tests using iPerf to see where the slowdown is. You can compare throughput for clients connecting to on-premises resources vs. the Internet. It could be caused by a routing issue or perhaps something else. You can also try using SSTP as it offers better performance than IKEv2.
Ian Little
/ February 11, 2019Hi, I cannot get my profile to pick up the settings from the XML file. I have followed the guide to the letter? Is there something obvious missing?
Richard M. Hicks
/ February 11, 2019If the settings from your XML file aren’t applying to the connection then you’ve got a syntax error somewhere. Open your ProfileXML in an XML editor (I use Visual Studio Code – https://directaccess.richardhicks.com/2019/01/24/always-on-vpn-profilexml-editing-and-formatting-with-visual-studio-code/) or use something like freeformatter.com to validate your XML. You should be able to find the issue using one of those tools. 🙂
IanL
/ February 12, 2019Thanks Richard, that did the trick.
Dan
/ February 13, 2019I’m stuck on this portion – of client configuration
Unable to create Always On VPN – Device profile: A general error occurred that is not covered by a more specific error code. Powershell is running under local system context too. Powershell for client config is so… scalable! smh! Anyhow, anyone have any ideas ?
Richard M. Hicks
/ February 13, 2019Agreed, using PowerShell to configure Windows 10 Always On VPN connections (device tunnel or user tunnel) isn’t entirely scalable. 😉 Typically I use PowerShell deployment only for testing. Once I’ve validated my ProfileXML I’ll use Intune or SCCM to deploy them.
With regard to your error though, it is most likely caused by a syntax error. Details here – https://directaccess.richardhicks.com/2019/01/21/always-on-vpn-unable-to-create-profile-general-error/.
Dan
/ February 15, 2019Thanks Richard! i’ll dig into this further. So far this technology is overly complex for my needs. Can’t believe MS makes the client side configuration this complex! GPO support is really needed!
Richard M. Hicks
/ February 15, 2019Yes, indeed. GPO support would be nice. Microsoft has no plans to support that though, unfortunately. However, it’s possible we’ll see something in the future from a third party. Stay tuned… 🙂
Dennis
/ February 14, 2019Hi, trying to setup the device tunnel here also but when testing the connection we get error 13801 of RasClient: IKE authentication credentials are unacceptable. https://blogs.technet.microsoft.com/rrasblog/2009/08/12/troubleshooting-common-vpn-related-errors/
There seem to be 4 possible causes but they look ok in our environment. Any idea?
Richard M. Hicks
/ February 15, 2019For the device tunnel, the RRAS server simply checks that the client has a certificate from a CA the server trusts with the Client Authentication EKU in its local computer certificate store. If you are receiving an “IKE authentication credentials unacceptable” message, I would have to assume either the client machine doesn’t have a certificate that meets those requirements, or the server lacks the proper certificate for the CA you are using. Have a look at those closely. 🙂
IanL
/ February 20, 2019I am trying to deploy the user tunnel profile with the setting to autodetect the proxy settings, does anyone know the correct syntax?
Richard M. Hicks
/ February 23, 2019There is no option to configure the client to automatically detect. The closest available option would be to define an automatic proxy configuration URL using the /Proxy/AutoConfigUrl element.
IanL
/ February 21, 2019Does anyone know a way of deploying the user VPN profile and including the option of Autodetect for the proxy server? I cannot seem to find the required syntax anywhere
Richard M. Hicks
/ February 23, 2019There is no option to configure the client to automatically detect. The closest available option would be to define an automatic proxy configuration URL using the /Proxy/AutoConfigUrl element.
Andrew
/ March 24, 2020Hi Richard,
What does that look like in the XML file? We’re trying to setup AOVPN Device tunnel with split tunneling and want web traffic to go through our websense WCCP proxy. Of course, I can set the autoconfigurl via GPO but would like to set it via the AOVPN profile xml file.
Richard M. Hicks
/ March 24, 2020Have a look at this VPNv2 CSP Native Profile example. It’s toward the bottom of the sample file.
Pascal
/ February 28, 2019Hi Richard
For the device tunnel to work properly so users can login/reach their homedrive an to be restrictive I have configured some /32 “Routes” and “TrafficFilters” for the Domain Controllers and Fileservers in the device tunnel VPN profile along with the internal DNS server as “DnsServers” (because only they can resolve the Domain Controller/Fileserver names). But as far as I tested I needed to add the DNS servers to the “Routes” and “TrafficFilters” in the profile too for DNS resolving to work properly. Then I had the problem that once the device tunnel is connected, the client tried to resolve the external address of the VPN server using the internal DNS servers and this failed resulting in the user tunnel not coming up. When I create the DNS record on the internal DNS servers, the usertunnel comes up properly. That would mean that any client on the internal network could resolve the VPN and therefore connect to it if I don’t block the requests on the firewall (because I do not have TrustedNetworkDetection enabled and the client would always try to connect to the VPN server). Do you have any idea on how to improve the profile/settings? Any help is appreciated.
Richard M. Hicks
/ March 3, 2019Using split DNS poses some unique challenges when using Always On VPN with both device tunnel and user tunnel. You could try adding an NRPT exclusion for your public hostname, but I’ve had mixed results with that configuration. Sometimes it works, others it doesn’t. :/ Another option is to have the public hostname resolve to the public IPv4 address in your internal DNS, but if you aren’t using TrustedNetworkDetection your clients will connect to the VPN internally if you don’t block it at the firewall. If you can use another namespace for your public hostname that would be ideal. 🙂
Ian Burnell
/ March 2, 2019I’d like to get a heads up if Microsoft plan to allow “Automatic” connection in Device Tunnel XML. Without this it can only use IKEV2 which means for my company they will go for Cisco because they want to be able to connect via SSTP/ Wi-fi. Anything coming in W10 1903 maybe???
Richard M. Hicks
/ March 3, 2019The Always On VPN device tunnel being restricted only to IKEv2 is definitely a serious limitation and often a barrier to adoption. I’m certain Microsoft could make the device tunnel work using SSTP, it’s just a matter of desire on their part. I am unaware of any effort to implement SSTP support for the device tunnel by Microsoft, so I can’t say if this feature will be added to the next release of Windows 10.
tomaz17
/ March 4, 2019Hi Richard
First of all i want to thank you for great articles on Direct Access and AlwaysOn VPN !
I would like to ask you for help configuring AlwaysOn VPN Device force tunnel. At the moment
my VPN server has 2 NICs – int and ext. INT NIC has default gateway configured.
I have done AlwaysOn VPN Device split tunnel configuration – everything works fine. What steps
should i take to implement AlwaysOn VPN Device force(full) tunnel? Should i change something in xml file
when deploying DeviceTunnel force adapter? For deploying i am using powershell.
Thank You for help in advance!
Richard M. Hicks
/ March 7, 2019Yes, you will enable force tunneling by defining it in the RoutingPolicyType element. You’ll need to remove the DefaultClassBasedRoute element and any Route elements as well.
tomaz17
/ March 5, 2019Hello
We are trying to achieve following:
1. When outside corporate network VPN connection automatically connects
2. All traffic is routed via corporate network – force tunneling
3. User cannot disconnect or delete VPN tunnel adapter
Can You please suggest which option i need to choose:
1. AlwaysOn VPN user force tunnel with Lockdown
2. AlwaysOn VPN device force tunnel
I have googled and failed to find how to configure user lockdown mode or device force tunneling.
Thank You for help in advance
Richard M. Hicks
/ March 7, 2019If you don’t want the user to be able to disconnect the session, then enabling LockDown mode is your option. Be advised that with LockDown mode the client will have NO Internet access if the VPN is unavailable.
Nemanja
/ March 14, 2019Hello,
Great aritcle, I learn a lot from it. I’ve configured Alwasy ON VPN in my compani for test. I won’t to use it instad of Direct Access. I configure device tunnel with force tunnel option.
Everithing is working fine(email with outlook client, owa webmail, intranet, skype for business, rdp to computers, dns resolution), exept Internet web browsing. I’m using in my compatny proxy for internet browsing, so it is already set in IE and Chorme by GPO. I’m able to telnet from VPN Win 10 client to proxy by proxy port, to ping proxy, to resolwe ip address from proxy name, but trafic is not going.
Do You know what do I miss, and is it possible to acomplish that work?
Thank You in advanced.
Richard M. Hicks
/ March 15, 2019Not sure, really. You’ll probably have to take a network trace on the client to see what the behavior is.
Nemanja
/ March 18, 2019I fine solutions. Add this lines to xml file:
mwgproxy:9090
After that I’m able to user proxy for win10 clients. I’m not sure why is this working that way, because when I created manually VPN connection for Always ON on client, proxy works fine by default (using IE settings), also in Direct Access work fine without any additional settings.
Richard M. Hicks
/ March 19, 2019That’s great. If you’re using IE/Edge I think this should work. However, I don’t think this works for non-Microsoft browsers. You might want to test with Chrome or Firefox if you use them.
Nemanja
/ March 25, 2019When I configure proxy in xml it works fine with both, IE and Chrome. Only difference is that when I use force device tunnel, web browsers are not able to use proxy settings from their connection options, but only settings that is configured in xml.
Internet browsing now work fine.
Now I have problem to accomplished that my Cisco Anyconnect work correctly. We need to use it for admin access form outside. I configure everything to enable Anyconnect connection, but after establishing connection, after 20-30sec Anyconnect start to reconnecting and stay in that state indefinitely and I lose all my connectivity.
Do You know is this scenario supported by AlwaysON Vpn?
Kind Regards,
Richard M. Hicks
/ March 25, 2019I probably wouldn’t recommend using more than one VPN connection at a time, mostly because it can cause strange behavior like this. If you need to use Cisco AnyConnect for remote administrator, I’d suggest first disabling the Microsoft VPN connections and see if that works. It may simply be that Always On VPN and AnyConnect can’t coexist.
Ian
/ March 17, 2019@Nemanja. It doesn’t use the IE Proxy settings it is under dial up connection. I had the same problem and added these lines to my xml
http://yourentry/proxy.pac
Nemanja
/ March 18, 2019@Ian, thank You for reply. I find solutions with line that sets: proxy, manula and adding webproxy:9090 servername in xml file.
Mark Klerkx
/ March 21, 2019Hello Richard, I can have a device or a user tunnel seperately, but as soon as I have both connected (as that normal behaviour??) I have no network connection anymore. When I ping a node in my network. I recieve a “general failure”. I think this is because there are 2 “gateways” from the same network.
Did I configure something wrong here?
Richard M. Hicks
/ March 21, 2019I would assume so. 🙂 Have a close look at your routing configuration in both of your ProfileXMLs. It is recommended that you disable class-based default routing and define your own routes. Typically the device tunnel would be configured with host routes to specific domain controllers or other management servers, but that’s not strictly required. You should be able to create overlapping routes without issue, as the route metric will decided which interface the traffic ultimately uses.
ced666
/ April 10, 2019Hello Richard,
I saw in the official Microsoft document (https://docs.microsoft.com/en-us/windows/client-management/mdm/vpnv2-csp) that you could establish a VPN connection from the public IP address of the gateway or multiple VPN gateways. I am very surprised because I tried to declare multiple VPN gateways with their DNS name, and it does not work, so support for multiple VPN gateways in the Always On client in tunnel device mode is not supported. charge. Same observation, it does not work with the IP address of the gateway. Why does Microsoft mention that it is possible?
I thank you in advance for your precious help.
Patrick
Richard M. Hicks
/ April 10, 2019Technically speaking you can provide more than one VPN server FQDN in your ProfileXML. However, I don’t believe the client will failover if the primary (first) entry is unavailable. It’s not something I’ve tested though so I can’t be certain. I’ll do some testing soon to find out though.
ced666
/ April 10, 2019Hello Richard,
I will also do tests on my side and I will keep you informed. I can confirm you already that the declaration of the IP instead of the name of the DNS, does not work in tunnel device mode, which seems to me a little logical because the VPN gateway uses a certificate with the DNS name for authenticate.
Thank you.
Richard M. Hicks
/ April 11, 2019Indeed, using hostnames would be preferred because they need to match the subject name of the certificate on the server, both for IKEv2 and SSTP connections. 🙂
Vadim
/ April 11, 2019Hi Richard,
thank you for the helpful post.
We’ve configured User Tunnel for force tunneling in Always On mode (true) and we want to allow our users to manually disconnect the user tunnel.
If I disconnect the user tunnel, the user tunnel connects automatically again.
So I try this command:
rasdial.exe “AlwaysON VPN User Tunnel” /DISCONNECT
The result: the user tunnel is disconnected and dosn’t connect automatically. After client reboot still the same problem, that doesn’t connect automatically.
Have you any idea?
BR
Vadim
Richard M. Hicks
/ April 11, 2019No idea. Typically either the connection is set to automatic (always on) or it isn’t. I’ve not come across a scenario where the user needed to disconnect, but have it still remain always on.
Vadim
/ April 12, 2019Hi Richard,
i’ve another question.
Is it possible to exclude network(or ip range) from forced tunnel?
For example MS Teams or Skype Online address ranges, that I don’t won’t to route over my company because of latency (voip traffic).
Thank you.
BR
Vadim
Richard M. Hicks
/ April 12, 2019Not natively, no. I do know that Microsoft Consulting Services (MCS) has something they call “managed tunnel” that provides this though. You’ll have to reach out to them for more details.
ced666
/ May 9, 2019Hi Richard,
is it possible to use the EAP protocol in tunnel device mode and using the machine certificate?
Thanks a lot for your help.
Patrick
Richard M. Hicks
/ May 9, 2019Possibly, but not sure. It’s not something I’ve ever tried myself.
Patrick
/ May 10, 2019Hi Richard,
EAP authentication can only work with a user certificate, not the machine certificate. When the EAP authentication method is used, only the user’s store is read by the protocol,. In tunnel device mode only the authentication method by the machine certificate is possible.
Source:
VPNv2 / ProfileName / NativeProfile / Authentication / MachineMethod
This is only supported in IKEv2.
This value can be one of the following:
Certificate
https://docs.microsoft.com/en-us/windows/client-management/mdm/vpnv2-csp
Richard M. Hicks
/ May 10, 2019That’s quite interesting because I know I’ve used PEAP with machine certificates for authentication using another vendor’s solution in the past! I’ll have to do some more testing with this and see what I can find out.
Patrick
/ May 11, 2019Hello,
Thank you very much for your feedback and your precision about the EAP protocol (I omitted to specify the framework for using the EAP protocol for AO-VPN in my previous message). I confirm that the EAP / PEAP protocol can quite work in other situation as for example in the case of network 802.1X or company Wifi. The option in question in the EAP / PEAP option “use a certificate on this computer”.
Indeed, for AO-VPN tunnel device, only the machine certificate authentication method is allowed. I find it unfortunate that it can not be used in tunnel device mode because there are interesting directives that can be used, such as “RootCATrustedCertificates” to filter only on the certificate of the expected certification authority (fingerprint ) by the VPN Client Always ON.
In addition AO-VPN tunnel user mode works very well in EAP / PEAP.
I hope this support will be possible in future versions of Windows 10 to enhance the security of the Always On device tunnel VPN client.
Richard M. Hicks
/ May 12, 2019I agree, it would be nice if the device tunnel supported PEAP as it is much more secure than just checking the computer certificate. I don’t expect Microsoft to address this however, mostly because the device tunnel is viewed as a temporary workaround for DirectAccess to Always On VPN migrations. Ideally Microsoft wants customers to move to Azure Active Directory and Intune management which would eliminate the need for the device tunnel.
Some Guy
/ May 12, 2019I remember when software companies used to develop their software so that it would provide solutions customers wanted. Now it seems customers have to design their solutions around the wants of the software companies. I must be getting old, yikes.
Richard M. Hicks
/ May 14, 2019I agree completely. 🙂
Some Guy
/ May 10, 2019@Patrick, that is not correct; EAP can mostly definitely be done using certificates from the computer account’s certificate store. People do this all the time with EAP for WPA2 Wi-Fi or for wired 802.1X. There is a checkbox in the EAP settings for “use computer credentials” or something like that.
The problem here not that EAP cannot use computer account’s certificates (it can); the problem is that the device tunnel mode of the AO-VPN client cannot use EAP. IKEv2’s “machine certificate” method of authentication is the only method supported by device tunnel mode, and this method is basically just plain ol’ X.509 certificate exchange, not EAP.
Richard M. Hicks
/ May 10, 2019Agreed. The use of EAP/PEAP is not supported using machine certificates specifically in the context of the Always On VPN device tunnel. It does certainly work in other scenarios as you mentioned.
Lisa
/ May 13, 2019Hello,
When I ran my script as an NT authority\system it gave me error:
Unable to create Device tunnel profile: A general error occurred that is not covered by a more specific error code
Have you any idea?
Thank you
lisa
Richard M. Hicks
/ May 14, 2019Most certainly an error in your ProfileXML. Details here: https://directaccess.richardhicks.com/2019/01/21/always-on-vpn-unable-to-create-profile-general-error/.
Peter Klaffehn
/ May 15, 2019Hi,
i have configured a device tunnel. For testing purposes i issued a certificate with a very short lifetime (4h) because i wanted to see what happens if the certificate expires while the tunnel is connected. When the certificate expires the tunnel disconnects. The certificate is not renewed white the vpn tunnel is connected. Can this be done somehow?
Regards, Peter
Richard M. Hicks
/ May 15, 2019If you are using certificate autoenrollment and with certificates that have a normal lifetime (several months to a year, commonly) then you won’t have any problems like this. When you enable certificate autoenrollment make sure you select the option to “Renew expired certificates, update pending certificates, and remove revoked certificates” and “Update certificates that use certificate templates”. With this configuration the client machine will automatically renew its certificate over the device tunnel prior to the certificate expiring. Details here: https://directaccess.richardhicks.com/2013/08/08/directaccess-computer-certificate-auto-enrollment/.
Patrick
/ May 23, 2019Hi Richard,
in IKEV2; do you enter whether the Always ON VPN client renegotiates session keys in re-key or reauth?
thank you so much
Patrick
Richard M. Hicks
/ May 23, 2019Yes. I do this using the Set-VpnServerConfiguration PowerShell command. Example here: https://github.com/richardhicks/aovpn/blob/master/Set-IKEv2VpnSecurityBaseline.ps1.
ced666
/ May 24, 2019thank you very much
my question, can the setting can be fixed on the VPN Always On client and not on the VPN gateway. I ask this question because on other VPN client, it is possible to implement different modes rekey or rehaut regardless of the configuration of the gateway VPN.
thank you very much
Richard M. Hicks
/ May 25, 2019Not to my knowledge. I believe this setting is enforced only on the server side.
ced666
/ June 20, 2019Hi Richard, just to let you know that the tunnel device on Windows 10 1903 works very well.
I can tell you that a bug has been fixed on the ConnecteionStatus.
When the tunnel is mounted, and you enter the get-vpnconnection -alluserConnection command, the ConnectionStatus status is connected 🙂
Patrick
Richard M. Hicks
/ June 20, 2019Yes, I saw that too. Most helpful! 🙂
ced666
/ June 21, 2019Hello Richard
I tested Always On VPN tunnel device on Windows 10 1903, the tunnel is well mounted but after a few hours, the tunnel is disconnected, then after some time, reconnected and disconnected. I underline a big problem of stability of the VPN tunnel contrary to the previous versions (1803, 1809). Have you had any information to this problem?
Thank you very much
Patrick
Richard M. Hicks
/ June 22, 2019I’m not seeing any issues myself with Always On VPN and Windows 10 1903 thus far.
ced666
/ June 23, 2019Hello Richard
I am very surprised that you have no concern for stability with the AOVPN Windows 10 1903
And yet other users seem to encounter the same problem AOVPN since the passage version Windows 10 1903, as you can see on the social technet (https://social.technet.microsoft.com/Forums/windowsserver/en-US/eab5aaa9-2d6a-4e87-8023-f0ab37f1fa83/alwayson-vpn-in-windows-10-1903-doesnt-connect?forum=winserverNIS). I do not think I’m the only one in this case. I confirm that AOVPN on Windows 10 1903 presents problems of stabilities. I confirm you that the AOVPN test were performed under the same conditions as the version of Windows 10 1803.
Patrick
Richard M. Hicks
/ June 24, 2019It’s not that I “have no concern” for issues with 1903, it’s just that I have not experienced any of these issues myself. As I’ve stated before, my testing with 1903 has been flawless so far. I’ll continue testing of course and will report any troubles I might have. I’ve also forwarded those forum links to my contacts at Microsoft so they can have a closer look.
Richard M. Hicks
/ June 24, 2019Following up on this. I’ve seen some reports of folks stating that Windows 10 1903 fails to establish Always On VPN connections after an upgrade from a previous version. For the record, I just completed two upgrades to 1903 from 1809 and still have no issues. Always On VPN connects without issue, both device tunnel and user tunnel. Tested on both a domain-joined client and non-domain joined machine (provisioned using Intune). I spoke with some folks at Microsoft regarding this issue and they have only seen one or two instances of Always On VPN not working on 1903. They are investigating. If anyone is having an issue with 1903 after upgrading from 1809 or earlier, reach out to me directly and I’ll assist. Thanks!
Colin
/ June 24, 2019Richard,
I have the problem for sure. Everything was fine on 1809. All 1709 and 1809 clients continue to work without issue.
I upgraded to 1903 and both tunnels stopped working entirely. I came across a couple of technet forum posts with similar complaints and a blog post about it suggesting using rasphone (that didn’t work for me).
I can’t bring the org to 1903 with this problem out there.
Richard M. Hicks
/ June 24, 2019If you look in the Application event logs on your clients that are failing is there any indication why? Do you see any errors that might indicate what the cause of the failure might be? Specifically I’d be interested in seeing any errors reported from the RasClient source.
Colin
/ June 24, 2019I have not looked yet but I will and report back.
The other posts I saw mentioned the cause being 1903 removing saved credentials or something but I don’t know what they were referring to.
Richard M. Hicks
/ June 24, 2019Thanks. 🙂
Jason Jones
/ June 25, 2019Can you guys check your application event logs to see if you are experiencing a RasMan crash in 1903? If so, can you also provide what value you have configured for HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DataCollection\AllowTelemetry on those 1903 machines?
Colin
/ June 25, 2019Mine is set to 0
Richard M. Hicks
/ June 25, 2019Can you try removing the key altogether and testing again please?
Colin
/ June 25, 2019No change. I see the same sort of messages for both the device tunnel and user tunnel with rasman appearing to crash with each.
Richard M. Hicks
/ June 25, 2019Interesting. I’m able to reproduce the issue by setting the following registry key: HKLM\SOFTWARE\Policies\Microsoft\Windows\DataCollection\AllowTelemetry = 0. If I remove the AllowTelemetry value entirely it starts working again. Did you try remove the value completely or just setting it to something other than 0?
Colin
/ June 25, 2019I deleted the entire key.
Also rebooted after.
I’m surprised to hear the telemetry setting impacts rasman.
It made no impact on my end 🙁
Richard M. Hicks
/ June 26, 2019That’s unusual. Can I reach out directly to collect some additional information from you?
Colin
/ June 26, 2019Sure. My availability is going to be spotty for a while over the next couple of weeks but I will do my best to respond.
Richard M. Hicks
/ June 26, 2019No worries…we’ll take what we can get. 🙂 Thanks!
Colin
/ June 25, 2019Here is what I see (this is the user tunnel, not sure what is happening with the device tunnel):
1) Rasclient Event ID 20221… it starts dialing the connection.
2) Rasclient Event ID 20222… the user is trying to establish a connection
3) Application Error: rasman
Faulting application name: svchost.exe_RasMan, version: 10.0.18362.1, time stamp: 0x32d6c210
Faulting module name: rasmans.dll, version: 10.0.18362.86, time stamp: 0x1cc7f460
Exception code: 0xc0000005
Fault offset: 0x000000000009d4f5
Faulting process id: 0x3898
Faulting application start time: 0x01d52b415ae8d6d0
Faulting application path: C:\WINDOWS\System32\svchost.exe
Faulting module path: c:\windows\system32\rasmans.dll
Report Id: c3b961f5-8ccb-4d24-bba0-895d88e6a215
Faulting package full name:
Faulting package-relative application ID:
At this point the VPN option vanishes from the Wi-Fi/Network icon in the systemtray.
4) Rasclient Event ID 20223…the user has successfully established a link (this is not true)
5) Rasclient Event ID 20224..the link to the server has been established for user (also not true).
Removing and readding the profiles does not help and it does not bring back the VPN to the wifi/network icon in system tray.
Colin Pazdzior
/ June 24, 2019(I’m not the Colin that just replied a few posts ago).
I’m also experiencing this issue. Upgraded my 1809 laptop to 1903 to test – on logon, both device and user tunnels connected normally, once….they subsequently disconnected after about 30s, and failed to connect after this. No logs collected, I did not have time – just rolled back to 1809 for now. Also a showstopper for us upgrading the rest of our users.
Richard M. Hicks
/ June 25, 2019Thanks Colin. Can you have a look in the application event log for any RasMan errors please? Also, let us know what the value of the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DataCollection\AllowTelemetry registry key is on your 1903 devices that are experiencing this issue. Thanks!
Patrick
/ June 25, 2019Hi Richard,
thank you very much for your reply.
I take a solution for the posts that are migrated from 1809 to 1903 and which has the AOVPN connection problem.
For my part, in the event viewer / application, I only have the event 20226 (The user code dialed a connection named vpndevice which has termed the reason code returned on termination is 829) without more details of the reason why the tunnel has disconnected.
Patrick
Rune Flo
/ July 15, 2019New and overlapping PKI.
“Set-VpnAuthProtocol -RootCertificateNameToAccept $cert1” does not accept array [actually two] of certificates.
The documentation (https://docs.microsoft.com/en-us/powershell/module/remoteaccess/set-vpnauthprotocol?view=win10-ps) states:
-RootCertificateNameToAccept
Specifies the root certificates that are allowed. Applicable only if the UserAuthProtocolAccepted parameter contains certificates.
The error on the RRAS server (WS 2019):
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.X509Certi
ficate2”.
At line:1 char:50
+ Set-VpnAuthProtocol -RootCertificateNameToAccept $cert1
+ ~~~~~~
+ CategoryInfo : InvalidData: (:) [Set-VpnAuthProtocol], ParameterBindingArgumentTransformationException
+ FullyQualifiedErrorId : ParameterArgumentTransformationError,Set-VpnAuthProtocol
Have anyone succeeded to get more than one root certificate for the -RootCertificateNameToAccept parameter?
Richard M. Hicks
/ July 15, 2019As far as I know you can only specify a single root CA using this command. :/
Donny B.
/ August 23, 2019I had previously tried to get Direct Access working for our mobile devices at the office but our upstream provider would not allow a second “VPN” kind of connection and was messing with the SSL certificate via their F5 (yes, state government at its finest) as we already have Checkpoint in place. So if I am able to leverage the Checkpoint VPN instead of having to use the RRAS I should be golden. Searching I have not found a good tutorial of how to accomplish this with a Checkpoint device. Could you point me in the right direction?
Richard M. Hicks
/ August 24, 2019Sorry, I don’t have any published guidance for configuring Check Point or any other third-party firewall/VPN appliance for Always On VPN at this time. It’s on my list of things to document and publish though. Hopefully I’ll have something for you in the near future. 🙂
David Trotter
/ September 13, 2019Hi Richard, hope you are well.
Apologies, I think I have posted this question on a different article.
Thank you for the great information you provide on your blog.
I have a deployed AOVPN solution running for a customer for several months now with no issues. I have three Windows 2016 RRAS servers and one Windows 2016 NPS server all domain joined. One thing I have noticed is that the Device Tunnel VPN connections across my three RRAS servers don’t ever seem to timeout. Obviously, with the user VPN connections these are conditioned by the settings on the NPS server with timeouts configured, but the Device Tunnel VPN is authorised on the RRAS server and I don’t know if there is a setting to configure a timeout.
The result is that I see many duplicate Device Tunnel connections on each RRAS server that can be connected for 100s of hours.
Have you had a similar experience of this?
Thanks
Dave
Richard M. Hicks
/ September 16, 2019Yes, and I just replied there too. 😉 Anyway, yes, this is common. It is a bug in Windows Server RRAS and Microsoft is aware of it. No ETA on a fix though. Current workaround is to restart the RemoteAccess service to clear any stale connections.
David Trotter
/ September 16, 2019Hi Richard,
Thanks for the reply and confirmation of this known issue.
I will keep an eye out for when this is resolved via a patch, but no doubt will read about it on your blog first.
Regards,
Dave
trotterd
/ September 16, 2019Hi Richard,
Thanks very much for the confirmation of this know issue. I will keep an eye open for a future patch to be released. No doubt I will hear about it on your blog first before I read a patch note.
Regards
Dave
dekor
/ April 30, 2020Hi Richard, firstly, a huge thank you, without your website I would have been clutching trying to deploy AlwaysOn!
Don’t suppose you know if there is anything official from MS on the idle time out bug for IKEv2? Still seeing this ourselves and can sometimes cause issues with multiple sessions for device tunnels.
One other quick question, sometimes I notice if device and user tunnel are connected, we have to use the user tunnel IP to connect via services such as dameware rather than the device tunnel IP. Its not a huge issue but as we only have the device tunnel registering in DNS it means manually checking the clients IP.
Richard M. Hicks
/ April 30, 2020Are you talking about the issue where some connections still appear in the console but the device/user isn’t connected any longer? That issue still persists. I wrote a PowerShell script that allows you to scavenge these stale connections though. Details here: https://github.com/richardhicks/aovpn/blob/master/Remove-VpnConnections.ps1.
If you’ve followed the standard implementation guidance for the device tunnel it will only have routes to domain controllers and perhaps some systems management servers. This means you can only initiate connections to remote connected devices from those hosts listed in the device tunnel routing table. The user tunnel has broad/full access to the internal network so it can be managed from any host on-premises.
Dekor
/ April 30, 2020Thanks Richard, will review the script and look to get it scheduled. We often find disconnected sessions still stuck so that will help massively and save us having to restart services out of hours.
In regards to device tunnel, yes, that’s exactly the setup but thinking about it, as we have an overlap with the user tunnel this would explain why connections from management server only work via user tunnel IP if both are connected. I’ll have a review and see if I can scope routes better.
Jeevan
/ September 24, 2019Hi Richard, What Reporting information that Device Tunnel leaves on the RRAS server?. I’m trying to get recent/historic utilization stats for Device Tunnel from my RRAS server. Thanks.
Richard M. Hicks
/ October 7, 2019The RRAS service logs information about VPN connections in the C:\Windows\System32\Logfiles folder by default. If you’re looking for additional information in a more readable format, consider enabling Inbox accounting on the RRAS server using the Remote Access Management console or with the following PowerShell command.
Set-RemoteAccessAccounting -EnableAccountingType Inbox -PassThru
Gerard
/ October 3, 2019Hi all,
We have setup always on (almost) successfully (Server 2016 based). Thanks to this article. There is one strange issue. I have a user where browsing through files and folders on a fileserer via a devicetunnel goes very smooth, but when he copies a 50mb file to his local device, he gets ping loss and the copy fails. somehow the vpn is unstable. any idea what it can be? and what to do?
regards,
Gerard
Richard M. Hicks
/ October 7, 2019I’ve not see anything like this specifically…
Gerard
/ October 9, 2019hmm to bad. running server 2016.. are there no settings like nat traversal or MTU size settings?
regards,
Gerard
Richard M. Hicks
/ October 10, 2019You could certainly try adjusting the MTU size on the VPN server to see if that helps. I’d suggest taking a network trace on the client and server when the issue occurs. That might yield some clues as to why the connection is dropping.
Gerard
/ October 17, 2019I think we’ve found the solution. our firewall where the RRAS side uses service processor offloading by default. we switched it off and always on works correctly now. we have similar issues before, it was caused by ECN bit. I’ll dig in to it once I have some time.
Richard M. Hicks
/ October 21, 2019Thanks for the update!
Matt H
/ November 26, 2019Hello Richard,
I have a couple questions –
Do you still recommend to only use the trusted network detection on the device tunnel if you use both tunnels (device and user)? Or does 1903 resolve that issue?
We use LTSC 2019 which is Windows 10 build 1809. Do you know of any updates that will give us the 1903 functionality? I’ve seen your comments that 1903 is very stable for you.
Thank you,
Matt
Richard M. Hicks
/ December 5, 2019If your VPN server’s public hostname is resolvable on the internal network, then yes, I would recommend enabling Trusted Network Detection. You should be able to use this for both device tunnel and user tunnel without issue. There were some issue with this in the past, but Microsoft has since resolved them. If you’re running at least 1809 with recent updates it should be fine.
Teuka
/ January 3, 2020Have you ever seen that device tunnel is just missing after creation? Everything seems to be ok after running ps1+xml manually with system account. Script says “Created DeviceTunnel profile. Complete.” Just like in Richards examples. But when i check there is nothing:
PS D:\aovpn\device> Get-VpnConnection -AllUserConnection
PS D:\aovpn\device>
Rasphone says empty list.
My clients are win10 1809 enterprise (few hundred). Intresting is that exactly same ps1+xml is success and created with fresh install of win10 1909 enterprise.
But because fresh install is not option at this time, is there any glue what is going on. Any places to check and debug with those 1809 clients? Logs? I Have tried few different clients, differents accounts, removing antivirus but DeviceTunnel is not created.
Richard M. Hicks
/ January 4, 2020That’s quite unusual, especially if the same script/XML works on other machines. I’m assuming you don’t see a VPN connection when you look at the network interfaces in the classic network control panel either (ncpa.cpl)?
Teuka
/ January 5, 2020That is correct, I cannot see a new interface in the classic network panel either. Same script/XML works also with fresh win10 1809 installation, tested today.
So what could be show stopper with our production 1809 clients. Always on VPN and these scripts are native built-in features so this behavior is really weird.
There has been installed 3rd party VPN software in those production machines, but removed and rebooted before aovpn-device-tunnel try outs. Of course there could be some bad registry remainings or something else, but how to pinpoint those? How to check all requirements for setting up those device tunnels.. Any service to be started if not running?
I also noticed that when running script/XML with problem clients, It takes over one minute before “Created DeviceTunnel profile. Complete.” is prompted. Usually this takes only few seconds with healthy client. So those problem clients try very hard something but never succeed.
Any tips are more than welcome 🙂
Richard M. Hicks
/ January 6, 2020That’s quite unusual, and not something I’ve seen myself yet. If it takes more than a few seconds to create the VPN profile something is definitely wrong though. :/ What that could be I have no idea. I’m assuming that there’s nothing of interest in the event log? If not, have you tried looking in the VPN-Client operational event log? There might be information there that is helpful.
Jonathan
/ December 4, 2020I have the same problem. I’m using also Windows 10 1809.
Bhargav
/ January 10, 2020Is there a way I can change the connection type to SSTP and keep it that way even after it times out?
I have the following code:
” Automatic”
When I change this to SSTP, VPN fails to connect. In the above code line, when it times out trying to connect to SSTP it connects to IKEv2. I am trying to get it loop to SSTP again.
Richard M. Hicks
/ January 10, 2020The device tunnel uses IKEv2 exclusively, so the tunnel type should ideally be set to IKEv2 and not Automatic.
Bhargav
/ January 15, 2020So, is there no way to configure Always-on with SSTP?
Richard M. Hicks
/ January 15, 2020For the user tunnel, yes. For the device tunnel, no. The device tunnel uses IKEv2 exclusively.
Bhargav
/ January 15, 2020Thank you for clarifying.
I am trying to setup user tunnel with SSTP but I am not sure why it wouldn’t keep connecting using SSTP only. Why would it try to connect using IKEv2 after timing out? What can I change in VPN profile code to prevent this from happening?
Richard M. Hicks
/ January 16, 2020This has to do with the VpnStrategy setting in rasphone.pbk. If the NativeProtocolType is set to Automatic, this entry will be “6”, which means try SSTP first. If that fails, it will try IKEv2. You can change this setting, for example setting it to “8” which instructs the VPN client to try IKEv2 first and then fallback to SSTP if IKEv2 fails. However, the way it works today is that Windows updates this setting to use the last successful protocol. So if you set it to 8 and IKEv2 fails and SSTP succeeds, Windows updates the entry to “6”. The next time you try to connect it will try SSTP first.
Hopefully that clarifies things a bit for you! Also, Microsoft might be changing this behavior in the future. Stay tuned for more details…
Teuka
/ January 10, 2020In previous post we had a mysterious problem where no device tunnels were created nevertheless scripts says “Complete” after a long period of time (over one minute). No log events, no error messages anywhere, no hanging processes, no antivirus installed, no previous 3rd party VPN softwares and so on.
The fault was with Windows 10 native WAP Push Message Routing Service “dmwappushservice”, it was disabled for some reason in our environment.
After registry edit below and reboot, script took not more than 2 seconds to run and everything is working brilliant now:
HKLM\SYSTEM\CurrentControlSet\Service\dmwappushservice
DelayedAutoStart 1
Start 2
Happy to deploy those few hundred mysterious clients now with SCCM 🙂
Richard M. Hicks
/ January 11, 2020Thanks for the tip. Good to know! 🙂
Lee Humphreys
/ January 16, 2020Hi Richard,
As always amazing articles on both DirectAccess and AoVPN. Always my first point of call over MS documentation.
Something I cannot find anywhere in the MS documentation – if you don’t use Traffic Filters, then in theory the Device Tunnel can provide all the access to the Network the Machine needs (like the Infrastructure Tunnel in DA) but also for the User needs. It can be secured using Machine Certs just like DA.
If the Device Tunnel can provide all the access, why bother with the User Tunnel at all? This will simplify deployment and reduce the requirements on Ports and IPs on the VPN Server. One caveat could be Azure MFA?
If using only the Device Tunnel, can you still use Azure MFA?
Just trying to establish exactly why you would need both VPN Profiles. We have been using DA on Windows Server 2012 R2 for the last 4 years and are very happy with it. Looking to migrate to AoVPN but want to keep the same simplicity as DA for ease of management, but would like to integrate with Azure MFA if possible.
Thanks,
Lee
Richard M. Hicks
/ January 16, 2020Great point Lee. Ultimately this is a design decision that must be made by the organization. Indeed, the device tunnel is fully capable of providing the necessary connectivity for all remote network access. However, the device tunnel has some potentially serious limitations. It uses IKEv2 exclusively, which poses some operational challenges. It uses device certificate authentication only, so anyone (including an attacker!) who has the device now has full network access. As you pointed out, the device tunnel does not support MFA of any sort, Azure or third-party. The user tunnel is more robustly authenticated and supports MFA, which are crucial for protecting the enterprise from unauthorized access. However, if you’re comfortable with granting access to a device based solely on a certificate, and you’re willing to accept the functional limitations of IKEv2, then certainly a device tunnel only scenario would work. 🙂
Lee Humphreys
/ January 16, 2020Thanks Richard.
So I’m leaning more towards a simple Device Tunnel for pre-logon services and manage out, and then a User Tunnel for full access protected by Azure MFA.
I believe I have 2 options for Azure MFA. If I use Azure MFA directly, then the NPS extension must be installed on the NPS Server. But this will break the Device Tunnel as it does not support MFA? So then that pushes me towards Conditional Access and MFA, which will allow the Device Tunnel and still push the User Tunnel to Azure CA for MFA?
Am I correct in saying that?
Thanks,
Lee
Richard M. Hicks
/ January 16, 2020That’s a pretty common deployment scenario. Typically the device tunnel is configured to provide limited access to only those services required to support domain authentication (domain controllers). Access is restricted by using host routes in ProfileXML to ensure that only those servers are reachable via the device tunnel. However, if you want to manage over this tunnel, any management servers/workstations would need to be included in the routes on the client. Device tunnel authentication does not use NPS at all, that’s why it doesn’t support MFA. You can safely enable Azure MFA with the NPS extension and it will not impact device tunnel operation at all.
Lee Humphreys
/ January 16, 2020Excellent, thanks for the advice.
In your opinion, would you rather use the NPS extension or Conditional Access with MFA to support MFA? Wondering which experience is best for the end user?
Thanks,
Lee
Richard M. Hicks
/ January 16, 2020It really depends on your requirements. Using Azure MFA with the NPS extension is easier to configure and ensures that all of your clients are protected at all times. This is important because Azure Conditional Access won’t necessarily know if a device is lost or stolen. However, using Azure Conditional Access has the benefit of only prompting for MFA under certain conditions, which can reduce MFA fatigue for users. It’s a little more difficult to configure Always On VPN to support Azure Conditional Access though. I’ve got a post in the queue on that topic, but not sure when I’ll be able to get it published. Hopefully in the next few months or so.
Some Guy
/ January 16, 2020The “Traffic Filters” are deployed on the end device itself, which means administrators are already trusting the end device regardless of what the filters are configured to do, which means the “Traffic Filters” are pointless, which means having two separate tunnels solely for “Traffic Filters” is pointless. Filtering would need to be done server-side in order to not be a joke.
The only reason to use User Tunnel IMO is if you need EAP or SSTP, but that says more about the shortcomings of Device Tunnel than it does about any usefulness of the half-baked dual tunnel concept.
Richard M. Hicks
/ January 16, 2020I’m not a big fan of traffic filters for many reasons, but you’re right, an attacker using a different device woudln’t be subject to them and the gateway would allow everything if you relied entirely on client-side filtering. The one advantage of client traffic filtering is that you don’t have to send the traffic over the VPN to ultimatley block it, which might reduce some utilization. Not a big win in my book though. Also, keep in mind that traffic filters prevent all inbound traffic on the client which breaks many outbound management scenarios! If you plan to implement traffic filtering, it is best to terminate VPN connections outside of a firewall and ACL that traffic on a network device. That’s also much easier to manage because updating traffic filters requires touching every client. Doing it on a firewall centrally is much more effective and efficient for sure.
To be clear, the device tunnel seems “half baked” because it was an afterthought. Microsoft never wanted to include this in the Always On VPN story. The idea with Always On VPN is that clients are cloud-native and joined to Azure Active Directory, not an on-premises AD. Microsoft got enough push back from enterprise customers who are exclusively on-premises, or are using hybrid Azure AD join, they ended up having to provide some sort of pre-logon VPN connectivity to support logging on without cached credentials and to streamline self-service password reset.
Lee Humphreys
/ January 21, 2020I have successfully configured the Device Tunnel in the System context using PsExec – however, I can see it listed under Network Connections when logged in with a Local Admin Account – is this by design?
Richard M. Hicks
/ January 21, 2020You will see the device tunnel in the classic Windows control panel applet (ncpa.cpl) but it won’t appear in the modern Windows UI. I have occasionally seen where it will appear immediately after you configure it, but it won’t reappear if you close out the UI and re-open it.
Andy Cippico
/ February 3, 2020This is more of a sounding-off than a tech question:
I’ve had AlwaysOn VPN running well for some time now but never looked at tying down the Device tunnel routes until recently. I’ve successfully done that using the Route entries in the XML file and adding all the AD DCs. I’m finding that the client authenticates fine but of course the GPO to map network drives doesn’t run because I’ve not added any file server IPs to the routes. It just sits there and holds the login process up until it times out.
Now, I could just add each file server’s IP into the XML file but they tend to change over time and new ones are added as new offices are established. I’m using SCCM and you’d think that would handle this better – but it doesn’t. Is Intune the only tidy way to achieve device tunnel updates for every client?
Richard M. Hicks
/ February 3, 2020Interesting observations regarding the device tunnel. Indeed, restricting device tunnel access is recommended because the tunnel is not as strongly authenticated as the user tunnel. Providing full internal network access to any device that has a machine certificate is a potential risk. Also, the device tunnel exists only to provide pre-logon connectivity anyway, so the idea of limiting access to domain controllers is generally accepted. It is not uncommon to also include certificate services infrastructure over the device tunnel (issuing CAs, CRL servers, OCSP servers, etc.) and other systems management servers (SCCM, WSUS, etc.). Management servers and/or workstations can be included to enable manage out scenarios. I’m puzzled though as to why your logon script is having issues with device tunnel access. That’s usually done in the context of the user, so network access would be provided by the user tunnel, not the device tunnel. The only thing that would require device tunnel access would be startup scripts.
And yes, Intune is the way to go for managing Always On VPN profiles, both device tunnel and user tunnel. Managing them with SCCM makes things more difficult. Specifically, as you’ve learned, SCCM has no way to update an Always On VPN profile after it has been deployed. You must remove the connection entirely and re-create it. Not the case when using Intune though. You’d just make changes to the settings in the UI or upload a new ProfileXML and everything is taken care of for you.
Thoughts?
Andy Cippico
/ February 4, 2020Thanks Richard. You raise a perfectly valid point about the user context. I guess I jumped too quickly at a possible cause rather than investigating it fully.
The long delay seems to be the client trying to contact the internal CA (which I have not added to the restricted device tunnel routes). in fact I’m surprised to hear you say that it’s not uncommon (implying OK?) to add these certificate server(s). Maybe I’ll do that now.
I kind of guessed you’d say that Intune is the way to go. It does seem crazy that we’ve spent weeks designing and perfecting SCCM, only for MS to ask us to use their online product. Perhaps I’m just getting old, but I do resent this steady migration of everyday services to the cloud.
Rant over – thanks for listening.
Richard M. Hicks
/ February 7, 2020I hear you there. 🙂
Some Guy
/ February 3, 2020@Andy – If your VPN server is properly setup to forward DHCP requests to your DHCP server, you can push DHCP Option 121 – Classless Static Routes – to AO-VPN clients via DHCP. (Note: You do not have to be using DHCP for address-assigning; even if you’re assigning IP addresses from a static pool within RAS, you can still push options from an external DHCP server.) Somewhere on this blog there’s a comment from me describing the setup.
For updating things that can’t be set via DHCP, my Powershell script that deploys the AO-VPN profile calculates a MD5 hash of itself and includes this hash in the name of the VPN connection. When there’s an existing connection with a different hash in its name, then my script knows this connection was created by a different version of the script, so it deletes and re-creates.
Richard M. Hicks
/ February 3, 2020Using DHCP to assign options like this is something I still have to test. Hope to get to that soon. It would certainly make things easier from a client management perspective. 🙂
Andy Chips
/ February 4, 2020Hi Some Guy,
Re. DHCP-issued routes: That’s a really useful tip. Thanks. I’ll have to check it out.
Re. SCCM: Yes, I use a similar method, but with a registry key. I’m sure there are many ways to crack that nut.
When updating/refreshing AOVPN connection profiles using SCCM the only problem I can’t figure out is how to do it seamlessly. Specifically: if the user concerned has an active AOVPN connection at the time. I can’t just push out the update because the script has to terminate the connection first, then recreate it. This would cause a blip in traffic and an unhappy user.
How do you handle that?
Richard M. Hicks
/ February 7, 2020I’ve had customers resort to copying the script and XML file locally and creating a scheduled task to implement it.
Cason
/ February 3, 2020Hi Richard,
Thanks for this blog. It’s helped a lot in getting this set up for my organization — it’s amazing how lacking MS documentation is on AOVPN. How did you get around the issue of the computer preferring to use the Internet connection’s DNS rather than the DNS set in the VPN connection? For example — when doing an nslookup for my organization it uses the DNS of my hotspot, and internal resources cannot be accessed. However, if I do a Set-NetIPInterface VPN -InterfaceMetric 2, it works correctly. Of course, this requires local admin and in our organization users do not have local admin. I’ve set a Startup script to run that sets this metric instead. Is this the approach you would recommend or is there another tactic I should be aware of?
Richard M. Hicks
/ February 3, 2020This is a known issue for which there isn’t much you can do about except set the interface metric after the connection starts. We’re hoping that Microsoft will provide the option to set the interface metric as part of the Always On VPN configuration, but that’s not here yet.
Peter Klaffehn
/ February 4, 2020We use an PowerShell script to deploy the vpn tunnel. In the end of this script we set the metric of the vpn tunnel this way:
$RasPhone = (‘C:ProgramData\Microsoft\Network\Connections\Pbk\rasphone.pbk’)
$Metric = ‘IpInterfaceMetric=0’
(Get-Content $RasPhone) -replace $Metric, ‘IpInterfaceMetric=10’ | Set-Content $RasPhone
Works like a charm 😉
Regards, Peter
Richard M. Hicks
/ February 7, 2020Good to know. Thanks for the tip!
[email protected]
/ February 21, 2020Hi Richard, love the blog. It has been a tremendous asset as we’ve worked on AOVPN.
I was hoping to pick your brain regarding device tunnels. We have a working device tunnel and user tunnel setup, using RRAS, deployed with Intune. Everything seems to be working well except for some performance issues, but I think we are close to resolving them.
I am curious what the expected behavior of the device tunnel is in terms of disconnecting when the user tunnel is established. Currently, an off-network client will boot up, establish the device tunnel, login, and establish the user tunnel. The device tunnel remains connected until the client is back on the internal network. Is this expected? It hasn’t caused any issues to have both connected at the same time.
We are using TrustedNetworkDetection on the device tunnel. We are not using TrustedNetworkDetection on the user tunnel. We chose to make the VPN server unresolvable on our internal network to avoid the issue where a user tunnel (with TrustedNetworkDetection) detected the device tunnel as a trusted network.
I would assume the device tunnel would see the trusted network on the user tunnel and disconnect.
All of our clients are fully patched on Windows 10 Edu 1909 (18363.657).
Thank you.
Richard M. Hicks
/ February 22, 2020The device tunnel and user tunnel are two independent connections. It is expected that when a user is logged on that both tunnels will be established. Trusted Network Detection can be enabled on both the device tunnel and user tunnel because the detection process only evaluates physical (non-virtual) adapters. VPN interfaces are not evaluated using Trusted Network Detection. There were some issues with this quite some time ago, but they have long since been resolved. If you are running 1909 you shouldn’t have any issues enabling TND on both connections.
David
/ June 6, 2021Hello Richard,
I have exactly the same problem on Windows 10 21H1 / 20H2.
Device tunnel is set up with Trusted Network Detection and DNS suffix ad.mycorp.com. It works fine. Turns off instantly on corporate LAN and starts again on public networks. However, if I create and start a test user tunnel or connect to existing VPN solution that we use (from Checkpoint), the device tunnel detects DNS suffix on those other VPN adapters (because DCs are reachable from there) and disconnects. I have tested this on a VM and a laptop. If I run Get-NetAdapter -Physical, VPN adapters won’t show up, so they are detected as virtual adapters. Regardless of that, the device tunnel still “counts” them and drops connection.
Any ideas?
Richard M. Hicks
/ June 7, 2021I’ve been testing Always On VPN device tunnel/user tunnel on 21H1 recently and haven’t seen this behavior. Very strange, for sure! You might have to open a support case with Microsoft to have them take some low-level tracing to see what’s up. It’s always possible it could be a bug.
Tristan
/ March 13, 2020Hey Richard
Trying to deploy device tunnels here after successfully implementing user tunnels. When running this VPN Profile XLM and PS1, it configures but seems to leave out the Server Address, Sets the Tunnel Type to Automatic and Authentication Methods to Chap, MSCHapv2, Pap despite being hard coded in the VPNProfile.xml.
When i try to dial up the VPN connection manually, it prompts me for credentials so obviously not set up right.
Any ideas why this is happening or how to resolve?
Richard M. Hicks
/ March 18, 2020When that happens it usually means there is a syntax error in your ProfileXML. It’s frustrating because it doesn’t error out, just borks the configuration. 🙂
Gavin Ashton
/ April 2, 2020So so pleased to find another professional habitually using the term ‘borks’. It’s one of my absolute favorites!
Richard M. Hicks
/ April 2, 2020It’s an accurate term! 😉 Also, it’s fun to say and reminds me of the Swedish Chef. 😀
Gerard
/ March 19, 2020Hi Richard,
i was looking in to the NPS. and i only saw user tunnel logging. where can i find the logging of the device tunnels? it isn;t in eventlog or accounting file.
regards,
Gerard
Richard M. Hicks
/ March 20, 2020The device tunnel isn’t authenticated by the NPS, only by the VPN server. You’ll have to look at the event logs on the VPN server to find that information.
AD
/ March 24, 2020Hi Richard,
Great article!
I’m wondering if it’s possible to configure the XML for Device Tunnel with Split tunneling but instead of defining the routes you want to go through the VPN, can you configure it to define what routes you DON’T want to go through the VPN?
Use case: We are currently doing forced tunnel but want to switch to a split tunnel with only Microsoft traffic going out the end-user’s Internet and everything else via the VPN. Wondering if that’s possible.
Thanks!
Richard M. Hicks
/ March 24, 2020There’s no way to do this by using namespaces, it would have to be by IP address. You might be able to use exclusion routes to do this, but you’d have to know every IP address that Microsoft uses for its online services. Also, those addresses change on a regular basis, which would mean constantly having to update your VPN configuration to match. Not exactly ideal. Third-party mobility solutions are much better at this, BTW.
victor bassey
/ March 26, 2020Hello Richard, please is the command below all i need to ensure all my VPN connections (both User and Device tunnels use only authorized internal CAs and also enforce CRL check? ) is any other registry settings required?
$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
Richard M. Hicks
/ March 26, 2020Not quite. You can use this PowerShell script to set the root CA certificate: https://github.com/richardhicks/aovpn/blob/master/Set-IKEv2VPNRootCertificate.ps1.
The syntax is .\Set-IKEv2VpnRootCertificate.ps1 -Thumbprint ‘[thumbprint of root CA certificate]’ -Retart
You can then use this PowerShell script to enforce CRL checks on the VPN server: https://github.com/richardhicks/aovpn/blob/master/Enable-IKEv2CrlCheck.ps1
The syntax is .\Enable-IKEv2CrlCheck.ps1 -Restart
Have fun!
victor bassey
/ March 27, 2020Many Thanks Richard
Richard M. Hicks
/ March 27, 2020👍😁
Julien
/ April 8, 2020Hi Richard
As always thank you for sharing your knowledge. Must appreciated !
I’m testing running concurrent device and user vpns . I’m a bit concerned that the device tunnel does not perform any server checks. If someone spoof DNS it will easily redirect all user’s traffic to a fake VPN server that will accept anything the client throw at it.
I’m trying to prove this.
How does the server know which certificate to use. In my case i already have a public cert in the form of aovpn.organization.domain which matches the client’s VPN FQDN and it doesn’t work. If i create a private certificate of the same CN but issued by the internal CA it works (both server certificates are installed in the computer certificate personal store.
You mentioned in another post the server certificate must be from a private ca ? what dictates that ? If i create a self signed certificate matching the VPN FQDN will the client blindly accept it ?
Richard M. Hicks
/ April 8, 2020This is a legitimate concern for sure. By default, the VPN server will accept a certificate from a device issued by any CA it is configured to trust. It is recommended that you restrict the certificate to a private PKI and configure the server accordingly using Set-VpnAuthProtocol -RootCertificateNameToAccept.
zzzp18
/ April 9, 2020Hi Richard. Love your site, has helped me to get a AlwaysOn rig up and running.. I do have a random issue though when I get a Device Tunnel online – where it stays online for just 4x pings – and then disconnects. I can’t actualy see any event logs either related to the disconnection on either the client computer or the server. Have you seen this issue before? SSTP seems to work fine in the user tunnel.
zzzp18
/ April 9, 2020Sorry – I note I see the error “The user SYSTEM dialed a connection named DeviceTunnel which has terminated. The reason code returned on termination is 631” .. on the client machine.. This error happens after 4x successful pings
Richard M. Hicks
/ April 10, 2020The error code is helpful. A 631 error indicates the user disconnected. Must be something on the client side. Do you have any third-party antivirus/antimalware running on your client?
Richard M. Hicks
/ April 10, 2020Not sure what’s up there. Not something I’ve seen in the past. Typically if the tunnel comes up it will stay up. Does it stay up if you don’t ping anything? Or does it connect and then disconnect anyway?
Daniel
/ October 19, 2020Hey Richard,
thank you for your great Blog, it helped me alot to understand AoVPN releated stuff.
But i have a strange problem in our environment, if the UserTunnel connects automatically everythings fine and the DeviceTunnel stays connected. But if i forcefully disconnect the UserTunnel, untick Auto Connect (AutoTriggerDisabledProfilesList is set) and then manually establish the VPN connection, the DeviceTunnel is disconnected and in the Eventlog i get following error message:
“The user SYSTEM dialed a connection named VPN NAME which has failed. The error code returned on failure is 631.”
If i then dial the DeviceTunnel manually it connects without any issues … I am currently on Windows 10 1903. Have you ever come across anything similar?
Thanks in advance
regards Daniel
Richard M. Hicks
/ October 19, 2020I haven’t encountered anything like that myself. Does it happen on more than one client? Or just this one?
Daniel
/ October 20, 2020its on all Clients, looks like I have another unique failure, IT never gets boring.
Some Guy
/ April 14, 2020That sounds familiar like an issue I had with a NAT device on the client side. SOHO NAT router was trying to be “helpful” at NATing VPN traffic, but it had very ancient firmware that only understood IKEv1 not v2. Updating firmware on the NAT box fixed the issue.
Zak
/ April 15, 2020Thanks both.
The issue turned out to be – because I am using Win 10 pro, and hacking it all together, I basically set a Device Tunnel to come online via scheuled task when it sees event ID 4002 (which is basically when any new network is connected; it will attempt to use RASDIAL to dial the connection).. Turns out the script I was using disconnected any ‘existing’ connection as step 1, but then sometimes it would reconnect. I’ve removed the disconnection part and I just let RASDIAL to do it’s thing.. Kind of a half assed way of doing it but works well enough 🙂
Richard M. Hicks
/ April 15, 2020Ahhh…so the pain was self-inflicted! This is exactly why we try to avoid these types of hacky configurations. 😉
Rune Flo
/ April 15, 2020Win 10 Pro? I believe you need Enterprise for the device tunnel to work. Has that requirement changed?
Richard M. Hicks
/ April 15, 2020That’s correct. Windows 10 Enterprise Edition is a requirement to support the device tunnel. However, you can still deploy the device tunnel to Windows 10 Professional machines, it just won’t initiate the connection automatically. You can start it manually though.
Rune Flo
/ April 15, 2020AoVPN is a very useful technology, but it lack some IPv6 polish to be perfect for device tunnels (we use DT only). For dual stack IPv4/IPv6 and IPv6 only environments the .XML config file fails with any IPv6 address configured in there. Has this changed lately?
Richard M. Hicks
/ April 15, 2020Wasn’t aware that was broken. It’s certainly working for me in 1909.
Rune Flo
/ April 15, 2020Great news. I’m on 2004 now. Will give the Profile.XML some IPv6 addresses (Route, DnsServers) and see what happens.
Thanks for pointing out.
Rune Flo
/ April 16, 2020In the early days of AoVPN testing I used the “Get-WmiObject -Class MDM_VPNv2_01 -Namespace root\cimv2\mdm\dmmap” to verify what actually got interpreted and configured from the Profile.XML file. Unfortunately the output from this command misinterpret IPv6 addresses by just using the first 32 bits and display as an IPv4 address. This is still the behaviour of the above command (OS build: 19041.207).
Thanks to your above reply I now revisited my Profile.XML and added back IPv6 address for DnsServers and Route. Both IPv4&IPv6 addresses are now correctly represented in both Get-DnsClientNrptRule and Get-NetRoute.
One thing I need to figure out is the default IPv6 route ::/0 going to the VPN tunnel. This may have advantages too, as this AoVPN configuration allow connectivity from/to every IPv4/IPv6 combo out there.
Richard M. Hicks
/ April 16, 2020Oh yes, that’s still an issue. If you pull the ProfileXML out it will not return the IPv6 address. That’s just a formatting issue though. If you look at the actual routes assigned to the interface you’ll see them configured correctly there. Here’s a script to display those routes if anyone is interested: https://github.com/richardhicks/aovpn/blob/master/Show-VpnConnectionRoutes.ps1.
Matt
/ April 21, 2020Hello Richard,
I’m still struggling with the device tunnel. I did get it to login as a new user, enroll in an AOVPN cert, and install the user tunnel via SCCM software center. However, logging in is so slow. It seems like it takes 10-20 minutes. Also, when using the device tunnel even on an existing profile, logging in is so slow. I have to wait for it to finally show a desktop and the user tunnel can connect. Any ideas? I’m working with 17mb down and 9mb up so I don’t think speed is an issue.
Thank you,
Matt
Richard M. Hicks
/ April 22, 2020There are many things that can cause slow logons when the device tunnel is configured. You’ll have to go through the standard slow logon troubleshooting process to determine what it is. To start, I’d suggest enabling verbose messages on the logon screen so you’ll have a general idea where the delay is occurring. A network trace might also be helpful. You might have to dig deeper and use tools like the Sysinternals tool Procmon or the Windows Performance Analyzer to find the ultimate root cause though.
Matt
/ April 24, 2020Hi Richard,
It appears to be hanging at “Applying Group Policy Maps Policy”. I’m not sure how to overcome this except to give the Device Tunnel access to the file servers. I assume that would speed it up. Have you ran into this one before? How do you overcome it?
Thank you much,
matt
Richard M. Hicks
/ April 24, 2020So it’s an issue with drive mapping, likely caused by not having access to the location over the device tunnel. Are you mapping drives via startup scripts? Typically this would be done via logon script, and the user tunnel would be up (or come up quickly) when the user logs on. In a pinch you could allow access to the mapped drive location via the device tunnel, but that’s not recommended.
Matt
/ April 24, 2020Hello Richard,
We’re using gpo preferences to create the drive mappings. Would be a bit of a pain to switch them to login scripts. Bummer
Richard M. Hicks
/ April 25, 2020Agreed. I think GPP is the recommended way to map network drives anyway, so I wouldn’t recommend switching to logon scripts. What’s odd is that the drive mappings shouldn’t slow the logon process because the user tunnel should be up to allow access. I’d have a close look at what’s actually happening there to see what the delay is.
Matt
/ April 23, 2020Thank you, Richard. I’ll take a look at enabling verbose messages
Anthony
/ April 29, 2020Hi Richard, You instructions and scripts have been very helpful in setting up and troubleshooting the Always On Device Tunnel. I’m having a weird issue where the device tunnel does not show in “Get-VpnConnection -AllUserConnection” even if it is connected and working. This prevents me from using some of your scripts including the ability to uninstall the device tunnel by script. Thank you
Richard M. Hicks
/ April 29, 2020If you cannot see the device tunnel using the PowerShell command Get-VpnConnection -AllUserConnection then it isn’t a device tunnel connection. 🙂 Do you see the VPN connection in the Windows UI? Or by running Get-VpnConnection by itslef?
Anthony
/ April 30, 2020I did end up finding it in the APPDATA rasphone.pbk when I thought it was going to be in PROGRAMDATA. It did show under Get-VPNConnection, but not the -alluserconnection. Weirdly it does establish before login though. It must be something in my device tunnel creation Powershell script. I will go back through this and see where I went wrong. Thank you
Matt
/ May 1, 2020First, I want to say thank you to Richard for all his great work and documentation as it helped me immensely in getting up DirectAccess years back and now AOVPN.
I actually did something different with the Device Tunnel. I created a 2nd DNS name (AOVPNDT.contoso.com) that is dedicated for Device Tunnel only. I had it going it it’s own dedicated server. The user tunnel is going through a different external IP and is load balancing 9 AOVPN servers by a kemp. The device tunnel only has IKE ports where the user tunnel is SSTP only. On the Device Tunnel server, I run this command every 15 minutes:
Get-RemoteAccessConnectionStatistics | where {$_.connectionduration -ge “1200”} | Disconnect-VPNUser
This will remove any connections that are over 20 minutes which is plenty of time for a user to login to a computer for the first time or reset their password before login. It’ll actually reconnect quickly if there is no user tunnel connected which is perfect. If the user tunnel is installed and working by that time, it doesn’t reconnect as I have no internal DNS record for AOVPNDT.contoso.com. It can’t find that hostname which is perfect. With it eliminating sessions over 20 minutes, this allows me to dedicate just one server for the Device Tunnel.
Lastly, I created a schedule task to remove and recreate the device tunnel on the computers at computer startup. That way if I ever need to add another route by xml, I just drop the new xml file onto the computers by GPO. Then next time the computer starts up, the task will recreate the device tunnel using the new file (it’s always looking at the same xml file at startup). All in all, this is working very well.
Here’s the task which runs a updateDT.cmd file with these commands
PowerShell.exe -ExecutionPolicy Bypass -File “C:\windows\contoso\DT\removeDTprod.ps1”
PowerShell.exe -ExecutionPolicy Bypass -File “C:\windows\contoso\DT\device_tunnel_prod.ps1” -xmlFilePath “C:\windows\contoso\DT\VPNProfileprod.xml” -ProfileName DeviceTunnel
PowerShell.exe -ExecutionPolicy Bypass -File “C:\windows\contoso\Update-Rasphone.ps1” -ProfileName “DeviceTunnel” -InterfaceMetric 16 -DisableIkeMobility -AllUserConnection
Richard M. Hicks
/ May 1, 2020Very interesting solution for sure! Certainly reduces the number of concurrent connections by quite a bit! 🙂
Jeremy N
/ May 6, 2020Hey Richard,
I’ve come across your blog while deploying a new RRAS/NPS solution and your articles have helped immensely.
I saw others asking about multiple device tunnels for the same client. I have this issue too. It occurs when I reboot the client, and appears that the RRAS server doesn’t realize the original connection has expired. This clears after some time, but I suspect it will provide issues with management and dns resolution. Do you have any advice or experience on this issue?
Reading the comments, I see security recommendations for the device tunnel. In our case, I would like to do all administration over the device tunnel and maintain the ability to use SCCM to control it. Locking down routes would add some admin overhead over time. Since the device needs an AD issued cert and needs to trust the AD CA cert as well, isn’t this fairly secure? Is the risk that someone would export the cert and use it to connect, gaining full access?
I also wasn’t aware you could integrate on prem NPS with the AD MFA. Do you have any articles on this?
Regards,
Jeremy
Richard M. Hicks
/ May 14, 2020It is not uncommon for a single client to have multiple connections appear in the RRAS management console. This can happen for a variety of reasons, but typically it is nothing more than a nuisance and doesn’t cause any real problems (assuming you have enough available IP addresses and ports available). That said, you shouldn’t have any issues managing out because although the client is consuming a port, it won’t actually be an active connection with an IP address assigned. The client should still register it’s active IP address in DNS, and as long as DNS is fresh it should resolve correctly.
Regarding device tunnel security, the level or risk you want to accept is entirely up to you. If you are comfortable with allowing a device to connect to your entire network with just a certificate, that’s fine. Just understand that granting full access to a device can be risk. This means anyone on the device, including an attacker, would have full access over this tunnel. If you aren’t storing private keys on TPM, this presents significant risk because private keys stored on disk can be stolen quite easily and used on another device.
I don’t have anything specific about using Azure MFA with NPS, but you can find the Microsoft documentation here: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-nps-extension.
Some Guy
/ May 14, 2020“Restricting” the device tunnel by pushing route configuration is a complete joke IMO. It is all happening on the client device. So that accomplishes absolutely nothing against the threat of device certificate being used to establish a connection free of restrictions.
If you are not comfortable with allowing a device to connect to your entire network with just a certificate, then you need to do some restricting on your network side not on the device.
Richard M. Hicks
/ May 14, 2020Agreed. If an attacker has control over a device with an Always On VPN device tunnel configured, nothing stops them from adding their own routes and gaining full access anyway. Using host routes is a “better than nothing” option at best. The only other option is to use a separate server for device tunnel connections and control access to on-premises resources using a firewall between the VPN server and the LAN. Another option is to use a third-party solution (NetMotion, Palo Alto, Cisco, etc.) as they provide much more security than native Windows 10 Always On VPN.
aventador06
/ May 26, 2020Hi Richard,
Thanks for your bible on AOVPN, it’s really the most complete site I have found on the subject.
One question I haven’t been able to answer :
What hardware spec (talking about vCPU / RAM) would you recommend to server 1.000 AOVPN simultaneously on a RRAS Windows Server 2019?
Do you have any guidance regarding the size in relation to the number of VPNs we would like to accept?
Thanks
Richard M. Hicks
/ May 27, 2020I’d say that if you provisioned a VM with 4 CPU cores and 8GB RAM it should easily handle 1000 concurrent VPN connections. Unfortunately there isn’t any published guidance from Microsoft on this, but from experience I can tell you this should work. 🙂
aventador06
/ May 27, 2020Thanks a lot for your reply.
Have a nice day
Julien
/ May 28, 2020I’ve about 1100 concurrent users per VPN gateways (4 deployed) using IKEv2 (AES256, DH14, SHA384) CPU is roughly used at 40-45% with 300Mbps average encrypted traffic . Memory is mostly irrelevant for VPN connections but useful for SQL if local logging and reporting. Since SQL will always use as much memory as possible usage go up to 90%. Users are rekeying (SA) every 1GB / 1 hour
Vm specs
4 x vCPU Intel Xeon E5-2698 v4 (2.20Ghz)
8GB RAM
Do not be tempted to use more vCPU as each network interface is handled by a single CPU so it will result in some vCPU being unused. In my case I have 3 interfaces (3 CPUs for the NICS and 1 CPu for the OS operation = 4) previously i had 8 vCPU per server for 3 NICs. Most CPUs were not used at all while the 2 CPUs handling the inside and outside interface were used at 100 %. I was stress testing a server to see how it behaved. (I was checking impact of encrypted throughput vs number of IPSec rekeys from multiple concurrent clients on CPU usage so I wanted a ridiculous amount of IPSec rekey per seconds) . Multiple clients doing throughput test @200Mbps with IPSec SA set to rekey every 1MB 🙂 I ended up deploying more servers with less resources (from 2 servers with 8 CPU to 4 servers with 4 CPUs) Worked million times better. 2 Years ago I was asked that the solution supported our entire workforce working from home (6000 users) . I didn’t think i would see that day. Then COVID-19 turned up and i was glad my “predictions” where very close to real usage.
aventador06
/ June 8, 2020Thanks a lot for these very precise information.
I’ve asked for a 2 NICs / 4 vCPU / 16 GB RAM.
We won’t be installing SQL at the moment but might later.
We need to make this work first then we’ll optimize and grow everything to support our 3.000 potential users.
Panos
/ June 16, 2020Hello,
great articles.Please tell me if i can have host checking in the device tunnel mode(like av installed,updates installed etc).
Thank you!!!
Richard M. Hicks
/ June 18, 2020Not in the device tunnel with Always On VPN. Non-Microsoft solutions like NetMotion, Palo Alto, and others allow you to do this. With Always On VPN you can only use device checks with the user tunnel, and it requires integration with Azure AD and conditional access policies.
aventador06
/ June 17, 2020Hi Richard,
I’m having performance issues.
The Internet access is a 1 Gbps access.
The server is hosted on a VMware farm with 10 Gbps NICs
I can easily reach 1 Gbps when I copy a file from the RRAS to the internal LAN.
When copying an 11 Go file, it tops around 60/70 Mbps/s
When copying a 1.2 Go folder with 3000 files from the same network share, it barely reaches 12/15 Mbps/s but the average is around 700 kbps/s with some 0 kbps/s moments…
I’ve tried IKEv2 and SSTP tunnels with the same result.
Would you have any guidance?
Is it possible to get in contact with Julien so we could exchange on his settings?
Thanks in advance
Richard M. Hicks
/ June 18, 2020File transfer speeds over Always On VPN are always an issue it seems. There are many factors that can limit throughput, and it can be hard to find bottlenecks. VPN protocol encapsulation and encryption often reduce performance greatly. Not uncommon for sure.
Peter Klaffehn
/ June 18, 2020Hi, we are using the always-on device tunnel. The clients do all get an dynamically assigned ip. Is it possible to assign static ip addresses to some of the clients? Regards, Peter
Richard M. Hicks
/ June 18, 2020Yes, but only in certain scenarios. You can do this using NPS or Active Directory user account properties. However, it will only work with single-server VPN deployments. If you have more than one server and are using unique IP subnets per server (best practice) then it will break as you have no way to know which server the client will connect to.
Rob M
/ June 30, 2020Hi Richard,
Are you aware of any problems or known issues with User Tunnels and Device Tunnels not working concurrently?
I have a situation where a half of my users are working with no problems where as the other half cant get both tunnels up. Basically one tunnel will be up and when we try connect to the other tunnel its flips over to that tunnel then so it cant have both tunnels up. Its like its fighting for the one connection. Strange i know!!
See anything like this before?
Richard M. Hicks
/ July 1, 2020I’ve heard reports like this before, but not worked with anyone to troubleshoot this directly. There is a known issue with device tunnel/user tunnel coexistence in some scenarios on Windows 10 2004 though. Details here: https://directaccess.richardhicks.com/2020/06/25/always-on-vpn-bug-in-windows-10-2004/.
Asbjørn
/ July 2, 2020We have the same issue on 1909 also (been for quite som time). Removing the DeviceTunnel seems to be the easyfix.
Richard M. Hicks
/ July 7, 2020Good to know. Perhaps this issue has resurfaced? It’s not unheard of. :/
Syed
/ July 2, 2020Hello Richard
After running this command IKEv2 connections are not working anymore. Basically users connecting over IKEv2 are NO longer able to access any corporate resource.
Can I know how to revert OR roll this change back?
$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
Thanks & Regards,
Syed
Richard M. Hicks
/ July 7, 2020You can remove this setting using the following PowerShell command.
Set-VpnAuthProtocol -RootCertificateNameToAccept $null
Once complete, restart the RemoteAccess service.
Restart-Service RemoteAccess -PassThru
[email protected]
/ July 19, 2020Hello Richard,
first, thank you for the massiv amount of informations about AOVPN. We successuflly emplemented AOVPN in our infrastructure but with one issue. The client-connection to the internal ressources works great, but only oneway. We can’t connect to the vpn-client, no RDP, no access to local shares. Even icmp isnt working. We checked our internal firewall. The routing from internal net to the vpn-server(DMZ) is open. In wireshark we see the incoming icmp on the vpn-server. In tracert when we ping a client the last answering hop is the vpn-server. Is there a spezial configuration on the client or server side we forgott to do?
We use certificate based device tunnel / splitTunnel.
Thanks, kind regards
Irek
Richard M. Hicks
/ July 21, 2020Does the client have a route back to the internal host over the device tunnel? If so, I’d suggest enabling firewall logging to see if the traffic is being allowed or denied on the client.
Owen
/ July 21, 2020Hello,
“server 2016… you must enable machine certificate authentication for VPN connections..”
Our RAS servers are Server 2016 – we are currently using user tunnels only but wish to implement device tunnels too. When running the PowerShell command mentioned in your blog post, will this require a reboot of the RAS server at all or will it cause our current user tunnel connections to disconnect?
Regards,
Owen
Richard M. Hicks
/ July 21, 2020You don’t have to reboot the server, but you will have to restart the RemoteAccess service, which will disconnect all currently established VPN sessions.
Owen
/ July 22, 2020Thank you very much. I’m still waiting for that AOVPN book! Leanpub?
Richard M. Hicks
/ July 22, 2020Hope to do that in the future, just not sure when! I’ve been incredibly busy lately getting organizations mobilized since COVID hit, so once things settle down again perhaps I’ll have the cycles available to start working on that project. 🙂
ced666
/ August 14, 2020Hello Richard,
I would like to know if it is possible in the configuration of Always On to do controlled split tunneling. For example, is it possible that a user accesses company resources through the VPN tunnel but that Internet browsing goes through a Proxy which is hosted in the cloud? Indeed, some entity is shifting the management of Internet browsing to SAAS solutions. Is this possible in Always On or should I configure the local workstation firewall instead?
Thank you in advance for your help.
Regards,
Patrick
Richard M. Hicks
/ August 14, 2020I don’t see any reason why that wouldn’t work. I have many customers that use split tunneling and also use cloud-based security gateways like Zscaler and I haven’t heard of any issues with that configuration.
Shri S Muthulingam
/ September 2, 2020While configuring the DEVICE TUNNEL Alwayson VPN solution. Is this the correct setup in client. Authentication : Use machine Certificates. Can Richard confirm this.
Or can we use EAP and configure the machine certificate?
Please advise
Shri
Richard M. Hicks
/ September 5, 2020According to the CSP, only certificate authentication is supported when using the MachineMethod authentication type.
https://docs.microsoft.com/en-us/windows/client-management/mdm/vpnv2-csp
Andreas
/ September 16, 2020Hi Richard,
first thank you for your efforts!! Your Website has saved me hours on troubleshooting regarding Direct Accesss and also Always On VPN.
Currently I expect a strange Problem with Always On VPN and maybe you have some input for me.
I have both, User Tunnel and Device Tunnel configured and also use Split Tunneling. For distribution I use Intune with Custom Profiles and all works fine exept the Proxy Settings on the Clients.
In our Proxy PAC file I use normaly the “isInNetEx(myIpAddress()” function to check the IP Addresses on the Clients. If the result includes an IP Address of our Always On VPN Client IP Range the Client should not use the corporate Proxy Server.
Unfortunately it seems the function did not recognize the Always On VPN Interfaces on the Client and returns only the IP Adresses of the W-LAN or Ethernet Adapter. So the Client is using the corporate Proxy Server.
I have used this function for many years with our Direct Access Clients without a Problem so I was a litte bit perplexed.
After some research I thought I found a solution and created a new PAC file for our Always On VPN Clients which simply told the Client use no Proxy Server and go directly to the Internet and added these Lines to the User Tunnel XML File.
Helloworld.Com
HelloServer:8080
AutoConfigUrl = HTML Path to our PAC file
Server = FQDN to the Proxy Server & Port
Unfortunately it had not the effect i wanted, the Clients are still using the corporate Proxy Server.
Have you seen simillar Problems or do you know any solution for this?
Best Regards
Andreas Wagner
Richard M. Hicks
/ September 18, 2020Getting VPN clients to work with on-premises proxy servers is always a challenge. They seem to use them when you don’t want them to, and not use them when you want them to. 😉 That said, you should be able to configure proxy server settings in ProfileXML using the Proxy/Manual or Proxy/AutoConfigURL elements. I’d suggest using one or the other, not both.
Some Guy
/ September 18, 2020Could you maybe serve a different proxy PAC to the client based on the IP seen by the web server serving it? I use the same PAC URI for all types of clients in any sort of situation, and in IIS I use URL Rewrite to serve different content for that URI depending on the the client.
Matt
/ October 1, 2020Hey Richard, thanks for all your content. It’s been a huge help over the past months.
Our company has been using an AOVPN since March and we’re looking to start provisioning devices over the internet with Intune Autopilot. The environment has hybrid AzureAD in place which requires offline domain join to be included in the provisioning process and we are struggling with the best way to handle VPN connectivity before the first user login so the domain join process completes. The device VPN is IKEv2 using machine certificates they receive from our on premise domain so it can not be used to complete the domain join without first getting the certificates from our domain.
I’d appreciate your thoughts on the best way to establish the IKEv2 device VPN before login to enable the offline domain join. We are using RRAS and don’t currently run any 3rd party products that offer VPN.
Thanks
Richard M. Hicks
/ October 1, 2020I can’t speak with any authority about Autopilot, but I know that folks are doing it. I’d expect that if you’ve provisioned the certificate and device tunnel profile prior to the first user logon it should work. I’ll ask one of my SCCM/MEMCM friends to comment here with more details.
Mark
/ October 15, 2020I just wanted to expose what I think is a major bug in the current Intune policy for AO VPNs. I’ve had several Premier support tickets about this, leading to a bug fix request. The Microsoft documentation for the VPN incorrectly uses as a tag for the name resolution table – but the CSP documentation has the correct tag, . In the Intune policy, this is the “NRPT Rules” area of the DNS section. If you use this, the policy is writing the CSP tag , rather than the correct . This causes the policy to deploy but not connect. In short, test these settings before you use them! We’re all 1909 and 2004, so I’m not sure if earlier versions of Win10 are also affected. I hope this info saves someone the weeks of frustration I’ve had.
Mark
/ October 15, 2020the formatting of this website took out my greaterthan & lessthan symbols… the tags in question are DomainNameInformation (the incorrect one) and DomainNameInformationList (the correct one). My post above makes no sense with those being removed from the formatting…
Richard M. Hicks
/ October 16, 2020I apologize for that. The WordPress platform removes them, assuming for security reasons. If you’d like, repost your question using brackets like this “[” and “]” because I think they are allowed. 🙂
Richard M. Hicks
/ October 16, 2020Wow, that sounds bad. :/
Christian Albrecht
/ October 23, 2020I am still experiencing the problem of unticked “Automatically connect” tick for AlwaysOn User Tunnel.
This happens as soon as I connect to the device with another user and then connect with the first user again, then the tick is surprisingly unticked.
Setup Windows 10 version 1909 User / Device Tunnel with VpnStrategy 14.
Do you have this problem too. Will MS patch this or is a patch already available. It’s bit annoying for endusers.
Richard M. Hicks
/ October 24, 2020The only time I’ve seen issues with this being unticked is when using Intune. Doesn’t seem to happen when we use PowerShell/SCCM. Is that the case for you?
trotterd
/ October 26, 2020Hi Christian, I hope you are well.
This scenario is not a bug and is actually by design as you can only have one user per device that can have the capability to “Auto Connect”. If you check the following Registry key, you will see the that only one SID (UserSID) is present.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\Config
That SID will match the user that has the AutoConnect capability.
I asked Microsoft about this and there developers responded saying there is no near future feature to allow multiple users to have the auto connect capability.
I suspect that Richard has an SCCM/PowerShell setup that re-installs the User AOVPN profile at every Logon, instead of running the script once.
Regards,
Dave
Richard M. Hicks
/ October 26, 2020That’s definitely good to know. In that case I’d suggest using my Always On VPN configuration script (New-AovpnConnection.ps1) with the -AllUserConnection option. This will allow the connection to be used by all users on the device.
Chris
/ February 23, 2021As non of our users are local admin and installing VPN profile (using powershell) normally needs privileged permission we came up by installing it to all users profile. By checking now this Reg. value UserSID it is set to all users:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\Config
UserSID is set to S-1-1-0
But we use device and user tunnel and both are AO true tunnels.
By using device and user tunnel on all users it keeps not connecting the user tunnel automatically. Only device tunnel does connect automatically. Is this a BUG?
How do other customer install the VPN profile to non-local users?
Get-VpnConnnection -AllUserConnection
Name : DEVICE VPN
ServerAddress : xxx.xx.xx
AllUserConnection : True
TunnelType : Ikev2
ConnectionStatus : Connected
SplitTunneling : True
Name : USER VPN
ServerAddress : xxx.xx.xx
AllUserConnection : True
TunnelType : Automatic
ConnectionStatus : Disconnected
SplitTunneling : True
Richard M. Hicks
/ February 24, 2021You can deploy the user tunnel to all users using my PowerShell script: https://github.com/richardhicks/aovpn/blob/master/New-AovpnConnection.ps1. Just use the -AllUserConnection parameter and it works like a charm. No conflicts, both device tunnel and user tunnel coexist peacefully. 🙂
Ian Campbell
/ November 5, 2020Richard, great video on Intune user profile creation, so thanks for that! I’m a bit of a n00b to Intune, although we have access due to our Microsoft 365 subscrip. I’m trying to run through the process but having trouble understanding what certificate is specified at about 2:50. What certificate is this (client machine cert? Server SSTP cert? NPS server cert?), and how would I import it to Intune to select here? Thanks for any info!
Richard M. Hicks
/ November 6, 2020You’ll see that option if you are deploying certificates using Intune. If you are deploying certificates using Active Directory, you can ignore that. However, the device has to have a certificate before it joins the domain, so you really need Intune to deliver those certificates beforehand. 🙂
Ian Campbell
/ November 6, 2020Thanks Richard!
Mathias
/ November 27, 2020HI richard, thanks for all yours usefull works on directaccess and alwayson vpn.
We are facing to a strange issue … we use both device and user tunnel, but sometimes we have to restart manually device tunnel….if we open rasphone both vpn are connected but connexion to corporate servers and tools fails, if we restart device tunnel, connexion come back.
it’s appear more frequently on poor connexion but not only. I can’t find any log on device tunnel connexion. du you have his issue in the past ? where can i find logs to help me to solve this issue ?
thanks
Richard M. Hicks
/ November 30, 2020That’s quite strange. I’ve not come across anything like that in the past, so I don’t have any guidance to offer unfortunately. It might be best to open a support case with Microsoft to have them look at things for you.
Mathias
/ December 3, 2020thanks for your answers
i opened a support case with microsoft , i had a jfirst conatct to understand our config now i’m waiting.
If they find solution i will post it here
Andy Chips
/ December 2, 2020Yes, this happens randomly in our organisation too. Device is IKEv2 and User is SSTP, so not fixed by recent updates, sadly.
Mathias
/ December 3, 2020Yes device is ikev2 no choice , but user is ikev2 too with sstp backup, but finally the same issue. For users who have this issue we roll back to direct access, but we can’t do this with all users, because some of them use network software key which don’t work with DA.
Neil Clarke
/ December 17, 2020We are experiencing the same issue on a new install, have you had any feed back from Microsoft? we have also replicated this in a completely different environment and had the same outcome.
Neil Clarke
/ December 22, 2020Logged this direct from intune and the answer was a little disappointing, They basically said that yea there are issues with the device tunnel and just stick with the user tunnel? Doesn’t seam much help. we are going to keep rolling out just the user tunnel at the moment and keep an eye on the device tunnel for out test users.
Richard M. Hicks
/ December 22, 2020Microsoft doesn’t have much interest in promoting the device tunnel to be honest. They’d much prefer everyone go to Azure AD join instead. 🙂
Andrew Lepkov
/ January 24, 2021Hi Richard, thanks alot for your guide, but im stuck at verifying creation of the VPN device tunnel.
Everything in elevated powershell prompt goes well and ends just like as in your screenshot.
“Created DeviceTunnel profile. Complete”
But when i try to check it via Get-VpnConnection -AllUserConnection i dont see it. I use script provided in guide, no changes have been made.
I’m struggling with it for days, please help. Thanks in advance !
Richard M. Hicks
/ January 26, 2021Not sure what’s up, but if you don’t see it with Get-VpnConnection -AllUserConnection it probably failed for some reason. I’m curious though, does it show up if you use Get-VpnConnection straight up? Also, do you see it in the classic network control panel (ncpa.cpl)?
Neil London
/ February 8, 2021Hi Richard, great guides here that are much appreciated! After creating user and device tunnels, data encryption is being set to “Require encryption” rather than “Maximum strength encryption” on both. “Set-VpnConnection -Name $ProfileName -EncryptionLevel Maximum” fixed the user tunnel but the same command didn’t work for the device tunnel (running as system). Do you know if there’s another way of doing this?
Richard M. Hicks
/ February 10, 2021I would try using the syntax Get-VpnConnection [ConnectionName] -AllUserConnection | Set-VpnConnection -EncryptionLevel Maximum and see if that works for you. Let me know if that helps!
NASIF OLOYEDE
/ February 12, 2021Hi thanks for this .his is my first time using always on vpn…my question is that based on your explanation it seems that to implement device tunnel I only need the vpn server configured with two nic, the powershell script and XML script local on my windows 10 and certificates configured on the vpn server, am I correct? Since it is device tunnel I dont need radius server or NPS server ?
Richard M. Hicks
/ February 15, 2021You can use one or two NICs. The device tunnel doesn’t care either way. And you’re right, you don’t need NPS for the device tunnel. Authentication is based on a device certificate and validated by the VPN server when the connection starts. NPS isn’t used at all for the device tunnel.
NASIF OLOYEDE
/ February 22, 2021Hi I thought VPN server should have two NICs because of the following: Your Remote Access (VPN or Always On VPN) server sits between the internet and your internal network. It should have two separate NICs (physical or virtual ones). The NICs should have two separate IP addresses on them.
Also the Certificate Authority server should have a root CA server and enterprise CA (with AD) server for the organization’s PKI certificate service?
Thanks a lot
Richard M. Hicks
/ February 24, 2021It’s a design choice, really. There are advantages to using two NICs, but that doesn’t mean it won’t work with a single NIC. Some folks are willing to accept the tradeoff in security for simplicity and ease of configuration. Same with the CA. Best practice is to use two-tier configuration with offline root, but again it will still work if you issue right from an online root. Just a preference, ultimately. 🙂
Rob
/ February 18, 2021Hi Richard,
How would I remove the device tunnel config from the server?
We’ve been running the device tunnel for a little while and while good we’ve decided to go with user and MFA.
Thanks very much
Richard M. Hicks
/ February 24, 2021If you’re talking about removing the device tunnel connection from a Windows 10 client, you can use this script: https://github.com/richardhicks/aovpn/blob/master/Remove-AovpnConnection.ps1.
Ian Currie
/ March 1, 2021Although the Device tunnel can appear to be unstable, beset by lots of intermittent issues, I find that most of the trouble boils down to one fundamental flaw: the Device tunnel (unlike the User tunnel) does not automatically disconnect itself.
For instance, if a user’s internet connection drops, the Device tunnel stays in a “connected” state. Once internet connectivity is restored and a new User tunnel established, corporate connectivity fails because the stale Device interface (and its associated routes) remains in place. The affected user has to either reboot their computer or restart the IKEEXT service.
Similarly, whenever an NLB node is taken offline, only the User tunnel properly fails over. The Device tunnel on the client still points to the offline node, rendering corporate resources inaccessible.
Richard M. Hicks
/ March 1, 2021Have you tried disabling IKE mobility on your clients? You could also leave IKE mobility enabled and set the “network outage time” value to a lower value (default is 30 minutes).
Chris
/ March 3, 2021Hi Richard
Can I ask what’s the concept behind the -AllUserConnection Parameter or your Script: https://github.com/richardhicks/aovpn/blob/master/New-AovpnConnection.ps1.
You check if it is running under SYSTEM. This means it also tries to establish the tunnel with User SYSTEM. That furthermore means User SYSTEM would need a UserCertificate?
Is the a way to install the profile in default user profile and establish the tunnel under the context of the logged in user with his client certificate?
If the profile get’s installed in the user directory that means that if a new user is logging into the device the script for creating the user tunnel need to run again for that “new” user on that device?
Is this how you handle this normally or is there a smarter way?
Very much appreciated.
Richard M. Hicks
/ March 3, 2021The -AllUserConnection parameter configures the user tunnel VPN connection for “all users” of the machine, instead of the individual user’s context. Although the script runs in the SYSTEM context, it still configures a user tunnel. As such, each user that logs on to the device will need a user authentication certificate (assuming you’ve configured EAP/PEAP with certificate authentication).
The use case for -AllUserConnection is to allow more than one user on a device to have an Always On VPN user tunnel. Without it, only one user would have an Always On VPN connection, that being the last user to get a VPN profile. Other users logging on to the same device would still have the connection, but it wouldn’t automatically connect. It also makes deployment easier because it’s provisioned once, regardless of how many users log on eventually.
shrimoutlookcom
/ March 4, 2021Hi Richard,
We are piloting the Device tunnel for AlwaysonVpn solution. Device is Windows 10 20H2 Enterprise edition. The User based AlwaysonVPN is fully functional.
For Device Tunnel –
In the PowerShell do we need to add ROUTES? or how to restrict the device tunnel can access only the AD services for user logins. and restrict like file shares or other server access.
Please advise with your experience and knowledge.
Richard M. Hicks
/ March 4, 2021You’ll define host routes in your device tunnel ProfileXML. Here’s an example: https://github.com/richardhicks/aovpn/blob/master/ProfileXML_Device.xml.
Some Guy
/ March 4, 2021Anything you define in the client XML configuration does NOT “restrict” the device tunnel in any way. All it does it adjust where a well-behaved uncompromised client voluntarily sends its traffic. The tunnel is actually still completely unrestricted for any traffic that the client does put through it.
If you want to actually “restrict” what the device tunnel can access (rather than just suggest to clients what they should use it for), then you need actual restrictions. I.e. firewalling on the VPN server side.
Richard M. Hicks
/ March 4, 2021Agreed. You also have the option to implement traffic filters client-side, but that has its own unique set of challenges. 🙂
sukafun
/ June 25, 2021Hi Richard. Without your guides I wouldn’t be able to configure AOVPN. Thank you.
I have a question restricting the device tunnel. How would you restrict device tunnel to reach to your internal network?
I know you do add the required routes on the device tunnel xml but an attacker can add more routes.
So what I was thinking is deploy two RRAS, one for device tunnel and one for user tunnel and each one has its own server address so the vpn client connects to. This way you have two different subnets. Device tunnel subnet you put ACLs to restrict it. User tunnel make it open if you wish.
Is this the best way to achieve this restriction for device tunnel because I don’t see how you can add any filters or ACLs on the same subnet if used by both device and user tunnel.
Richard M. Hicks
/ June 26, 2021You can use host routes on the device tunnel to restrict access, but it is a simplistic way to do this. It also means an attacker can add their own routes and gain additional access to your network if one of your endpoints is compromised. Using two separate VPN servers would be one way to solve this problem. You can place restrictive ACLs on the device tunnel VPN server to address this limitation.
You could also employ traffic filters on the device tunnel. This would allow you to restrict access to specific hosts and also restrict protocols and ports. Historically they haven’t been used because they block all access inbound to the client, which prevents remote management. You can now specify a direction for traffic filters, which means you can enable manage out if you need it.
B Fox
/ April 13, 2021I’m having an issue with the Device Tunnel MTU sizing. I have no control over my provider and IKEv2 with 1400 MTU is dead slow. Lower the MTU to 1300 and it’s lighting fast.
I’ve tried doing a couple things to get this working correctly, none of which have worked. I need to be able to set these settings before the device goes out which is before the VPN Tunnel connects.
Set registry settings per Microsoft for default mtu for PPP and VPN – https://docs.microsoft.com/en-us/troubleshoot/windows-client/networking/change-default-mtu-size-for-ppp-vpn-connection#references – This worked on the server and for the User VPN but not for the device VPN on the client. Server is showing 1300 MTU now but client still shows 1400 for device tunnel.
Set sub interface MTU with Netsh – This only works when the tunnel is connected and I need to set this before it goes out.
Set MTU registry key under HKLM\System\CurrentControlSet\Services\Tcpip\Paremeters\Interfaces\{LONG-S-ID}. It looks like this key isn’t created until you connect once so can’t set it here either.
Any idea how to get this set?
Richard M. Hicks
/ April 14, 2021No idea. I’ve never had to mess with MTU settings on the server or client.
Some Guy
/ April 14, 2021If large packets do not work across your Internet provider’s network, then logically the place you should be adjusting MTU is on the interface to your Internet provider. The VPN tunnel should inherently size itself to fit inside the outer MTU. So fix your incorrect outer MTU.
Typically the “interface to your Internet provider” would be on a router. If the router interface to the ISP has the correct MTU set then clients behind the router will discover the correct MTU to use for packets to the ISP (as long as the router config isn’t broken).
Daniel
/ April 15, 2021Hi Richard,
your Website is big win for all Admins using Always on VPN.
Right now I am facing a big problem with the Device-Tunnel.
Connections from the VPN-Client to the corporate Network, everything works fine. (Routing is fine)
If I try to reach the VPN Client from the corporate network or the RRAS Server, it failed.
We use your Basic – XML, changed to our needs.
https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/vpn-map-da states to disable the on the XML
I did that, but the beheavior is the same.
I also check the windows firewall log on the RRAS Server and I see an ICMP Request marked as “SEND”
What did I miss?
Jeremy
/ June 28, 2021Hi Richard,
What a great site you have regarding the Always on VPN. Without this, there is no way to deploy Microsoft´s VPN solution easily. Why has not Microsoft done this easier ?
Now to my question regarding NPRT :
We have issues with Split DNS in the Device tunnel.
For Example :
We have specified this in our Usertunnel – example “corp.office.com”
but we have external websites on “corp.com” with external IP´s that we would like to not use the internal DNS servers. We do not have any DomainNameInformation specified in our Devicetunnel but have that specified on the Usertunnel. But when connecting the Usertunnel everything works.
Should we specify exclusions in the Devicetunnel xml for “.corp.com”
I do not really understand if there is a relationship with the Device and Usertunnel deployed ? Otherwise I do not understand why it works when fireing the Usertunnel up that has DomainNameInformation specified with “.office.corp.com” and DNSservers “our internal ones”.
Richard M. Hicks
/ July 6, 2021Thanks for the kind words. Much appreciated! 🙂
To begin, know that the use of NRPT on the device tunnel is not supported. However, it shouldn’t be required as the device tunnel provides limited network access only. Only Active Directory infrastructure (DCs, DNS, management servers, etc.) should only be reachable over the device tunnel. If you have public namespaces that you want to resolve over the user tunnel, you may have to use the NRPT to force them to be resolved by internal DNS servers.
Peter
/ July 12, 2021Richard, great series of AOVPN articles.
I’m struggling with AOVPN configuration (Device Tunnel). Looking at prerequisites, is it recommended/possible to use RRAS + NPS with Device Tunel?
Richard M. Hicks
/ July 12, 2021There’s no option to use NPS for the device tunnel. Device tunnel authentication is based on a device certificate only. This is performed by the VPN server and doesn’t use NPS.
Kyle
/ August 3, 2021Hi Richard, thanks for all these articles- really helpful in aiding the setup of AOVPN.
However, I am having an issue with the command:
Set-VpnAuthProtocol -UserAuthProtocolAccepted Certificate, EAP -RootCertificateNameToAccept $RootCACert -PassThru
It runs OK and our private CA is set, but our Device Tunnel then stops working with error 13806. This then works when I clear the above setting OR if the RRAS Server is able to communicate directly with the Domain Controllers.
Any help on above would be helpful, as we need to prevent any CA being authorised, and not have the RRAS communicate with our Domain Controller (as recommended by Microsoft).
Richard M. Hicks
/ August 4, 2021If the certificate on your endpoints is issued by the CA defined using Set-VpnAuthProtocol, it should work. If it does not, I would suspect one of two things. First, the certificate isn’t issued by the CA you defined on the RRAS server. Make sure you define the root CA certificate, not an issuing CA. Next, it’s possible that the CA you defined did not actually get implemented. If you run Get-VpnAuthProtocol do you see the same certificate you used with Set-VpnAuthProtocol? There’s a known issue where Windows can choose a certificate other than the one you enter. Details here: https://directaccess.richardhicks.com/2020/10/19/always-on-vpn-ipsec-root-certificate-configuration-issue/.
Kyle Sayer
/ August 10, 2021Thanks for the response. We only have one CA, so is the issuing and root CA. Checked Get-VpnAuthProtocol and confirmed correct thumbprint. At a loss on this one.
Richard M. Hicks
/ August 11, 2021If those match, I’d suspect an issue on the client. You’re certain the client has a device certificate issued by the same CA, correct?
Nigel
/ October 6, 2021Hi Richard,
Thanks so much for this guide.
I’ve been tasked with deploying an AoVPN config. A server admin has generated the config.xml file for me with the IKEv2 settings and connection details for me.
I’ve confirmed it works using powershell to import it and have also confirmed that using an InTune custom device configuration profile. The managers because it’s so new are wanting the option to add to the list of addresses for the split tunnel configuration.
From the testing I’ve done so far, it seems if I update the configuration of the xml on InTune and save it, it doesn’t seem to push a new config to the clients.
Is my only option here to resort to SCCM deployments with Powershell scripts to reapply config?
Richard M. Hicks
/ October 6, 2021In my experience, updating the XML in Microsoft Endpoint Manager/Intune usually results in those changes being propagated to the client. However, there’s nothing preventing you from using PowerShell to update the routing table if that works more reliably. FYI, I’ve found that the time it takes the settings to get pushed out varies greatly. Sometimes within the hour, other times a day or two. :/
Nigel
/ October 6, 2021Hi Richard,
Thank you so much for responding and confirming that updating the XML should work from Endpoint Manager.
In your experience is there a way to reliably force Endpoint to overwrite the XML? I’ve been doing some testing and would prefer to avoid falling back to using PS to re-write the ProfileXML.
I’ve tried updating different things as part of the device config profile such as descriptions and titles, then forcing the client I’m testing with to sync.
After syncing the client after making changes, if I look at the VPN Plugin Platform event logs, I can see an event ID 2018 at the same time as forcing the sync which is saying the VPN profile was modified, however when I check the system profile to confirm the XML config it hasn’t updated the routing table.
Apologies for the long winded messages, Microsoft Endpoint Manager sometimes almost seems like a black box with the level of detail it provides when it comes to config deployment.
Richard M. Hicks
/ October 13, 2021Not that I’m aware of. Also, after the sync, you may have to restart the device, or at a minimum restart the VPN connection for the changes to take effect.
Matt Klein
/ November 16, 2021We had a working MS VPN for some time and recently switched to Cisco ACI for our backend virtual networking and now running into a similar problem Thorsten Frohberg noted a few years ago (above) where MSVPN users can connect to the VPN but don’t have access to internal resources. Apparently Cisco ACI can’t create static routes as needed to point client traffic back to the client IP address on the VPN.
Is there anyone whos run into something similar? We’ve also been asked by Cisco if MSVPN has any sort of outgoing (from VPN server -> internal network) SNAT so it leaves VPN server with an IP the ACI knows how to route? I imagine this would require some sort of SNAT table on the VPN server itself to understand how to reroute the traffic as it comes back. Thoughts? Thank you in advance and sorry for long question.
Richard M. Hicks
/ November 16, 2021RRAS does allow you to configure NAT so that all client VPN traffic appears to source from the VPN server’s internal IP address. I typically don’t recommend this, however. Most commonly you would configure routes for VPN client subnets in your core network. I’ve not come across anyone else using Cisco ACI though, and I’m not familiar with its capabilities.
Matt Klein
/ November 16, 2021Do you have information/article on how to configure that? Why would you not recommend it? Thanks so much for the reply…
Richard M. Hicks
/ November 16, 2021I don’t have anything published, unfortunately. I’d be happy to put something together for you though. NAT should be avoided as much as possible because it usually causes more problems than it solves. It breaks end-to-end connectivity, prevents outbound management, and obfuscates the client’s original source IP address, making it more difficult to identify unique VPN clients in access logs. It is also a performance drain, and there have been reports that NAT in RRAS doesn’t scale well. I could go on… 😉
Matt Klein
/ November 16, 2021Thanks – I think I’ve found information on how to enable it now if absolutely necessary and am good with your warnings enough to avoid it. Take care
Richard M. Hicks
/ November 16, 2021🙂
Magnus
/ December 7, 2021Hi Richard
I have configured RRas on o windows 2019 server and set up both user-tunnel and device tunnel.
User-tunnel work great (user authentication goes thru NPS and is also using M365 Authenticator add-on)
Device-tunnel: Here we have issues, the device-tunnel is getting connected, but I cannot get traffic thru the tunnel
I have only one route setup in the device tunnel (leads to my domaincontrollers)
VPN-server is behind KEMP Vlm-3000
Thanks
/Magnus
Richard M. Hicks
/ December 10, 2021I’m assuming you can reach the resource from the VPN server itself, right? If so, have a look at the routes on the client itself. You’ve defined the route to your domain controller in XML or in the Intune UI, but did it get deployed to the endpoint correctly? Use Get-NetRoute -AddressFamily IPv4 and see if the route shows up in the routing table. Also, try running Test-NetConnection -Port 445 to validate the traffic is using the correct tunnel interface to get to the resource.
Magnus
/ December 10, 2021Hi
The user-tunnel is using sstp (works great)
Device-tunnel is IKEv2 and the client has correct route.
I also tried to separate the device-tunnel to another vpn-server (bypassing kemp).
Non of the vpn-servers can ping/tracert the clients (not even user-tunnel even thou it works great)
Richard M. Hicks
/ December 10, 2021That’s odd. I’d suggest taking a network trace on the VPN server to watch where the traffic goes on egress. You might also want to take a network trace on whatever resource you are trying to reach internal to ensure it is arriving.
Magnus
/ December 13, 2021After several hours of troubleshooting I ended up with F-secure preventing the traffic from the client…..
Now we can do autopilot even when out-of-office
This brings me to another “small” problem. Autopilot sets the windows edition to “windows pro” by default. When the user first logon to the computer, the edition will convert to enterprice (we have M365 E3 lic user-licens)
Problem here is that device-tunnel only work with win 10 enterprise. Solution right now is that we create a configuration profile in intune with os-edition upgrade and provide a MAK-key, The computer is converted to enterprise and the tunnel comes up, now we can logon for the first time.
Is there another (better) solution for this?
Thanks
Magnus
Richard M. Hicks
/ December 13, 2021No, that’s really the only workaround I’m aware of. I wrote about it a while back here: https://directaccess.richardhicks.com/2021/04/19/always-on-vpn-and-autopilot-hybrid-azure-ad-join/.
It’s not perfect, but it seems to work for the most part.
James Edmonds
/ February 1, 2022I’ve deploy device tunnels on a couple of occasions without issue, but at my current place of work, I am getting this error when trying to deploy the profile:
“Unable to create Device Tunnel profile: Operation cannot be carried out because an object already exists.”
Not one I’ve come across before. Even after removing all other VPN connections, I get the same.
Any idea what it’s complaining about?
Cheers
James
Richard M. Hicks
/ February 1, 2022Make sure you are removing VPN connections from all users using Remove-VpnConnection -Name [ConnectionName] -AllUserConnection. Also, it is possible that removing the connection will leave behind artifacts that can prevent a new profile with the same name from being created. In that case, use my removal script here.
https://github.com/richardhicks/aovpn/blob/master/Remove-AovpnConnection.ps1
If you’ve already removed the connection you can use the -CleanUpOnly switch to perform the cleanup. Be advised that due bug/known issue this script does not work on Windows 11. Hoping Microsoft fixes this soon.
James Edmonds
/ February 1, 2022Thanks Richard,
Gave the CLI attempt a go, but still got the same. I guess I’ll just have to wait, as I am using Windows 11, so fingers crossed Microsoft get this bug fixed soon.
I spotted an issue with their script when deploying the user tunnel, and came across your other post with the cleanup script. As I saw it doesn’t help Windows 11 users at the moment, on that occasion I had to comment out their EXIT command in their cleanup block in order for it to deploy.
Frustrating.
Thanks very much
James
Richard M. Hicks
/ February 1, 2022Indeed. Hope it is resolved soon!
Andy Chips
/ February 1, 2022I have had exactly the same error in the past. In my case I was trying to recreate a VPN connection with the same name as one I had previously deleted – at least I *thought* I’d deleted it. It turned out that I had to remove all occurrences of it from the following registry key:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseResourceManager\Tracked\{GUID}\device\default
After deleting this I was immediately able to create the VPN connection without error.
I hope that helps.
Richard M. Hicks
/ February 1, 2022Thanks for the tip, Andy. FYI, my Always On VPN profile provisioning and removal scripts include this cleanup task (and a few others) to prevent this sort of error. 🙂
https://github.com/richardhicks/aovpn/blob/master/New-AovpnConnection.ps1
https://github.com/richardhicks/aovpn/blob/master/Remove-AovpnConnection.ps1
Now if Microsoft would just fix the bug in Windows 11 they’d work on that platform too. 😉
James Edmonds
/ February 2, 2022Whilst Richard has confirmed his cleanup script does not work on Windows 11, do you know if this manual registry cleanup also works on Windows 11?
Richard M. Hicks
/ February 3, 2022It should, yes.
James Edmonds
/ February 3, 2022Damn, didn’t work.
Oddly, even if I pick a completely different and random name, I get the same error. I then see the above mentioned key populate with an entry matching that name, but no tunnel appears in rasphone.
I’ll give your install script a test next week on Windows 10 first, then see if it gives me more success on Windows 11.
Richard M. Hicks
/ February 4, 2022Let me know how it goes!
James Edmonds
/ February 3, 2022Your install script sadly doesn’t help with this either.
Looks like Windows 11 generally has some issues with device tunnel deployment, as I’ve searched the registry for references to the various profile names I’ve used and come up with nought.
There must be something else in there that’s conflicting with the device tunnel deployment 🙁
Richard M. Hicks
/ February 4, 2022Oh yes, there is a knwon issue with Windows 11 that is preventing several of my scripts from working. Hoping Microsoft fixes them soon. :/
Gareth Wilson
/ February 4, 2022Is anyone else seeing the VPN profiles failing to create using the PSexec util for the machine based vpn on Windows 11 ?
we are getting the error in the PS script.
Exception calling “CreateInstance” with “2” argument(s): “A general error occurred that is not covered by a more specific error code.”
The same profile.xml file works perfectly fine on all flavour of windows 10
Richard M. Hicks
/ February 4, 2022Yes, this is a known issue in Windows 11. There’s a bug that prevents the enumeration of the MDM_VPNv2_01 instance in the root\cimv2\mdm\dmmap namespace. Several of my scripts won’t work on Windows 11, as well as Microsoft’s MakeProfile.ps1 script. Microsoft is aware of the issue, but no ETA on when they will fix it.
Richard M. Hicks
/ August 1, 2022FYI, a fix for this issue is due out soon. I’ve tested a prerelease fix and it works without issue. Microsoft due to release the fix publicly in late September, hopefully. I’ll post something as soon as it is available.
Brendon
/ January 16, 2023Hi Richard, do you know if these patches have been released? if so, do you happen to have the KB number for them? Thanks!
Richard M. Hicks
/ January 17, 2023It is scheduled for release in late February. It’s been pushed back a few times, however. :/
Steve Prentice
/ November 4, 2022Hey. I just had exactly the same issue, what a pain. I found the following blog useful (sorry Richard!):
http://tbone.se/2022/07/21/always-on-vpn-user-tunnel-in-add-remove-programs-with-powershell-in-windows-11/
It contains a link to his GitHub, and a version of the script that worked fine for me, what a relief.
Richard M. Hicks
/ November 4, 2022Great stuff. Thanks for sharing! 🙂
James Edmonds
/ November 4, 2022Do we know what it was that TBone had to change in his script compared to Microsoft’s default one, that allowed it to work on Windows 11?
I have already written, and use my own script for our deployment, so rather than rearchitect our deployment method, I’d like to just incorporate the required changes into my existing script.
Richard M. Hicks
/ November 4, 2022It looks like he added a workaround to remove an existing Always On VPN profile using PowerShell instead of WMI. So, if removing an existing profile using WMI fails, it falls back to using Remove-VpnConnection.
James Edmonds
/ November 4, 2022Ah I see. We have issues deploying the profile even when an existing one does not exist, so I don’t think this will help us 🙁
Steve
/ March 9, 2022I have an existing User tunnel with conditional access and short lived MS VPN 1 hour certs. User tunnel is SSTP and with certs of course. I now want to try Device tunnel. I’m a the step to Set-VpnAuthProtocol on the current RAS but don’t want to mess up the Azure VPN cert. Will I break it?
Richard M. Hicks
/ March 10, 2022Nope! RRAS supports using different authentication methods for each tunnel. You can safely enable device certificate authentication while not disrupting your existing user certificate authentication with SSTP.
Steven
/ March 10, 2022OK thanks. I tried it but failed. I know it’s due to my certificate misunderstanding. Before running the 3 lines script to set Set-VpnAuthProtocol -UserAuthProtocolAccepted I have a test profile working. Not sure what cert it used of course but was working. I do have revokation check turned off due to the 1 hour cert for USER tunnel. After running succesfully the deploy ras server script my test profiles fail with this error..
IKE failed to find a valid machine certificate.
Now my computer has a domain issued cert and teh RAS server ( not domina joined) has a copy in the root authorty and the thumbprint seems to match my deviec issues cert of the parent CA. Should I remove the requirement somehow or do you thiknk its somehting simple?
Richard M. Hicks
/ March 10, 2022It should work if configured correctly. The value of -RootCertificateToAccept should be the thumbprint of the root CA server’s certificate. You can find that by looking at the certificate issued to your VPN server and/or endpoint and looking at the root CA certificate in the certificate chain.
Feel free to reach out to me directly if you need more help. 🙂
Steven
/ March 10, 2022Thank you for your quick reply. I did confirm they match. Still error 13801 from your book, page 337 (which is an awesome quick reference and continues to show me options and per your post https://directaccess.richardhicks.com/2021/12/13/always-on-vpn-error-13801/#:~:text=A%2013801%20error%20will%20occur,in%20their%20respective%20certificate%20stores. I have simply done it wrong. 🙂 Not to my surprise and figured as such. Not sure what else I can do. I only have the one domain device cert on my RAS and the one from the Azure VPN in trusted reoot and the domain issues does match a few computer issued certs on my pc, all with the same root issues CA and thumbprint. In my testing before I Set-VpnAuthProtoco I used a client profile but never picked a specific cert to use. Is this my problem?
Richard M. Hicks
/ March 13, 2022You should be able to connect if you don’t specify the root CA certificate using Set-VpnAuthProtocol. However, it’s best to define a specific PKI to trust for best security. If you are sure you have the right certificates in place on your endpoints and the VPN server, make sure your PKI is healthy and doesn’t show any errors in pkiview.msc. Expired or unreachable CRLs can also cause this error.
Steven
/ March 10, 2022I just realized, the server cert I’m using for the User tunnel SSTP is the same name as my public FQDN I’m conencting to in my VPN profile. However for my domain issued Device certs, the name does not match this. Should I be using that thumbprint?
Richard M. Hicks
/ March 13, 2022The certificate installed on the VPN server for IPsec from your internal CA must include the public hostname as the subject name. 🙂
Steve
/ March 10, 2022Sorry to spam you. You already answered my original question. Now my other issue is one of a bad device cert setup or Request/Import.
Looking through the server issued cert I see the CN for the root CA (where my device issued cert is from an intermediary). I understand the root thumbprint matches but I do not see any mention having any intermediaries on the root cert on the RAS. I do see Client authentication. Perhaps I did not request it properly for this non-domain joined server.
Richard M. Hicks
/ March 13, 2022The server and clients would need the entire certificate chain to fully trust the certificates.
Fabiano Montelo Maranhao
/ April 7, 2022Richard, have you seen any device tunnel in “dormant” status?
Get-VPNConnection – AllUserConnection
Name ConnectionStatus
——-
MyCompany DeviceTunnel Dormant
Richard M. Hicks
/ April 7, 2022I have not! Very interesting. I have no idea what would cause that. It should remain “always on” and not timeout for any reason.
Molouya
/ February 27, 2023Hi Richard,
What is the Impact is I remove the device tunnel connection from my laptop and use use only User tunnel?
Regards,
Richard M. Hicks
/ February 27, 2023You’ll lose the ability to log on to the device without cached credentials. Also, it’s possible that some GPOs may not apply correctly. Commonly that would be things like mapped drives. Otherwise you probably won’t notice any difference at all.
Matt Davies
/ June 16, 2023Hi Richard,
Any ideas if you could use the Set-VpnAuthProtocol -CertificateEKUsToAccept parameter to restrict down the accepted certificates to use a custom EKU like you do in https://directaccess.richardhicks.com/2019/05/28/always-on-vpn-users-prompted-for-certificate/?
If you can any idea what this command would look like as there information of that parameter is lite if you search the internet
Thanks,
Matt
Richard M. Hicks
/ June 18, 2023Absolutely. You can specify a specific application policy OID the certificate must include using -CertificateEKUsToAccept. Once that’s done the certificate must be issued by a specific trusted root and also include Client Authentication in addition to your custom EKU. Works like a charm. 🙂
Sai Krishna
/ November 27, 2023Hi richardhicks,
We have no issues in connecting the device tunnel from intune vpn profile, but what is the best way to remove the device tunnel because aovpn device tunnel is active which is causing main azure vpn issues. We have to make sure aovpn is removed, after removed by using script, after intune sync aovpn connection is coming back, how to tackle this please guide
Richard M. Hicks
/ November 27, 2023I’d suggest using my PowerShell script to remove any Always On VPN profiles. You’ll find it here.
https://github.com/richardhicks/aovpn/blob/master/Remove-AovpnConnection.ps1
Just make sure the profiles no longer apply to the user or device and you should be good to go. 🙂
Sa Krishna
/ November 27, 2023Thanks Richard.
Script is working like charm, but from intune device tunnel profile is assigned to all devices, hard to remove manually…
Any suggestions on vpn triggers will that suffice this scenario??
Appreciate your suggestion
Richard M. Hicks
/ November 28, 2023I’d suggest using Intune Remediations to do this.
https://learn.microsoft.com/en-us/mem/intune/fundamentals/remediations
I have detection and remediation scripts for Intune Remediations in my GitHub repository here.
https://github.com/richardhicks/endpointmanager
Sandeep
/ November 28, 2023Thank you for the wonderful article , sorry for asking a simple question, for some reason i am unable to run in system context , we are trying to run as admin still it is not under system context , is there amy way to run as system context
Richard M. Hicks
/ November 28, 2023You’ll need to use the Sysinternals tool Psexec. Here’s what the command looks like.
psexec.exe -i -s powershell.exe
That will launch another PowerShell command window running in the SYSTEM context.
You can download the Psexec tool here: https://learn.microsoft.com/en-us/sysinternals/downloads/psexec