Unlike DirectAccess, Windows 10 Always On VPN settings are deployed to the individual user, not the device. As such, there is no support for logging on without cached credentials using the default configuration. To address this limitation, and to provide feature parity with DirectAccess, Microsoft later introduced the device tunnel option in Windows 10 1709.
Device Tunnel Use Cases
The device tunnel is designed to allow the client device to establish an Always On VPN connection before the user logs on. This enables important scenarios such as logging on without cached credentials. This feature is crucial for organizations who expect users to log on to devices the first time remotely. The device tunnel can also be helpful for remote support, allowing administrators to manage remotely connected Always On VPN clients without having a user logged on. In addition, the device tunnel can alleviate some of the pain caused by administrators resetting remote worker’s passwords, or by users initiating a Self-Service Password Reset (SSPR).
Device Tunnel Requirements
The device tunnel requires Windows 10 Enterprise edition 1709 or later, and the client device must be joined to the domain. The device tunnel must be provisioned in the context of the local system account. Guidance for configuring and deploying a Windows 10 Always On VPN device tunnel can be found here.
- Windows 10 Always On VPN Device Tunnel Configuration using PowerShell
- Windows 10 Always On VPN Device Tunnel Configuration using Microsoft Intune
- Windows 10 Always On VPN Device Tunnel with Azure VPN Gateway
Device Tunnel Authentication
The device tunnel is authenticated using a certificate issued to the client device, much the same as DirectAccess does. Authentication takes place on the Routing and Remote Access Service (RRAS) VPN server. It does not require a Network Policy Server (NPS) to perform authentication for the device tunnel.
CRL Checking
Eventually an administrator may need to deny access to a device configured with an Always On VPN device tunnel connection. In theory, revoking the client device’s certificate and terminating their IPsec Security Associations (SAs) on the VPN server would accomplish this. However, Windows Server RRAS does not perform certificate revocation checking for Windows 10 Always On VPN device tunnel connections by default. Thankfully an update is available to enable this functionality. See Always On VPN Device Tunnel and Certificate Revocation for more details.
Configuration Best Practices
As the device tunnel is designed only to support domain authentication for remote clients, it should be configured with limited access to the on-premises infrastructure. Below is a list of required and optional infrastructure services that should be reachable over the device tunnel connection.
Required
- All domain controllers
- Enterprise DNS servers (if DNS is running on servers other than domain controllers)
Optional
- All issuing certification authority (CA) servers
- All certificate services online HTTP responders
- All certificate services Online Certificate Status Protocol (OCSP) servers
- System Center Configuration Manager (SCCM) distribution point servers
- Windows Server Update Services (WSUS) servers
- Management workstations
Limiting Access
Limiting access over the Always On VPN device tunnel can be accomplished in one of the following two ways.
Traffic Filters
The administrator can configure traffic filters on the device tunnel to restrict access only to those IP addresses required. However, be advised that when a traffic filter is enabled on the device tunnel, all inbound access will be blocked. This effectively prevents any remote management of the device from an on-premises system over the device tunnel.
Host Routes
An alternative to using traffic filters to limit access over the device tunnel is using host routes. Host routes are configured with a /32 prefix size and define a route to a specific individual host. The following is an example of host route configuration in ProfileXML.
Note: A PowerShell script that enumerates all enterprise domain controllers and outputs their IP addresses in XML format for use in ProfileXML can be found here.
Caveats
Some organizations may have hundreds or even thousands of domain controllers, so creating individual host route entries for all domain controllers in profileXML may not be practical. In this scenario it is recommended to add host routes only for the domain controllers that belong to the Active Directory site where the VPN server resides.
Supportability
Do not use the <DomainNameInformation> element in ProfileXML or enable force tunneling for the device tunnel. Neither of these configurations are supported.
Tunnel Coexistence
The device tunnel can be safely deployed in conjunction with the user tunnel whenever its functionality is required.
DNS Registration
If the device tunnel and user tunnel are both deployed, it is recommended that only one of the tunnels be configured to register in DNS. If the device tunnel is configured to register its IP address in DNS, be advised that only those devices with routes configured in the device tunnel VPN profile will be able to connect remotely to Always On VPN clients.
Additional Information
Windows 10 Always On VPN Device Tunnel with Azure VPN Gateway
Windows 10 Always On VPN Device Tunnel and Certificate Revocation
Windows 10 Always On VPN Device Tunnel Configuration with Microsoft Intune
Windows 10 Always On VPN Device Tunnel Does Not Connect Automatically
Windows 10 Always On VPN Device Tunnel Missing in Windows 10 UI
Deleting a Windows 10 Always On VPN Device Tunnel
Windows 10 Always On VPN Device Tunnel Configuration using PowerShell
Michael Leeming
/ March 30, 2020Tunnel Coexistence
Will this use twice the amount of ip addresses for connected devices?
Effectively many more, as RAS often have multiple device tunnels hanging from the same devices.
Michael Leeming
/ March 30, 2020And if registerDns makes more sense with User tunnel regarding support scenarious, then leaving registerdns out of device tunnel, will make it hard for sccm etc. to contact a device, before it also has a user tunnel active?
Richard M. Hicks
/ March 30, 2020Correct. If you decided to register the user tunnel, then SCCM and other management tools must wait until a user is currently logged on to connect remotely.
Richard M. Hicks
/ March 30, 2020Absolutely. That’s why it is recommended only to deploy the device tunnel when absolutely necessary. If you have to deploy it, plan accordingly. It will require at least twice the address space, and certainly some more resources on the RRAS server to support the extra connections. Not much more though, as mos of the traffic will use the user tunnel anyway.
Eric
/ March 30, 2020Thanks a lot for answering questions and this clear post about device tunnel. Greetings from the Netherlands!
Richard M. Hicks
/ March 30, 2020My pleasure!
Michael Leeming
/ March 30, 2020Well, there is also the option to only install a device tunnel, but then you will miss out on SSTP fallback, which is only supported by user tunnels.
I think maybe it is best to have 2 options, a group of devices with only user tunnels and a group of devices with only device tunnels.
I wish there was an option for triggering a device tunnel before login and to have it close down completely after login, before a user tunnel is started.
Richard M. Hicks
/ March 30, 2020I’ll be covering that topic in depth next week. 🙂 You could, in theory, hack something together yourself to accomplish this. You could set the device tunnel AlwaysOn option to ‘false’, then create a schedule tasks that triggers the connection upon system restart. You could then configure another scheduled task to disconnect the device tunnel when the user tunnel comes up. Not sure how well it will work, but it might be interesting to test sometime!
Michael Leeming
/ March 30, 2020I have had the same thought, but I think the hardest part would be not to start the device tunnel when connected to company network already or trigger the device tunnel when Internet is available, cause it might not be at boot. Normally device tunnel would trigger as soon as Internet is available, this is a slightly different scenario and timing could be an issue. (mostly with WiFi)
But it is very interesting to see if it is possible.
Richard M. Hicks
/ March 31, 2020There are many other scenarios to consider as well, such as coming out of sleep/hibernate, what happens if a user tunnel connection drops, etc. No question this would likely cause more problems than it solves. It was just a thought really. Technically possible, just not practical.
Michael Leeming
/ April 6, 2020I’m planning to go with the following.
1.. Deployed device tunnel with always on disabled, but with register dns and routes to all internal subnets.
2. Create a scheduled task which fetches a public available text or XML list. If device is in the list, the device tunnel should connect. Run scheduled task at boot and forever check the list every 5 or 10 minutes.
3. Deploy user tunnels with always on enabled and also with register dns and routes to all internal subnets.
4. Make it possible for IT administrators to add devices to the public list, when a device needs to allow non-cached logins or when a remote device needs to be managed by sccm, manually or similar.
To some it up, the device tunnel will become a backup vpn connection, which remotely can be turned on when needed. But in day to day usage, only the user tunnel will be used and conflicts between the two tunnels, like register dns, will not be a big issue.
Hope this makes sense 🙂
Richard M. Hicks
/ April 6, 2020Clever! Hope this doesn’t cause more support overhead than it is worth though. 🙂
Graham
/ April 20, 2020Hi Richard, many thanks for these fantastic articles.
Do you know if Read-Only Domain controllers are supported? We have a single AD site with 2 DC’s but we would prefer to only allow access to a RODC.
Richard M. Hicks
/ April 20, 2020I believe so, but it’s not something I’ve tested.
Evgeniy
/ December 22, 2022Hi, Graham!
I hope you can receive my reply and the topic is still actual to you. Did you finally try to establish Always On VPN with RODC? Please, check my post here on December 22, 2022.
grahampriley
/ April 20, 2020I should have also said that we are looking at deploying device tunnel only so we will not need an NPS server. We are going to allow access to our SCCM DP, WSUS, AV server.
In fact, please ignore me, I have answered my own question, we use LAPS so the remote clients will need to be able to update their AD computer account.
Thanks anyway!!
Richard M. Hicks
/ April 20, 2020Ok! 😉
dandirk
/ May 7, 2020So we have found we need to include our DNS servers to the device tunnel otherwise get the domain controller cannot be found message.
While logically this seems reasonable, your lack of mentioned it, makes me wonder if something isn’t working right.
That said, my assumption (out of thin air), is that we use InfoBlox for DNS. Not entirely sure but believe we have been trying to remove at least some reliance on the Win/DC DNS services.
Does this sound like a reasonable assumption?
Richard M. Hicks
/ May 14, 2020Good point. I’ll update the post to reflect that. Most organizations have DNS running on their domain controllers so the guidance reflects that. But you’re right, if that’s not the case and you are using something else for DNS those would need to be included too.
Ryan Arnold
/ August 27, 2020Thanks for the great content as always, Richard! I have a question regarding DNS resolution. We are using a device tunnel setup on Windows 10 v2004 with Server 2019 and our internal domain is the same as our external. I’ve noticed that after creating the device tunnel, pinging a internal resource always returns external IP unless I change the metric of the device tunnel to something lower than the Ethernet adapter. Is there a way to set the metric lower in the xml or perhaps there is another way to address this altogether? Thank you.
Richard M. Hicks
/ August 27, 2020This is a common complaint. Indeed, lowering the interface metric of the VPN interface to something lower than the Ethernet interface is the way to resolve it. Unfortunately you can’t do this in XML. However, you can update this setting after the VPN connection has been created by using my Update-Rasphone.ps1 PowerShell script. You’ll need to run it on each machine where you have this problem. Here’s the syntax.
.\Update-Rasphone.ps1 -ProfileName [name of VPN profile] -InterfaceMetric 3
You can find the script here: https://github.com/richardhicks/aovpn/blob/master/Update-Rasphone.ps1.
Ryan Arnold
/ August 27, 2020Awesome – thank you!
James
/ July 24, 2021Using the update ras phonebook script seems to successfully update the phonebook file, and the device tunnel picks this up after a reboot, but for some reason the user Tunnel ignores the setting in the pbk file and remains on its previous value… any ideas why ?
Richard M. Hicks
/ July 25, 2021Not sure. Is the VPN profile deployed in the all users context? If so, the rasphone.pbk will be in a different location (C:\ProgramData\Microsoft\Network\Connections\Pbk\).
Jake Gilfillan
/ October 20, 2020Richard, Curious if you’ve seen any issues with the user tunnel initiating its connection from the Device Tunnel like some sort of loopback? When checking the RRAS console, almost all of our user’s client address as the IP they’ve received from the Device Tunnel. Many of the users also have multiple user tunnels from the same device IP, some users taking 10 IPs between the tunnels.
Richard M. Hicks
/ October 24, 2020Unusual. I’m curious though…is the public hostname resolvable over the device tunnel? I’m wondering if when the user tunnel tries to connect it is resolving to an IP address that is reachable over the device tunnel, so you have a tunnel-within-a-tunnel scenario?
David
/ November 17, 2020Hello Richard, I am trying to find information about Always On VPN and PCI DSS compliance. Currently my company uses Checkpoint vpn with two-factor authentication (AD password + RSA Token). Besides the fact that clients have to be manually deployed, connection process is also inconvenient for users. There is no way to manage devices and change expired user passwords. I decided to implement Always On VPN device and user tunnels or at least device tunnel and leave Checkpoint vpn instead of user tunnel. My collogues argue that this kind of setup is not secure and cannot be PCI DSS compliant as it does not use MFA. I can’t find any source about this topic on the internet. Maybe you can answer these questions:
1) Can device tunnel with only machine certificates be accepted by PCI?
2) Is user tunnel technically considered 2FA using NPS and Peap-TLS authentication?
3) If it is possible to add RSA Token authentication on top of user certificate or password authentication for Always On VPN?
Richard M. Hicks
/ November 24, 2020I’m not familiar at all with the PCI/DSS specifications, so I don’t know specifically if Always On VPN would meet their compliance requirements. However, if you are using certificate authentication (device or user) I would argue that is defacto multifactor authentication. The “something you have” is the corporate-issued device and the “something you know” is the credentials to log on to the device itself. Remember, MFA is implemented to mitigate the risk of lost or stolen credentials. However, that risk is effectively mitigated when you use certs for authentication, essentially making MFA redundant.
For the record, it is possible to integrate MFA with Always On VPN when using either MSCHAPv2 and in some cases PEAP, depending on your MFA provider.
David
/ November 24, 2020Thanks for reply. I agree with you about MFA definition and hopefully I can use it as an argument.
For reference, PCI DSS has very strict rules. It requires use of MFA, jump servers and other things that complicate life. As for vpn connections, it several requirements. One of them is: “Multi-factor authentication must be used for all VPN connections”, that does not tell much.
( https://bit.ly/2J6CrWL )
Richard M. Hicks
/ November 30, 2020I think that client authentication certificates satisfy the “spirit” of the rules, but perhaps not the “letter” of them. My guess is that it would depend on the auditor, and you know how that can go. 🙂
Tiifrali
/ January 19, 2021Just wondering.. Has anyone succeeded to deploy a user certificate through device tunnel? 🙂 If there is a new remote user who don’t yet have remote connectivity with always on user user tunnel.
Should just ca.contoso.com .. do the trick? Or is it unsecure.
Richard M. Hicks
/ January 21, 2021That won’t work. The user must sign on to request the certificate, but the user tunnel won’t connect without the certificate. Chicken/egg. 🙂
Michal K.
/ March 10, 2021comparing to DA, if Cert cant be used as a requirement, how would you secure the user profile connection so users cant just add the vpn connection to personal devices?
Richard M. Hicks
/ March 10, 2021You’ll need to issue the certificates and ensure they are only enrolled with a TPM on your client devices.
MichalK
/ March 10, 2021if cert cant be used to secure user profile, how would you prevent users from adding vpn connection on their personal devices?
Richard M. Hicks
/ March 10, 2021If the VPN server accepts standard credentials (username/password) then nothing. That’s the advantage of using certificates for client authentication. Not only do they provide higher assurance, they can’t (easily) exported and used on another device. This ensures that VPN connections only from your managed devices can be made.
Ajni Kurtaj
/ February 11, 2021Hi Richard, right now I have a deployment with User and Device Tunnel. The “Manage Out” feature is only available on the User Tunnel. Device Tunnel never works. Is that a feature or a bug?
Richard M. Hicks
/ February 15, 2021It depends. If you’ve configured only specific host routes on the device tunnel, then you’ll only be able to manage from those hosts specified in the routing configuration on the client. Also, make sure you configure DNS registration on only one of the connections (most commonly the device tunnel). Make sure any on-premises servers/workstations you want to manage out from are in the routing configuration on the device tunnel for your clients. Should work then.
Paul Kecun
/ February 24, 2021Hi Richard, we’ve been making use of Always On Device Tunnels for about 12 months now without much in the way of issues.
Everyone is on Win10 20H2 and the RRAS Server is Windows 2019 with the IKEv2 Fragmentation key set.
Recently started to find that a number of clients are regularly disconnecting at the same time every day but I haven’t been able to find a reason – and it’s very intermittent!
There’s no packet loss at the client end or the server end. It can’t be an idle timeout as sometimes it will disconnect when you’re actively using it and it always reconnects again within 30 seconds.
There’s is nothing else of note in the event logs anywhere. I’ve tried increasing UDP timeouts on the firewall / RRAS (clutching at straws) but no joy.
Client end –
20226, RasClient
The user SYSTEM dialed a connection named xxxxxxx which has terminated. The reason code returned on termination is 631.
Server end –
20272, RemoteAccess
RoutingDomainID- {00000000-0000-0000-0000-000000000000}: CoID={xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx}: The user xxxxx.xxxxxxx.xxx connected on port VPN2-248 on 23/02/2021 at 22:57 and disconnected on 24/02/2021 at 13:38. The user was active for 881 minutes 31 seconds. 41198811 bytes were sent and 30714340 bytes were received. The reason for disconnecting was administrative settings or explicit request. The tunnel used was WAN Miniport (IKEv2). The quarantine state was .
Don’t suppose you’ve seen similar in your travels and have any suggestions?
Richard M. Hicks
/ February 27, 2021I’ve heard others report similar issues. No one specific cause has been identified though. Sometimes it is related to group policy processing. Others it was third-party security software interference (client or server).
Johan Janssen
/ September 21, 2021Hi Paul,
Did you ever solve this issue? Seeing the same here and no idea what is causing it ….
Kind regards,
Johan
db
/ May 8, 2021Hi Richard,
I am in the process of enabling device tunnel on an existing setup. I limit the certificate ekus to a custom value.
When I ran the this setting on the RRAS server it said the EKU is invalid for a machine certificate.
Is EKU filtering invalid for device tunnels?
PS U:\> Set-VpnAuthProtocol -CertificateEKUsToAccept “AlwaysOnVPN”,” AlwaysOnVPN – DeviceTunnel”
WARNING: Configuration parameters will be modified after the Remote Access service is restarted.
WARNING: Machine Certificate EKU filter AlwaysOnVPN is invalid
WARNING: Machine Certificate EKU filter AlwaysOnVPN – DeviceTunnel is invalid
Richard M. Hicks
/ May 14, 2021You must use the OID of the EKU, not the friendly name. Should work then. 🙂
Panos83
/ May 25, 2021Hello, i face a strange issue. When the users are working from home they can connect and stay connected. When they are working through office premises we get some random disconnects and the user moves from WiFi to Ethernet and vice versa to quickly solve the issue. What could be the problem? Always on Device Tunnel! Thank you in advance
Richard M. Hicks
/ May 27, 2021Could be any number of things. You might want to try reducing the IKE Mobility timeout value or disabling it altogether.
Panos83
/ May 27, 2021an event 828 also for the termination can explain something?Is there any settings to disable mobike just for testing?
Richard M. Hicks
/ May 27, 2021Yes, you can disable IKE mobility on the endpoint itself by looking at advanced security properties on the VPN connection itself. You can change the outage time or simply disable it completely.
Methio
/ May 27, 2021Thanks for the detailed explanation on this topic. I have implemented Device Tunnel based Always on VPN, with customer requests. One thing I could not figure out is, how to add multiple routes to the tunnel so that users can reach multiple networks/subnets in the company. They are only able to reach the subnet where the device tunnel belongs to for now. Also the configuration is with Split-Tunnel enabled. Customer want to run only Device Tunnel, and requested not to add User Tunnel in the configurations. Appreciate your help, thanks.
Richard M. Hicks
/ May 27, 2021You can add multiple routes in the Microsoft Endpoint Manager UI, or if you are using custom XML you simply add multiple Route statements in your XML.
Methio
/ May 27, 2021I was using custom XML, and thought the “Route” is for host routes with /32, is it possible to add something like 192.168.20.0</Address and 24 in the XML file, I only saw /32 on PrefixSize. Just confirming, thanks
Richard M. Hicks
/ May 28, 2021You can specify any prefix size you like. The examples here use /32, as using host routes for the device tunnel is recommended. That doesn’t prevent you from using something else if you want, though. 🙂
pun84
/ June 21, 2021Richard,
How do you control device tunnel access? It appears that you cannot utilize NPS firewall policies in device tunnel mode like one can with user tunnels.
Richard M. Hicks
/ June 21, 2021The quickest/easiest way is to use routing. For example, instead of routing the entire internal network over the device tunnel, simply add host routes to individual hosts as required. Commonly this would be domain controllers, but it could also be any infrastructure services that you’d want the device to connect to without a user logged on.
pun84
/ June 24, 2021Hi Richard,
I already allow access via single hosts in the routing table, I realized it would be a security risk if someone was able to just add routes without some other restriction in place. I suppose its still secure since they would need administrative privileges to add additional routes.
It just seemed a bit strange that user tunnel could work with NPS firewall while device tunnel does not.
Thanks,
Richard M. Hicks
/ June 24, 2021“Secure” here is subjective, of course. 😉 Indeed, using routes to limit traffic isn’t the best option. Using traffic filters would be a better choice, but they are difficult to manage. Also, until recently, enabling traffic filters broke outbound management, so many organizations couldn’t accept that trade-off. You’re right though if someone can add routes on your endpoint, you’re already in trouble. If you’re looking for something more positive, have a look at traffic filters. They now support inbound and outbound rules so you can enable manage out with them.
pun84
/ July 5, 2021Hi Richard,
It wouldn’t let me respond to the other comment, so ill use this one. You mentioned traffic filters, I assume you are talking about the client side filters that can be applied in the profile XML. Do you think I can just apply windows firewall rules on the RRAS server using the client ip pool as the local address range?
Thanks,
Richard M. Hicks
/ July 6, 2021Correct. You can certainly try using configuring rules on the Windows firewall on the RRAS server to see if that works. I don’t see why it wouldn’t. 🙂
RB
/ June 28, 2021Anyone found documentation on how to specify IPv6 routes in the ProfileXML?
Richard M. Hicks
/ July 6, 2021Absolutely. I recently update my sample XML files here.
https://github.com/richardhicks/aovpn/blob/master/ProfileXML_User.xml
https://github.com/richardhicks/aovpn/blob/master/ProfileXML_Device.xml
Enjoy!
pun84
/ July 14, 2021Hi Richard,
How do you handle the fact that device tunnel doesn’t support SSTP? We have about a 1/4 of our user working on SSTP currently while on user tunnel. If we deploy device tunnel to them I assume we will lose them as potential connected users.
I have looked into a few things to try and remedy the issue but so far we’ve been classifying it as an endpoint ISP issue
Thanks,
Richard M. Hicks
/ July 15, 2021Since the device tunnel only supports IKEv2, you just have to accept the limitations associated with it. Not much else you can do, really. That said, the device tunnel is only required in very specific scenarios. More often than not, if the device tunnel isn’t working, it doesn’t affect users much at all if the user tunnel is configured to use SSTP. Where you users might feel the pain is if they are trying to log on without cached credentials, such as when they have been given a new device and need to log on to the domain the first time remotely, or when they have changed their password. Other than that, the device tunnel isn’t really important.
Brandon
/ August 23, 2021If we wanted to have the device tunnel use NPS, for example to force the computer to also be a member of a group to allow connection instead of just the certificate, would that be possible?
Say for example a users laptop is stolen, what’s the best way to prevent that system from connecting to the network using device tunnel?
(Or is certificate revocation the only way to control/prevent access of a lost device?)
Richard M. Hicks
/ August 24, 2021Unfortunately, no. The Always On VPN device tunnel only supports device certificate authentication. You can’t configure it to use EAP/PEAP. The most effective way to prevent a device from connecting immediately is to place its certificate in the “untrusted certificates” store on each VPN server. I would still suggest revoking the certificate and issuing a new CRL just for good measure, though. See the following post for more details.
https://directaccess.richardhicks.com/2019/04/22/denying-access-to-always-on-vpn-users-or-computers/
Brandon
/ August 31, 2021Thank you very much!
Richard Gibbons
/ November 5, 2021Hi Richard
I am currently facing an issue where by we have a device and user tunnel connected however this seems to affect traffic and ping requests become timed out.
If i just have the device tunnel connected all seems fine but as soon as i connect the user tunnel the same happens.
I know tunnel co-existence is supported but this seems to be an issue.
Many Thanks
Richard
Richard M. Hicks
/ November 5, 2021Are you using split tunneling for both tunnels?
Richard Gibbons
/ November 8, 2021Yes we are using split tunneling for both.
Richard M. Hicks
/ November 8, 2021That’s strange. If you run Test-NetConnection -Port 445 to an on-premises server when this happens, do you see the traffic using the correct VPN interface?
Michael Dees
/ February 8, 2022You have to use split tunneling on both for this to work?
Richard M. Hicks
/ February 9, 2022You must use split tunneling on the device tunnel as force tunnel for the device tunnel isn’t supported. However, you can use force tunnel with the user tunnel when the device tunnel is configured with split tunnel, no problem.
Michael Dees
/ February 8, 2022I’m having issues connecting the user tunnel if the device tunnel is up. Sometimes it connects, but then drops. Anyone else having this issue?
Richard M. Hicks
/ February 9, 2022What is the error message you are receiving? Also, what VPN protocol are you using for the user tunnel?
David
/ July 7, 2022Hi Richard,
Thanks for the great article.
If I am using device tunnel and user tunnel connecting via the same RRAS, how do I limit the access of the device tunnel to only domain authentication? do I need to have a different IP address allocation pool for the device and user tunnel, and if so how would that be done? or is the only way to limit device tunnels is via traffic rules?
Richard M. Hicks
/ July 8, 2022Typically this is done using host routes, traffic filters, or a combination of the two. If you want to control access by restricting access using an internal firewall, then you’ll need to configure a separate server (and separate public hostname) to point device tunnel connections to that server. You can then create firewall rules to restrict traffic accordingly.
Evgeniy
/ December 22, 2022Hi, Richard!
Thank you for the article, we’ve got Always On configuration, that works great except one thing.
For security reasons, we are forced to use RODC for remote devices that connect with Always On configuration.
Whenever a user changes their domain password not locally with Ctrl-Alt-Delete (on other domain computer, or in RDS terminal session, or in Office 365 web-form), after reboot user certificate can’t be validated no more resulting in user tunnel connect being impossible.
Boh device and user tunnels provide access to RODC, CA-server and DNS servers (as they are separate, not on DC). User tunnel provides access to corporate proxy server as well.
In a testing environment with WDC the issue doesn’t occur.
We’ve seen the same case on reddit and MS learn portal, but with Windows 11 only. We use Windows 10.
Richard M. Hicks
/ December 22, 2022That’s interesting. It would appear that access to a writeable DC is required when using client authentication certificates. I’m not sure why, though, but based on your experience this seems to be the case.
RCMI23
/ April 10, 2023Thanks for this guide, very helpful!
I was curious if there was any further information that came up regarding the need for a writeable DC (see Evgeniy comment), as opposed to a RODC, and “the why” this might be necessary.
Richard M. Hicks
/ April 10, 2023Not to my knowledge. Password changes always require access to writeable domain controllers. As such, a writeable DC must be reachable over the device tunnel for the password change to take effect. To be clear, a writeable DC is not required for anything else. So, if you want to restrict device tunnel access to RODCs, everything will work except user-initiated password changes.
Alex
/ September 29, 2023Hi, after upgrading (clean installation) to windows 11 im facing an issue. We use device (split tunnel of course) and user tunnel (force tunnel). Both connects fine after windows starts. The mertics are as expected. for user tunnel we have 4 to have a higher prio over ipv6 (5) and the device tunnel metric changes from 3 to 4215 or something after connection. But i dont have access to internal oder external resources.
After researches i tried to disconnect the device tunnel and redial the user tunnel and everything works fine, then deinstalled the device tunnel, restarted and everything is fine, too.
It looks like my windows tries to send the traffic only through the device tunnel but its limited to ces/cep services etc.
i have no clue how to correct this, thought its enough to set the correct metrics. Anyone else facing this issue?
For all of our win 11 testers, this happens. Whats the difference to win 10?
Richard M. Hicks
/ September 29, 2023Thats quite unusual. I’ve never seen the device tunnel interface metric set that high automatically. My recommendation is to manually assign the interface metric to both device and user tunnels. I usually set them to ‘3’ for both. You can do that by editing the following settings in rasphone.pbk.
IpInterfaceMetric=3
Ipv6InterfaceMetric=3
I’ve also published a script to help automate this here: https://github.com/richardhicks/aovpn/blob/master/Update-Rasphone.ps1.
In addition, you will find detection and remediation scripts for Intune here: https://github.com/richardhicks/endpointmanager.
Hope that helps!
Alex
/ October 1, 2023Hi, thank you for your fast reply. I thought it works as designed after the user (force) tunnel connects, the device tunnel gets a high metric automatic.
Since we implemented this, 2 years ago, always the device tunnel metric changes to 4xxx when the use tunnel is connected.
I changed both metrics to 3 but unfortunately the connections stays as before, connected but without access to internal/external resources.
The second behavior what comes with my issue: The login procedure is very long. It stays at “waiting for ProfSvc” for like 90 seconds (timeout?) and then starts windows.
Maybe there are missing firewallshares, necessary in windows 11 or a missing route for the device tunnel?!
Today i have a second meeting with my microsoft support, i hope he has some helpful information for me.
Richard M. Hicks
/ October 2, 2023Not sure what’s up there, to be honest. As for the log on delays, those are most commonly caused by lack of network access to resources required during the logon. Running a network trace and/or using procmon.exe should yield some clues as to what’s causing the slowness.
Guillaume Blain
/ November 6, 2023I have a similar issue only with Windows 11. We have both device and user tunnel installed. We notice, randomely, we are not able to reach the admin share “\\xyz\c$”. Metric have been set to priorize user tunnel over device tunnel. the only way to reach the device is to use the ip address of the device tunnel. It’s not the same issue but could be related.
Richard M. Hicks
/ November 6, 2023If you can reach the device tunnel via IP address but not hostname, that sounds more like a name resolution issue. Endpoints not registering their device tunnel IP address, perhaps?
gblainc69ab8acb5
/ November 6, 2023Only User tunnel ip address is registered in the DNS. Also, i notice, if the user tunnel connected before the device tunnel, i’m able to reach admin share. If the device tunnel is connected before the user tunnel, i’m not able to reach it. It happen only with Windows 11 clients. Windows 10 admin share are reachable.
Richard M. Hicks
/ November 7, 2023Wow, that is odd. It might be worth having a look at the firewall logs on the endpoint to see if anything is being dropped.
gblainc69ab8acb5
/ November 7, 2023Hi Richard, thanks for the hint on the firewall. We discovered that the traffic pass trought the public profile of the windows firewall instead of domain profile and was block. We found that a win11 august fix (KB5029263) was causing an issue with the firewall. Microsoft release a KB last week to fix that issue (KB5031455) and it is suppose to be in the Nov 2023 rollup. After installing the KB5031455, we are able to reach the admin share. We will monitor it for the next few days but we are positive.
here is some reading regarding the issue:
https://techcommunity.microsoft.com/t5/windows-11/kb5029263-broke-windows-firewall-on-windows-11/m-p/3915922
https://www.reddit.com/r/sysadmin/comments/16asavs/windows_firewall_using_public_instead_of_domain/
Thanks again for your help 🙂
Guillaume
Richard M. Hicks
/ November 7, 2023Ok, good to know. Thanks for the reference links!
Evgeniy
/ November 19, 2023Hello, Richard and community!
We’re experiencing an issue with the AD policies failures on VPN tunnel change from Management to User.
Is there any way to halt UserTunnel connection to let all the policies to apply?
Thank you
Richard M. Hicks
/ November 20, 2023Not to my knowledge. :/