Recently I wrote about Windows Always On VPN device tunnel operation and best practices, explaining its common uses cases and requirements, as well as sharing some detailed information about authentication, deployment recommendations, and best practices. I’m commonly asked if deploying Always On VPN using the device tunnel exclusively, as opposed to using it to supplement the user tunnel, is supported or recommended. I’ll address those topics in detail here.
Device Tunnel Only?
To start, yes, it is possible to deploy Windows Always On VPN using only the device tunnel. In this scenario the administrator will configure full access to the network instead of limited access to domain infrastructure services and management servers.
Is It Recommended?
Generally, no. Remember, the device tunnel was designed with a specific purpose in mind, that being to provide pre-logon network connectivity to support scenarios such as logging on without cached credentials. Typically, the device tunnel is best used for its intended purpose, which is providing supplemental functionality to the user tunnel.
Deployment Considerations
The choice to implement Always On VPN using only the device tunnel is an interesting one. There are some potential advantages to this deployment model, but it is not without some serious limitations. Below I’ve listed some of the advantages and disadvantages to deploying the device tunnel alone for Windows 10 Always On VPN.
Advantages
Using the device tunnel alone does have some compelling advantages over the standard two tunnel (device tunnel/user tunnel) deployment model. Consider the following.
- Single VPN Connection – Deploying the device tunnel alone means a single VPN connection to configure, deploy, and manage on the client. This also results in less concurrent connections and, importantly, less IP addresses to allocate and provision.
- Reduced Infrastructure – The device tunnel is authenticated using only the device certificate. This certificate check is performed directly on the Windows Server Routing and Remote Access Service (RRAS) VPN server, eliminating the requirement to deploy Network Policy Server (NPS) servers for authentication.
- User Transparency – The device tunnel does not appear in the modern Windows UI. The user will not see this connection if they click on the network icon in the notification area. In addition, they will not see the device tunnel connection in the settings app under Network & Internet > VPN. This prevents casual users from playing with the connection settings, and potentially deleting the connection entirely. It’s not that they can’t delete the device tunnel however, it’s just not as obvious.
- Simplified Deployment – Deploying the device tunnel is less complicated than deploying the user tunnel. The device tunnel is provisioned once to the device and available to all users. This eliminates the complexity of having to deploy the user tunnel in each individual user’s profile.
Disadvantages
While there are some advantages to using the device tunnel by itself, this configuration is not without some serious limitations. Consider the following.
- IKEv2 Only – The device tunnel uses the IKEv2 VPN protocol exclusively. It does not support SSTP. While IKEv2 is an excellent protocol in terms of security, it is commonly blocked by firewalls. This will prevent some users from accessing the network remotely depending on their location.
- Limited OS Support – The device tunnel is only supported on Windows Enterprise edition clients, and those clients must be joined to a domain. Arguably the device tunnel wouldn’t be necessary if the client isn’t domain joined, but some organizations have widely deployed Windows Professional, which would preclude them from being able to use the device tunnel.
- Machine Certificate Authentication Only – The device tunnel is authenticated using only the certificate issued to the device. This means anyone who logs on to the device will have full access to the internal network. This may or may not be desirable, depending on individual requirements.
- No Mutual Authentication – When the device tunnel is authenticated, the server performs authentication of the client, but the client does not authenticate the server. The lack of mutual authentication increases the risk of a man-in-the-middle attack.
- CRL Checks Not Enforced – By default, RRAS does not perform certificate revocation checking for device tunnel connections. This means simply revoking a certificate won’t prevent the device from connecting. You’ll have to import the client’s device certificate into the Untrusted Certificates certificate store on each VPN server. Fortunately, there is a fix available to address this limitation, but it involves some additional configuration. See Always On VPN Device Tunnel and Certificate Revocation for more details.
- No Support for Azure Conditional Access – Azure Conditional Access requires EAP authentication. However, the device tunnel does not use EAP but instead uses a simple device certificate check to authenticate the device.
- No Support for Multifactor Authentication – As the device tunnel is authenticated by the RRAS VPN server directly and authentication requests are not sent to the NPS server, it is not possible to integrate MFA with the device tunnel.
- Limited Connection Visibility – Since the device tunnel is designed for the device and not the user it does not appear in the list of active network connections in the Windows UI. There is no user-friendly connection status indicator, although the connection can be viewed using the classic network control panel applet (ncpa.cpl).
Summary
The choice to deploy Windows Always On VPN using the device tunnel alone, or in conjunction with the user tunnel, is a design choice that administrators must make based on their individual requirements. Using the device tunnel alone is supported and works but has some serious drawbacks and limitations. The best experience will be found using the device tunnel as it was intended, as an optional component to provide pre-logon connectivity for an existing Always On VPN user tunnel.
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
victor bassey
/ April 6, 2020Great summary of the advantages/disadvantages of deploying device tunnel only. What is the general observation recently, is deploying both tunnels together now stable (i.e deploying both user and device tunnels)
Richard M. Hicks
/ April 6, 2020Always On VPN device tunnel/user tunnel coexistence has been pretty solid since the release of Windows 10 1809. However, my experience with 1909 has been rock solid all the way around. Definitely quite reliable these days. 🙂
Some Guy
/ April 6, 2020Not so sure about “No Mutual Authentication”. Can you expand on that one? My experience has been that IKEv2 connection attempt will most definitely fail if the server certificate doesn’t check out. That would mean the client is indeed verifying the server certificate. Are you talking about something else?
Richard M. Hicks
/ April 6, 2020To some extent, yes, but it’s pretty weak compared to using EAP. Indeed the client checks the server’s certificate, but it doesn’t necessarily know that it is the correct server. It only knows that the certificate name matched and it was issued by A CA that it trusted. By contrast, the user tunnel configured with EAP allows the administrator to define the specific CA that issued the certificate.
victor bassey
/ April 13, 2020A client of mine is insisting on using forced tunnel for both device and user tunnel. A quick test shows the user tunnel was not connecting as client couldn’t reach the external vpn gateway hostname when device tunnel is connected. I was thinking of adding the vpn gateway hostname into internal dns, but then adds more complexity for load-balancing and clients trying to connect when on local lan…. any tips on getting both tunnel deployed as forced?
Richard M. Hicks
/ April 14, 2020Yes, don’t use force tunneling on the device tunnel. 🙂 Seriously though, there’s no real point in using force tunneling on the device tunnel. If you absolutely must do this, then you’ll have to configure the user tunnel FQDN in internal DNS. Optionally you could use a different namespace for both tunnels. Regardless, you’ll also have to configure an exclusion route for the user tunnel IP address on the device tunnel.
LanDI
/ April 29, 2020Richard I can get device tunnel up and runing but have bever got user tunnel to work.
been over the certs and teh settign/policies a thousand times.
in the NPS log i always get arejection error code 7
7 = IAS_NO_SUCH_DOMAIN ?
any thoughts/ideas?
Richard M. Hicks
/ April 29, 2020Not sure, but look closely at the user certificate template. Make sure the subject is the Fully Distinguished Name and that the UPN is in the Subject Alternative Name list. I’d suggest not using email anywhere on the template as well.
David
/ May 4, 2020Richard – your blogs are great and have been a huge help to me. We’re moving from DA to AOVPN and we have one sticking point and thought maybe you’d be able to shed some light on it or at least confirm my suspicions. Our devices are hybrid joined, we have user and device tunnel setup and working properly. When we use the intune issued VPN certificate the device can authenticate to file shares and internal resources but not to local SQL and we receive an error on the domain controller that it cannot validate the CRL and the certificate is rejected. My suspicion is that Azure AD (AAD) is passing the login credential for the local file share, but local SQL isn’t supported by AAD for pass through authentication. Any thoughts or advice? Is there a way to ignore CRL for that particular root CA, as those certs are issued for such as short time anyway or would that not be recommended?
Richard M. Hicks
/ May 5, 2020Are you using Azure conditional access? Or is the Intune issued certificate from SCEP or PFX connector?
David
/ May 10, 2020Azure conditional access, the certificate is issued by Azure VPN.
David
/ May 10, 2020I should have been more clear, this is the certificate I’m referring to.
https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/ad-ca-vpn-connectivity-windows10
Richard M. Hicks
/ May 14, 2020Guidance for disabling CRL checking for Azure AD conditional certificates can be found here: https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/vpn-config-eap-tls-to-ignore-crl-checking.
David Boos
/ May 20, 2020I disabled CRL checking on the NPS and Alwayson servers, this is the error on the domain controller.
The client certificate for the user AD\USERNAME is not valid, and resulted in a failed smartcard logon. Please contact the user for more information about the certificate they’re attempting to use for smartcard logon. The chain status was : The revocation function was unable to check revocation for the certificate.
Richard M. Hicks
/ May 21, 2020That’s unusual. The Azure certificate should not be presented for authentication to on-premises resources, only VPN access. Did you not configure SSO using an on-premises issued user certificate then?
David Boos
/ May 21, 2020I might be missing something there so here’s what the client has –
1. Certificate issued to the user by internal CA as a client authentication certificate.
2. Certificate issued by Microsoft VPN root for IKE/client authentication.
3. Certificate issued to the machine by internal CA for client authentication certificate.
How would I specify authentication should take place via the internal CA client auth certificate instead of the Microsoft VPN certificate?
Richard M. Hicks
/ May 22, 2020With Azure CA configured, the certificate issued by Azure is used to authenticate to the VPN server. However, to authenticate against internal resources you need to configure SSO in ProfileXML. It is in the DeviceCompliance element. There you’ll define the user certificate to be used when authenticating to internal resources, which will be the user certificate issued by your internal PKI. Let me know if you need a code sample and I can provide one.
David Boos
/ May 23, 2020If you have a code sample that would be awesome.
Thank you, I really appreciate your help on this. I had tested it using an internal CA certificate and everything worked, switched to Azure CA and then it quit. I knew I was missing something, thank you again for pointing it out.
Richard M. Hicks
/ May 25, 2020You can enable device compliance using Intune UI natively, or if you are using custom ProfileXML you can add the following to your code (angle brackets replaced because WordPress strips them out!).
[DeviceCompliance]
[Enabled]true[/Enabled]
[Sso]
[Enabled]true[/Enabled]
[Eku]1.3.6.1.5.5.7.3.2[/Eku]
[IssuerHash]05A2C3F46A95B172300347840B8144685B0F2284[/IssuerHash]
[/Sso]
[/DeviceCompliance]
The IssuerHash is the certificate thumbprint of your root CA certificate. The EKU is the OID for Client Authentication. There’s still more to configure though. You must also publish the Azure AD certificate in Active Directory and you also have to disable CRL checking on the NPS server. Here are two good articles for reference.
https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/ad-ca-vpn-connectivity-windows10
https://docs.microsoft.com/en-us/windows/security/identity-protection/vpn/vpn-conditional-access
David Boos
/ May 26, 2020Thank you – that is extremely helpful. I’ll post back when I have this working properly.
David Boos
/ June 8, 2020That fixed it for me, thanks for pointing me in the right direction.
Phil
/ May 6, 2020Hi Richard,
I have this exact setup (device based AOVPN tunnel using IKEv2 machine certs, to an Azure AOVPN GW) in place for a customer at present – and the VPN connection is visible in the notification area network connection pop up.
Client config is being deployed using the inbuilt Intune VPN client profile. I’m going to be experimenting with pushing a custom XML to try and resolve a weird windows client side routing issue (class based nonsense I suspect) – will report in if its different in that context.
Richard M. Hicks
/ May 6, 2020If you are pushing out the profile using the native Intune UI and not custom XML, then it isn’t a device tunnel. The only option for deploying the device tunnel using Intune at the moment is custom XML. Also, by default, you would not see the device tunnel connection in the Windows UI via the notification area. 🙂
grahampriley
/ May 27, 2020Hi Richard,
Can you think of any reasons why a Device Tunnel VPN wouldn’t work from a Workgroup PC?
We are testing Device Tunnel from Domain-joined 1909 (Education) Laptops’s and thankfully the VPN appears to be very stable however we are having trouble with being able to logon to the domain.
In troubleshooting we have dropped the Laptop off the domain with the plan to re-join the domain but now it is in a workgroup the VPN never connects. We are only using Device Tunnel – there are no NPS servers in the mix. The client still has all the required certs but it just never connects. As said, when it was domained it connected fine.
Regards,
Graham
Richard M. Hicks
/ May 27, 2020Yes. The device tunnel is only supported on domain-joined devices. 🙂
grahampriley
/ May 27, 2020Ah I found your other article https://directaccess.richardhicks.com/2019/03/14/always-on-vpn-device-tunnel-does-not-connect-automatically/
Why didn’t I read that before dropping off the domain damn it!!
Richard M. Hicks
/ May 27, 2020😉
Damian Murray
/ June 9, 2020Hi Richard,
we were in the process of testing AOVPN before we went into lockdown. We noticed that login time was greatly increased with a Device Tunnel – assuming this is due to the device being able to communicate with the on-premise domain controllers. We started to test with just a User Tunnel configured so users were logging in with cached credentials and so login time was improved.
I am aware of some of the downsides to this (user will have to logon at least once while joined to the network, no unattended management) – what would your opinion be of deploying just a User Tunnel? I hadn’t thought about it (until asked) but I guess that machine based Group Policy would also not be processed?
Thanks
Damian
Richard M. Hicks
/ June 9, 2020The user tunnel only option is quite common. In fact, we only recommend deploying the device tunnel when it is actually required. If users must log on without cached credentials, then the device tunnel is required. If not, user tunnel only is perfectly acceptable. 🙂
Damian Murray
/ June 9, 2020Thanks for the reply 😁
What about machine group policy etc?
Richard M. Hicks
/ June 9, 2020I believe that machine-based group policies are still processed. I’m not certain about that though. Might have to do some testing to confirm.
Fernando Leiva
/ June 17, 2020Hi Richard, thanks so much for your amazing blog.
We use device tunnel and user SSTP for when IKEv2 is blocked. SSTP is a manual connection. We’ve noticed that once in a while devices are successfully connected to the device tunnel, however they cannot access any internal resources, other than DNS servers. The device tunnel status shows only connection to the internal DNS servers, and of course, event logs aren’t helpful at all. A reboot of the client usually fixes this. Do you have any insight as to what could be causing this?
Richard M. Hicks
/ June 18, 2020No idea to be honest. I’ve encountered this myself on occasion. Like you’ve I’ve just rebooted and things work after that.
Mahesh
/ July 3, 2020Very interesting about Device tunnel.
It will be great if you can share some details about
1. How does the firewall port requirement looks like? What all ports to be opened for device and user tunnel.
2.How about client IP address planning? if user is connected through user tunnel and device is already connected over device tunnel, does this scenario will have two IP address consumed …one for user and other for device?
3.While device is getting authenticated at VPN server using certificate, why it needs to be domain joined? Where does the domain join verification is done?
Appreciate if you can help with details for these points and really helps
Richard M. Hicks
/ July 7, 2020Inbound UDP ports 500 and 4500 are required for IKEv2. The device tunnel is a separate connection and will consume an additional IP address. Plan accordingly. Domain-join requirement is a licensing requirement, not a technical one. You can only configure the device tunnel when the client is joined to the domain. It will still work if not domain-joined, but it won’t start automatically.
@MaheshSA78 (@MaheshSA78)
/ July 4, 2020Hi Richard,
Thanks for such a nice article, these are really helpful.
Couple of points disturbing me a lot, it will be great if you can help
1. If Domain membership is mandatory for Device tunnel, what is the check point to ensure domain join? I mean how does the validity of domain join is checked?
2.Is it possible to configure both user tunnel and device tunnel using same VPN/RRAS Servers?
3.For VPN Clients IP allocation, its difficult to get single subnet with thousands of IPs. Can we have multiple subnet/different range if IP subnet for VPN client while internal NIC of RRAS Server is in different Subnet than the VPN client IP scope? If yes please suggest some insight.
Regards
Mahesh
Richard M. Hicks
/ July 7, 2020There is no validation of the device’s computer account at all. The requirement for domain-join is a licensing one. The device tunnel will only automatically connect on domain-joined devices. If you deploy the device tunnel to a non-domain joined device it won’t connect automatically, but will manually. It is recommended that each VPN server assign clients with a unique subnet. You can use multiple subnets per server as long as you configure internal routing accordingly.
Mike
/ August 12, 2020Hi Richard, little confusion and I was wondering if you can shed some light on this type of scenario.
What would be the best approach for shared devices.. i.e tablets for outside workers.
So for example:
– 200 workers who share 50-100 tablets
– many of the users may have never signed into some of these devices
– on any given day they can just grab a tablet that been sitting there and
head out to the worksite.
My worry is how will some of these users have a VPN profile if they have never logged into the device and now are out in the field.
My approach on this was just to use device tunnels and not have to worry about user tunnels. Thoughts? better approach?
I understand some of the security concerns in your article that’s why these RAS servers are on an isolated VLAN by themselves between firewalls.
Richard M. Hicks
/ August 13, 2020Given your requirements I’d say that implementing a device tunnel only would be acceptable. The goal of this post was to consider some of the limitations of using the device tunnel only. However, there are some uses cases where it makes sense, and it sounds like that’s the case here. As long as you can accept the risks/limitations of using the device tunnel only I think it should work just fine for you. 🙂
Rob
/ August 13, 2020Hello,
I’m testing with a Device and User tunnel.
I would like the device tunnel on boot and then the user once I’m logged in.
I’ve been having various issues with 1809 and 2004 but my real question is should both tunnels stay up at the same time or should the device drop once the user is up?
MS stated they should both stay up (while on a call with them on something else) but I’m just wondering what other peoples experiences are?
Richard M. Hicks
/ August 13, 2020Correct. The device tunnel and user tunnel are two separate and distinct connections and they should both stay up at the same time. Others have tried custom solutions to programmatically trigger the device tunnel and disable it after user logon, but that’s not something I’d recommend.
Simon Erichstrup (@QErichstrup)
/ January 8, 2021Hi Rog and Richard,
In this case we would end up with two IP adresses on the Client VPN subnet correct?
How is it avoided running into asynchronous routing to/from the client?
I have a testing scenario where i have a device tunnel connection with /32 routing specifically to two DCs only.
Then secondly I have a
RoutingPolicyType:ForceTunnel
NativeProtocolType:IKEv2
MachineMethod:Certificate
alwayson tunnel running.
(Basically identical to the DeviceTunnel, but with ForceTunnel and I have asked about MS support for this option elsewhere.
So no User Certificate and all traffic routed through VPN.
I could make the Device Tunnel do this also and skip the second part, but I gather any malicious user gaining access to this workstation would then have a rather large attack surface at his hands.
Thoughts?
BTW Thank you for your willingness to share your knowledge on this product. It is hugely appreciated.
Kind regards,
Simon
Richard M. Hicks
/ January 9, 2021You shouldn’t have any issues with routing. Each interface has its own IP address, so traffic sourced from that interface will be returned accordingly. Having both device tunnel and user tunnel on the same VPN client subnet is quite common in fact.
Ron
/ August 20, 2020reg add HKLM\SOFTWARE\Microsoft\Flyout\VPN /f /v ShowDeviceTunnelInUI /t REG_DWORD /d “1”
Adds the device tunnel status to the top of the available network connections, simple, easy to deploy via SCCM or GPO and best of all it works. Sadly this key does not work for visibility in the pre-logon screen
Richard M. Hicks
/ August 27, 2020You also can’t disconnect the Always On VPN device tunnel by clicking on the “disconnect” button. At least you can see the connection status without having to dig for it.
FYI, I’ve documented this tip using PowerShell here: https://directaccess.richardhicks.com/2020/08/27/always-on-vpn-device-tunnel-status-indicator/.
Simon Quist Erichstrup
/ January 8, 2021Hi Richard,
I understand that Device Tunnel does not support splittunnel, but I have a scenario where device tunneling AND force tunneling is requested.
It seems I am able to define Force Tunnel and a route print indicates it works.
Do you have any knowledge as to why it is not supported?
Richard M. Hicks
/ January 9, 2021The device tunnel does not support “force tunnel”, that’s correct. However, there isn’t anything stopping you from doing this. “Not supported” and “doesn’t work” are two different things for sure. 😉 That said, Microsoft must have some reason not to support it. I suspect there are some unintended consequences that could be problematic if you enable force tunnel on the device tunnel.
Simon Quist Erichstrup
/ January 11, 2021Hi Richard,
Thank you for your reply.
I bet they do 🙂
I will try and ascertain as to why directly with MS.
Wish me luck 😉
Rory (@outofmyelement)
/ February 8, 2021If i have hybrid ad-joined laptops that typically log in to local AD when in office, why wouldn’t I simply just use device tunnel when they are off network to behave as if they were in office but remote? I don’t understand why I would use a user tunnel on top of the device tunnel when its already functioning completely fine over the device tunnel. It just adds duplicate tunnels and double ip, mixed registered DNS for management.
Also, even though the device tunnel is authenticated by certificate, the user is still required to log in with valid AD credentials to use the system so its not like they can access the network without valid credentials on top of the certificates. I’m only doing this on corporate laptops, not peoples personal computers.
I’m looking to move from Fortigate client with pre-login VPN to MS always on vpn over IKEv2 but this post and others make it very confusing. Am on on the right track but getting confused by all the details or am I not understanding something?
Its easy to do the config and deployment but it just doesn’t make sense when I read how its intended to work etc. Should I just set it up, use it and not care about how you are supposed to use it?
Thanks
Richard M. Hicks
/ February 10, 2021To be clear, you *can* deploy the device tunnel alone and it will work. However, as I outlined in this post, there are some drawbacks that require consideration. However, if you are will to accept some of the limitations that a device tunnel only solution brings, then there’s no problem deploying it. 🙂
Simon Quist Erichstrup
/ February 10, 2021Hi Rory,
I understand your confusion.
The short, short answer is:
Because Microsoft does not support using SSTP (either as initial or as fallback) for use with Device Tunnelling.
What you WILL encounter using IKE/IPsec is that some ISPs block these UDP packets.
Most often you will see the Device Tunnel come up on the VPN server, but the client end times out and reports error code 809.
I have a case scenario from just this week.
An ISP had downtime due to overload because we had much snow falling and more people worked at home than usual.
Due to covid19 many people and students work online here in Denmark and the strain on their systems proved too much.
Quick fix from their end rather than scaling hardware up, was to drop some traffic. Apparently they decided to scrub VPN traffic.
This is why it is prudent (I would argue necessary) to also establish an user tunnel that runs SSTP.
Some Guy
/ February 11, 2021Rory, yes you are right, user tunnel is dumb and pointless. The whole concept is very half-baked.
If you are dealing with managed endpoints and simply want the experience of being “always on” the network, introducing user into the equation makes no sense. An endpoint that is always on the network should be always on the network regardless of who’s around.
It feels like Microsoft designed the whole thing around user tunnels, then realized at the last moment that user tunnels don’t actually provide the “always on” experience, so they hacked together an *actual* always-on connection – the machine tunnel – as a quick fix to their design error. The only real reason to use user tunnel is if you want features they never bothered to implement for machine tunnel (e.g. SSTP) or to feel like a MS fanboy. 😉
Richard M. Hicks
/ February 15, 2021Indeed, the device tunnel was an afterthought. The decision to deploy VPN tunnels per-user was a Microsoft design choice, ostensibly because they wanted to provide users with access regardless of device (managed or not).
MrMusic
/ December 2, 2021Several months ago deployed AOVPN in device tunnel only, the result has been mixed, stability being the biggest issue for a variety of reasons.. Likely going to try user tunnel so that conditional access is possible but also SSTP protocol.
I agree that the whole user tunnel thing is just weird design from MS, add the functionality for ACAP and SSTP to the device tunnel in some manner and be done with it.
Matthias
/ June 24, 2021A bit frustrating on this
– Deploying Device Tunnel to archive “online logon” capabilities we route
DNS Servers
DCs
Fileserver (drive maps in gpp)
DFS Server
WSUS
Management Server
What doesnt work
– User Tunnel -.- (with and without trustednetworkdetection)
– Drive mapping 🙂
-> but we can reach the drives through unc, what the hec?
– Using Background placed in sysvol, still unc works
– Folder redirection to the fileservers (especially desktop)
Device Tunnel
https://pastebin.com/RPmLwLaB
User Tunnel
https://pastebin.com/vER4fLE0
any ideas? tried different styles on the device tunnel, route everything (0.0.0.0/0) leads basically to the same…dont geht it why
Richard M. Hicks
/ June 24, 2021Your device tunnel XML is missing the DnsSuffix information. Try adding that to see if things work better. As for the user tunnel not working, make sure you can resolve the public FQDN to the correct IP address. If it is resolving over the device tunnel, it may not resolve, or it may be resolving to the wrong address.
Hope that helps!
Matthias
/ June 25, 2021added, but changed nothing so far
But the resolveable external adress is a point to look at
User and Device Tunnel has the same fqdn to connect. But while i am connected (device OR user) we cant resolve the name cause our internal dns server responses to the dns request where we did not make an entry for the vpn server. So the first vpn tunnel which connects leads
We want to “work around” the “internalnetworkdetection” problem with this (internally not resolvable). Any advise for this?
Richard M. Hicks
/ June 26, 2021You have some options. You could add the public FQDN in your internal DNS so it resolves to the correct public IP, but if you’re trying to avoid using trusted network detection, then that won’t work. Another option might be using different FQDNs for the VPN tunnels, ideally in a separate namespace so they always resolve externally. You could also use the NRPT to ensure your public FQDNs always resolve externally too.
joshschmidt360281307
/ December 14, 2021Hi Richard,
We have a Device Tunnel AOVPN using Split Tunnel Policy set up and it works for most things but some of our internal services are not available for users that should be able to access them. These services are also available outside of the VPN but we haven’t been able to get the config right to route those services outside of the VPN. Thoughts?
Richard M. Hicks
/ December 15, 2021This is most likely a name resolution issue. Specifically, the DNS response from the external (public) interface is being preferred over the VPN interface. To solve this you’ll need to lower the interface metric of the VPN interface. I usually set it to ‘3’. You can do this temporarily for testing using Set-NetIpInterface. To make the change persistent you’ll need to update the InterfaceMetric setting in rasphone.pbk. I have a PowerShell script that allows you to do that here: https://github.com/richardhicks/aovpn/blob/master/Update-Rasphone.ps1.
Keith C.
/ December 21, 2021Device tunnel only requires a Windows Enterprise license on the client. But just to be certain, “standard two tunnel (device tunnel/user tunnel) deployment” requires a Windows 10 Enterprise license as well?
Richard M. Hicks
/ December 21, 2021Yes, the device tunnel will only work with Windows Enterprise Edition. The user tunnel will work with Enterprise Edition and Professional. If you want to do two-tunnel deployment with both device tunnel and user tunnel, then you must have Enterprise Edition to support the device tunnel.
Joe L
/ November 27, 2023Hello, we been using your script for deploying our device tunnel and worked amazing on windows 10. Last spring, we started to roll out windows 11 and noticed that only the user that was logged in (local admin) has the tunnel during the install.
Looking in the VPN Settings and installing the notiifcation status reg hack it doesn’t show up there. if we go to the admin account it does. If i am logged in with a domain account and then use SCCM’s script feature and push it again it will show up. this only happens on windows 11. Just wondering if you have heard or seen anything like this. We are running 22h2 and haven’t had a chance to test with 23h2 if this is still an issue.
Richard M. Hicks
/ November 27, 2023I’m not aware of any limitations with the device tunnel deployment on Windows 11. I’m curious though. Do you see the device tunnel if you run Get-VpnConnection? If not, do you see it when you run that command with the -AllUserConnection parameter?