When deploying Windows 10 Always On VPN, administrators can configure Trusted Network Detection (TND) which enables clients to detect when they are on the internal network. With this option set, the client will only automatically establish a VPN connection when it is outside the trusted network. Trusted network detection can be configured on both device tunnel and user tunnel connections.
TND Operation
When trusted network detection is configured, the VPN client will evaluate the DNS suffix assigned to all physical (non-virtual or tunnel) adapters that are active. If any of them match the administrator-defined trusted network setting, the client is determined to be on the internal network and the VPN connection will not connect. If the DNS suffix is not present on any of these adapters, the client is determined to be outside the internal network and the VPN connection will establish automatically.
TND Configuration
Trusted network detection is defined in the Intune UI or in ProfileXML as a string that matches the DNS suffix assigned to clients on the internal network. In this example, the DNS suffix on the internal network is lab.richardhicks.net.
Note: Your organization might have more than one DNS suffix. Ensure that the trusted network detection configuration includes all DNS suffixes in use in the environment to ensure reliable operation.
Intune
Follow the steps below to configured trusted network detection in Microsoft Intune.
- Open the Intune management portal (https://devicemanagement.microsoft.com/).
- Navigate to Devices > Configuration Profiles > [Profile Name] > Properties > Settings.
- Click on Trusted Network Detection.
- Enter the DNS suffix(es) used on the internal network.
ProfileXML
To define Trusted Network Detection in ProfileXML, add the TrustedNetworkDetection element as follows.
Caveats
In some instances, an Always On VPN client connection may persist, even if the client is connected to the internal network. A common scenario is when a client device connects to a Wi-Fi network that is not connected to the corporate network (for example guest Wi-Fi), then connects to the internal network with Ethernet via a docking station. If the Wi-Fi connection is still available, the Always On VPN connection will persist, even though the machine is connected to the internal network. This is expected and by design.
Workaround
To address this specific scenario, administrators can implement changes via group policy to the way Windows handles multiple connections to the same network. For example, beginning with Windows 10 1709, group policy can be configured to ensure that Windows 10 clients prefer wired Ethernet network connections over Wi-Fi, and to ensure that Wi-Fi connections disconnect when an Ethernet connection is detected.
GPO Configuration
Open the Group Policy management console (gpmc.msc) and perform the following steps to create the required group policy objects.
- Create a new Group Policy Object (GPO).
- Right-click the new GPO and choose Edit.
- Expand Computer Configuration > Administrative Templates > Network > Windows Connection Manager.
- Double-click the policy Minimize the number of simultaneous connections to the Internet or a Windows Domain.
- Select Enabled.
- From the Minimize Policy Options drop-down list choose 1 = Minimize simultaneous connections. Optionally you can choose to disable Wi-Fi whenever connected to Ethernet by choosing 3 = Prevent Wi-Fi when on Ethernet.
- Click Ok.
- Double-click the policy Enable Windows to soft-disconnect a computer from a network.
- Select Disabled.
- Click Ok.
trotterd
/ March 25, 2020Hi Richard, I hope you are well.
I have a scenario where we have a top level Active Directory Forest Root. For example:-
ad.company.co.uk
My users computers, RRAS VPN servers and NPS server is in a child domain called: –
staff.ad.company.co.uk
When I logon to a computer connected internally on the network, If I look at settings, and then Network Status, it shows the forest root of the domain, regardless of the computer being a member of the child domain staff.ad.company.co.uk.
I have configured the TrustedNetworkDetection parameter within the Device Tunnel Profile and the User Tunnel Profile to use the child domain of staff.ad.company.co.uk which seems to work, but reading your article is making me wonder if I should also include the forest root as a TrustedNetworkDetection in both profiles.
If adding two TND dns entries to the profiles, is it just a case of adding two lines one after each other.
Regards
Dave
Richard M. Hicks
/ March 26, 2020If you run ipconfig /all the second line below Windows IP Configuration will have a Primary DNS Suffx entry. That should be in your trusted network detection configuration. 🙂
trotterd
/ March 27, 2020Hi Richard,
Just for clarity, is it actually possible to have multiple Trusted Network Detection elements configured. If so would each one be listed within there own element, or would you only define one element and list the trusted networks and separate the list using a comma.
Regards
Dave
Richard M. Hicks
/ March 27, 2020You can only define the element once. However, if you have more than one internal DNS suffix you can add them, separated by commas.
trotterd
/ March 26, 2020Hi Richard, thanks for the steer, much appreciated.
Regards,
Dave
sysadminjames
/ April 19, 2020Hi Richard, hoping you can help me understand this part better.
I have two RAS behind a KEMP LB, I have users spread across both using “least connection”. I have found then when connected to RAS01 if I reboot it and expect clients to move over to RAS02 the client will sit disconnected for around 5 minutes each time. Then eventually may connect back to RAS01.
I would have expected once it is unreachable it would re-dial the VPN and connect to my 2nd server. In you experience is there normally such a delay?
Richard M. Hicks
/ April 20, 2020Using all of the default settings this is pretty typical. There are some things you can do to make sure the client re-establishes a connection more quickly though. On the Kemp, make sure the following settings are configured.
System Configuration > Miscellaneous Options > L7 Configuration
– Select Yes-Accept Changes from the Always Check Persist drop-down list
– Enter 60 in the L7 Connection Drain Time (secs) field and click Set Time
– Enable Drop Connections on RS Failure
– Enable Drop at Drain Time End
System Configuration > Miscellaneous Options > Network Options
– Enable Reset on close
If you are using IKEv2 you may also need to make changes to the network outage time in rasphone.pbk on the client. A script to make that change can be found here.
sysadminjames
/ April 22, 2020Thanks Richard, I have given them ago to mixed results at the minute.
I have User and Device tunnel deployed both using IKEv2, with the rasphone settings would you recommend to set the NetworkOutageTime to 60 for the user tunnel?
Richard M. Hicks
/ April 22, 2020That should work. I think I typically set it to two minutes (120) but 60 should be fine too.
Simon Whitfield
/ June 24, 2020https://hybridcloudexperts.be/index.php/2019/11/13/windows-10-always-on-vpn-and-network-list-manager-policies/#comment-3832
If you use network policies to rename you network to show a more friendly name within the network control panel items then it is actually that name that TND uses to detect, not the connection specific DNS suffix.
We implemented always on and found that it was trying to constantly connect to VPN, even though we had used TND with our suffix. Found the above site, added our network friendly name to TND as well, and it was no longer trying to dial the VPN when on site.
Richard M. Hicks
/ June 24, 2020Thanks for that very valuable tip, Simon! Definitely good to know. I’ve personally never seen anyone use that setting, but it’s there and available so likely someone will at some point. NHS it sounds like for sure! 😉
Ron
/ December 1, 2020Thanks Richard, for all your posts.
I have configured the trusted network in de VPN Profile and it’s working on the office loccations. However we have some branch offices which are connected via site to site vpn where rfc1918 traffic is routed through the VPN tunnel and the rest via local breakout to the internet.
On these locations the Always On VPN is still connecting which it should not do. If I delete the VPN Profile I still can reach the corporate network via the site to site vpn connection.
I verified the dns suffix on the adapters which is correct.
The connection profile is also domain profile.
Is there logging available to see what the trusted network detection detects during the check if it’s internal or external ?
I would like to see why the VPN thinks it’s on an external connection.
Richard M. Hicks
/ December 1, 2020There’s no easy way to see how trusted network detection is working. You could comb through the event logs looking for this information, but I don’t recall ever seeing it there. The only time I’ve seen this is when working with Microsoft support. They typically collect very low-level debug tracing information that includes this information.
Johan
/ December 23, 2020Interesting article, but although I implemented the mentioned configuration & GPO settings we still have a weird issue in our environment. Our scenario is slightly different though: device is connected with Ao through a WWAN connection. When the user puts the device in the docking station, the LAN connection is initiated and the WWAN disconnects automatically. Sometimes we notice the Ao connection persists. What also strikes me at that time is that the corporate network is being detected as “unauthenticated”. So it looks like NLA is not really working. Any thoughts about this?
Richard M. Hicks
/ December 28, 2020There are a few settings that might help with this. Open the local group policy editor (gpedit.msc) and navitage to Computer Configuration > Administrative Templates > Network > Windows Connection Manager. Set the following:
Enable Windows to soft-disconnect a computer from a network = Disabled
Minimize the number of simultaneous connections to the Internet or a Windows Domain = Enabled (Option 1 – Minimize simultaneous connections)
Let me know if that helps!
Johan
/ December 29, 2020Hi Richard,
Thanks for getting back at me. These GPO settings are already applied but they don’t make any difference.
When we try to simulate it it fails 1 out of 3 times. When it fails you can see it’s connected to the domain profile but with a mention of “unauthenticated”. Several devices have the issue, mainly 1909 but also some 20H2 devices.
Kind regards,
Johan
Richard M. Hicks
/ January 6, 2021Odd that it works sometimes. Not sure what’s up there.
Johan
/ January 14, 2021Hi Richard,
Just to let you know, I found a workaround for the issue. Whenever the connection goes south I restart the “IKE and AuthIP IPsec Keying Modules” service. This will drop the Ao connection and restore the corporate LAN connection to full effect. I created a scheduled task which is triggered on a certain event ID which is logged upon reconnection (20277). Everybody happy! (for now…)
Regards,
Johan
Richard M. Hicks
/ January 18, 2021Great to hear! 🙂
David green
/ February 5, 2021Related issue to this topic, hopefully this is one you have seen and can assist with.
AOVPN working fine if device started remotely on wireless but if network cable plugged in it takes precedence and AOVPN traffic fails to route correctly.
One of the guys has “fiddled” with the network metric settings manually when cable plugged in to get it to work but we cannot do that for 250 remote users.
Any thoughts how we force it to recognise to use the VPN even when on a cable?
Richard M. Hicks
/ February 5, 2021Best way to do this is to update the rasphone.pbk file on your clients to lower the VPN interface metric to something lower than the Ethernet interface. I have a PowerShell script that can be used to automate this here: https://github.com/richardhicks/aovpn/blob/master/Update-Rasphone.ps1.