Always On VPN Trusted Network Detection

Always On VPN Trusted Network DetectionWhen 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

Always On VPN Trusted Network Detection

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.


Follow the steps below to configured trusted network detection in Microsoft Intune.

  1. Open the Intune management portal (
  2. Navigate to Devices > Configuration Profiles > [Profile Name] > Properties > Settings.
  3. Click on Trusted Network Detection.
  4. Enter the DNS suffix(es) used on the internal network.

Always On VPN Trusted Network Detection


To define Trusted Network Detection in ProfileXML, add the TrustedNetworkDetection element as follows.

Always On VPN Trusted Network Detection


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.


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.

  1. Create a new Group Policy Object (GPO).
  2. Right-click the new GPO and choose Edit.
  3. Expand Computer Configuration > Administrative Templates > Network > Windows Connection Manager.
  4. Double-click the policy Minimize the number of simultaneous connections to the Internet or a Windows Domain.
  5. Select Enabled.
  6. 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.
  7. Click Ok.Always On VPN Trusted Network Detection
  8. Double-click the policy Enable Windows to soft-disconnect a computer from a network.
  9. Select Disabled.
  10. Click Ok.Always On VPN Trusted Network Detection

Additional Information

Understanding and Configuring Windows Connection Manager

Leave a comment


  1. Hi Richard, I hope you are well.

    I have a scenario where we have a top level Active Directory Forest Root. For example:-

    My users computers, RRAS VPN servers and NPS server is in a child domain called: –

    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

    I have configured the TrustedNetworkDetection parameter within the Device Tunnel Profile and the User Tunnel Profile to use the child domain of 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.



    • If 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. πŸ™‚

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



      • You can only define the element once. However, if you have more than one internal DNS suffix you can add them, separated by commas.

  2. Hi Richard, thanks for the steer, much appreciated.



  3. sysadminjames

     /  April 19, 2020

    Hi 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?

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

  4. sysadminjames

     /  April 22, 2020

    Thanks 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?

  5. Simon Whitfield

     /  June 24, 2020

    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.

    • Thanks 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! πŸ˜‰

  6. Ron

     /  December 1, 2020

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

    • There’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.

  7. Johan

     /  December 23, 2020

    Interesting 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?

    • There 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, 2020

        Hi 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,


      • Odd that it works sometimes. Not sure what’s up there. :/

      • Johan

         /  January 14, 2021

        Hi 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…)



      • Great to hear! πŸ™‚

  8. David green

     /  February 5, 2021

    Related 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?

  9. John Quile

     /  March 15, 2021

    Hi would this also prevent the Azure VPN Client from connecting if it was detected to be on a trusted network? It seems to create a Windows 10 VPN in the control panel so I’m assuming it could?

    • I’m not sure. I haven’t spent much time working with the Azure VPN client. However, the Azure VPN client isn’t “always on”, so I don’t suspect that’s the case.

  10. Chris

     /  April 6, 2021

    Not 100% correct in this section but:
    What would be a best practice Client Windows Firewall ruleset for AlwaysOn VPN?

    Just allow UDP 500 / 4500 and HTTPS to the VPN Server public IP on public profile?

    Or is there a smarter rule already available in the Windows Firewall?
    PS: We disabled allowing all outbound per default.

    • I think that would work. However, you’ll have to ensure that the Domain profile allows whatever traffic you want to go over the VPN tunnel.


Leave a Reply to David green Cancel reply

%d bloggers like this: