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 lab.richardhicks.net.

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.

Intune

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

  1. Open the Intune management portal (https://devicemanagement.microsoft.com/).
  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

ProfileXML

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

Always On VPN Trusted Network Detection

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.

  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

11 Comments

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

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

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

        Regards

        Dave

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

    Regards,

    Dave

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

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

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

    Reply
  5. Simon Whitfield

     /  June 24, 2020

    https://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.

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

      Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: