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

74 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
    • Thanks for this hint. It sadly also seems to trigger when Windows have done some network-mishaps and added a second network, i.e. mydomain.com 2/3/4.

      I think we can assume that it does not look at the connection suffix (alone at least), but also on the networking name itself.

      Reply
      • echo

         /  January 16, 2023

        By Cisco’s manual, if there is both the domain and DNS-server check, they are both checked: “An active interface will be considered as an In-Trusted-Network if it matches all the rules in the VPN profile.”
        I discovered that when coming home from work and resuming my laptop in home cable network, the DNS-suffix remained while getting another IP-address so I concluded that having only DNS-suffix in that TND check is not enough (and that’s how it was configured by somebody else, now I see why).

  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.

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

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

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

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

        Johan

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

        Regards,

        Johan

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

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

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

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

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

      Reply
  11. Remon

     /  April 19, 2021

    Hey Richard, We have a device vpn and user vpn tunnel running (always on vpn) and we have some issues on branch offices. While colleagues work there, the vpn is still being connected while the dns suffix is set correctly and the network connection type is set to “domain”. In the head office we don’t see this problem. Do you have any idea what could be wrong about this? Our config is pretty straight forward with only 1 dns suffix to check. Could the network metric settings have something to do with this? I know that we have a script in place to prefer the vpn connection if it comes to metrics…

    Reply
    • Unusual. Have you configured Network List Manager policies using group policy?

      Reply
      • Remon

         /  April 26, 2021

        Hey Richard, no we have not configured Network List Manager policies in the on-premise environment.

      • Ok. You can try adjusting the network interface metrics to see if that helps. It’s not something I’ve tried, but you never know. Let us know what you find!

  12. Chris

     /  May 3, 2021

    We having a issue where we have a Device and User Tunnel.
    The Device tunnel can access all our DC’s.
    The User Tunnel has a route to 10.0.0.0/8 (includes the DC’s).

    Both have metric 1 in Get-NetRoute.
    Now I have the issue that the firewall profile will not switch from public to domain.

    Although I have enabled for the domain.
    Unfortunatelly if the firewall profile does not switch to domain it blocks almoste every outbound connection.

    Any idea what would be required for proper switch firewall profile with device and user tunnel?

    Reply
    • So the VPN interfaces both have the pubic firewall profile enabled when they are established?

      Reply
      • Chris

         /  May 4, 2021

        Yes both user and device tunnel are on public:

        Name : Device VPN
        InterfaceAlias : Device VPN
        InterfaceIndex : 5
        NetworkCategory : Public
        IPv4Connectivity : NoTraffic
        IPv6Connectivity : NoTraffic

        Name : User VPN
        InterfaceAlias : User VPN
        InterfaceIndex : 26
        NetworkCategory : Public
        IPv4Connectivity : LocalNetwork
        IPv6Connectivity : NoTraffic

        If I am fast enough I see Networkidentification on the VPN Interfaces

        Name : Netzwerkidentifizierung…
        InterfaceAlias : Device VPN

        If I then look in the firewall log I see drops to protocol 4. Is the required to the VPN endpoint?

        2021-05-04 13:36:48 DROP 4 172.20.250.65 123.123.XX.XXX – – 0 – – – – – – – SEND

        Are your vpn interfaces switch properly to domain profile for a domain joined device?

      • Not sure what’s dropping there, but it could be related to domain detection. That certainly sounds like what is happening here. If Windows doesn’t detect a domain controller on the network it will enable the public or private firewall profiles.

      • Chris

         /  May 6, 2021

        That means I require to allow the public / private firewall profile to do DNS and further domain detection checks to our DC’s? Otherwise it will not switch the User and Device tunnel AOVPN interfaces to the domain profile?

        Do you have an idea what firewall rules would be required if: Block connections that are not allowed by a Windows Defender Firewall rule is activated on the outgoing public and private profile?

        I guess this is interesting also for others.

      • I would think so. I don’t know what rules would be specifically required though. It might be helpful to compare to a clean build without any policies applied to see what the differences are.

  13. Rob D

     /  May 14, 2021

    Pretty much the same issue as Chris here. Both tunnels in combo seem recently to be very unstable with the network category seemingly randomly hitting domain and public in various boot and ‘whilst working’ scenarios (causing drop outs and OS freezing). What’s the best way to change the netipinterface to a low number please as this is the bit I’m not in line with your advice above for. I’m getting an error with your script and I can’t find the metric to change in the global device tunnel pbk. The metric is usually around 25-35 user tunnel but device is usually around 4000 ish. Wonder if this just starting recently is due to a Windows patch?

    Thanks Richard, keep up the great work.

    Reply
    • You can use the Set-NetIPInterface PowerShell command to do this, but it isn’t persistent. Usually, my Update-Rasphone.ps1 script works well, but if you’re having issues with it, you could just resort to editing the rasphone.pbk entry yourself directly.

      Reply
  14. Rob D

     /  May 16, 2021

    Thanks, presume the metric in rasphone.pbk in the global allusers profile for device tunnel is ‘IpInterfaceMetric’. However, I tried modifying this by overwriting the file with this variable set and reconnecting didn’t seem to change the metric in powershell for the new connection once changed. If I’m confident the above pbk object is correct I think I’ll try and change it by the group policy ‘INI’ file modification tool, which has worked well for us in the past for changing the connection protocol where needed. Finally, do you recommend device and user both being set to the same metric, or would you go for device being 5 and user as 25 being best practice? Thank you for all your excellent work as usual, very much appreciated Richard.

    Reply
    • Yes, the value of IpInterfaceMetric and Ipv6InterfaceMetric should control the metrics for the VPN interfaces. Odd that Get-NetIPInterface wouldn’t reflect that change though. I’ll have to look into that. You should be ok with both device tunnel and user tunnel interfaces having the same metric. No harm in having one lower than the other though.

      Reply
  15. Nico

     /  May 19, 2021

    We have a bit uncommon network configuration. The internal LAN and the internal WLAN have the same Domainname. But the WLAN has only restricted access to the internal network. So Always-On VPN should connect in the WLAN, but not in the internal LAN. The domain name can’t be changed because it would affect even devices whiteout Always-On VPN. Is there any other way, to detect the network, whiteout to use the trusted network tag in the xml? Something like the website at Direct Access?

    Reply
    • That is unusual. There’s no good workaround here, either. You can either disable trusted network detection or keep it and not have access on the WLAN. There is no option to use NLS like there is with DirectAccess, unfortunately.

      Reply
  16. Jeffrey

     /  May 27, 2021

    Hello Richard,

    After reading all these comments and trying everything i am still unable to resolve my problem with TND.
    The connection specific DNS suffix is configured correctly on all adapters via dhcp. Also the primary DNS suffix is configured (althouh manually for testing purposes).

    For some reason the Always On VPN is always connecting, even when the dns suffix is resolvable. That means we cant use our internal network because all traffic is going to azure. We tried everything described in the comments. Also chancing the network type to private, azure domain joined and public as i saw that on some other sites.
    It doesnt matter if we try on cable or on wifi; same result.

    Is there maybe somebody who has experienced the same problem and can share a solution, or at least point us in the right direction?

    Also we are not sure if RegisterDNS must be true as in your example.

    true ourcompany.local
    false
    false

    Can someone give a hint or link. We are stuck for a couple of days now.
    Many thanks in advance.

    Reply
    • In your XML configuration file, you have TrustedNetworkDetection set to ‘true’, correct? FYI, it must be lower case! ‘True’ won’t work. 🙂

      Reply
      • Jeffrey

         /  May 27, 2021

        Hello Richard, many thanks for you fast reply.
        The TrustedNetworkDetection is configured with the dns suffix.

        true
        true
        company.local
        false
        false

        Is true also necessary in addition to the TrustedNetworkDetection with the dns suffix?

      • No, sorry for the confusion. The TrustedNetworkDetection element simply needs to match the DNS suffix assigned by DHCP to the interface. If you have multiple DNS suffixes, they should all be included in a comma-separated list within the same single TrustedNetworkDetection element in XML.

      • Jeffrey

         /  May 27, 2021

        Hello Richard, many thanks for you fast reply.
        The TrustedNetworkDetection is configured with the dns suffix.

        I see that tags are not allowed.
        So hereby the same config again.

        RememberCredentials true RememberCredentials
        AlwaysOn true AlwaysOn
        TrustedNetworkDetection caroz.local TrustedNetworkDetection
        DeviceTunnel false DeviceTunnel
        RegisterDNS false RegisterDNS
        PluginProfile>

        Is true also necessary in addition to the TrustedNetworkDetection with the dns suffix?

      • Sorry for the confusion. TND does not support “true” or “false”. Have a look at my previous comment for clarification.

    • Remon

       /  May 27, 2021

      Hey Jeffrey, I have the exact same problem. I raised a Microsoft Premium case for this issue to see if they can get it solved. Will be hard for them when Richard is not at Microsoft anymore :). If I got relevant news I will share it.

      Reply
      • It will be really hard as I’ve never been with Microsoft. 😉 That said, another thing to consider when trusted network detection is failing is if you are using the network list manager option in Active Directory. If you have configured that (it’s not common) your TND configuration will need to include whatever name you defined in the network list manager in the GPO.

  17. Ashish Arya

     /  June 2, 2021

    Hi Richard,

    Here is my environment –

    1. Azure VPN client
    2. All machines are Azure AD joined
    3. TND option does not work
    4. Whenever the machine gets on LAN, the vpn doesn’t disconnects
    5. User tunnel based VPN

    Is there any othere setting we can apply may be a script which can turn off the VPn when the machines are on LAN.

    Reply
    • I don’t have much experience with the Azure VPN client. However, I know that it doesn’t support Always On VPN (though it might have some auto-connect capability, I’m not sure). That said if you are connected outside and you move to the LAN, and you still have network access to the Azure VPN gateway, it would be expected to maintain connectivity. One option would be to ensure that the Azure VPN gateway hostname can’t be resolved internally.

      Reply
  18. Dave

     /  July 23, 2021

    I have configured a device tunnel & have an always on split tunnel VPN. Whilst working remotely, obviously the device tunnel kicks in pre-logon, then when the user gets to the desktop, the Always on VPN kicks in. For some reason the device tunnel refuses to disconnect. I have included the in the xml for the device tunnel & configured the Always on VPN TrustedNetworkDetection in the Intune profile. Looking for some help on this!

    Reply
    • That’s expected and by design. The device tunnel remains connected even when the user logs on and establishes their own tunnel. 🙂

      Reply
  19. sukafun

     /  August 10, 2021

    Hi Richard. Question around your sentence about AO VPN is connected when it was outside then connected to internal (simultaneous connection) AO VPN connection will persist you said this is expected an by design.
    In my situation, I have lots of laptops with active cellular all the time and I end up with lots of devices/users connected to AO VPN when connected to corp WiFi.
    The GPO above you mentioned works if the device gets connected to ethernet as WiFi and cellular get disconnected. However if device is connected to corp WiFi the cellular does not disconnect then AO VPN persists.
    I found no GPO or a way to controller cellular behavior. Did you come across this situation?

    Reply
    • I have not come across that specific scenario, unfortunately. I’m not currently aware of any method to disable an LTE connection when an endpoint is on the internal network.

      Reply
      • I’ll post in here once I find a solution.

        In regards to split DNS, for external DNS record obviously it would point to VPN public IP address. For internal DNS, is it important to create DNS record to point to internal VPN IP address?

        When I created internal records, I found all my devices/users connected to the VPN servers even with the TND enabled. So I deleted the records again.

      • Even if your VPN server FQDN is resolvable in internal DNS, TND should prevent it from connecting if it is configured correctly. However, you can avoid the use of TND altogether if you simply can’t resolve the VPN server FQDN on the internal network.

  20. JeffVader

     /  September 7, 2021

    Hi Richard,

    Thank you for all of the information you have given, such a brilliant resource!

    I have one question regarding TND – I have configured it and it works as expected, but they are saying that it is possible to manually start the tunnel when connected to a trusted network – is that by design? As in TND is only for the auto connect trigger?

    Reply
    • That’s correct. There’s nothing that would prevent a user from trying to establish a VPN connection while on the internal network, even if it is listed as a trusted network detection. If you want to prevent this, I’d suggest making sure your public FQDN doesn’t resolve when you are on the internal network.

      Reply
  21. Hi Richard
    What is your experience with the duration of the Networkidentification process with AO VPN Interfaces. I experience sometimes that it takes 20 seconds after VPN connection of the user tunnel, to get that identification done. Is this normal? Can this be speeded up?

    Get-NetConnectionProfile

    Name : Netzwerkidentification………..
    InterfaceAlias : User VPN
    InterfaceIndex : xx

    Reply
    • It’s not uncommon for that process to take a bit of time. I’ve seen it happen quickly, other times it takes 20-30 seconds as you are seeing. Not sure why this happens, but it might be related to name resolution. Not sure though.

      Reply
  22. Hi Richard (and others).

    We have a problem with TND, and from reading here and also on Microsoft page it says that “The VPN stack will look at the DNS suffix on the physical interface and if it matches any in the configured list and the network is private or provisioned by MDM, then VPN will not get triggered”. Our corporate machines has networkcategory “DomainAuthenticated”. I assume that this is the problem, but why having corporate networkinterface set to Private ?

    Reply
    • Trusted network detection simply decides if the Always On VPN connection should be established or not. The Windows Firewall profile selection is determined by domain controller reachability. If the VPN interface comes up and a domain controller can be contacted, the Domain profile is enabled. If not, the Public or Private profile is enabled. These two processes are distinct. Most commonly the Always On VPN interface will have the Domain profile because it provides access to the network where domain controllers reside.

      Reply
      • Ross Baker

         /  November 30, 2021

        Thanks for he reply, we found our issue in the end. For some strange reason our detection was say domain.company but some machines had it as domain.company 2. So the detection wasn’t working on the lan. The work around was to put 2 in to the profile.

  23. Ross

     /  November 25, 2021

    Hello Richard, we are finally rolling out always on. We have a working solution just run in to issue with the above. If some (not all) users are connected to the corporate network on cable or Wifi with DNS suffix intact Always on VPN still connects. While this happens most users can do everything and tracert is going the right way just we’ve had the odd user not being able to connect to anything when they are both connected. Any ideas? I’ve set “Minimize the number of simultaneous connections to the Internet or a Windows Domain” with no luck

    Regards Ross

    Reply
    • If trusted network detection isn’t working as expected, it could be that a Network List Manager profile is enabled. Have a close look at that, and if any are defined, they must be included in the TND configuration on the client. Alternatively, you could forgo TND altogether and just make sure that the VPN public hostname isn’t resolvable internally.

      Reply
  24. psychodata91

     /  May 3, 2023

    FYI – I’m running into an issue where on my AzureAD Joined machines (with no on-prem domain) I cannot get TrustedNetworkDetection to follow the on-prem Suffix.

    Based off some other postings, and some testing, it seems like the issue is that this network is being listed as “Public” under Get-NetConnectionProfile . Changing the profile to Private, it starts to follow the TrustedNetworkDetection list of domains

    https://social.technet.microsoft.com/forums/en-US/19b0504e-4262-48bb-836d-965d2740c685/always-on-vpn-trusted-network-detection-not-working-on-wired-connection

    Now the problem is “OK, how do I get my AzureAD devices to set this domain to be Private, not public” – The only decent option I’ve seen for that is something like a Proactive Remediation or scheduled Task of some sort, but at least it’s one step closer and 90% of the way there.

    Just wanted to comment in case anyone else comes looking for similar and is only finding “Just make sure it can reach the DC” when there is no DC!

    Reply
  25. Peter Blaines

     /  November 7, 2023

    Hi We have Always on VPN setup, device tunnel and user tunnel. Have setup trusted network connection to dns suffixes on both connections. Intermittently each connection will think its inside trusted network and will disconnect the vpn
    any ideas?

    Reply
    • I’ve not seen this myself, but I’ve heard others report the same. Typically this isn’t an issue. When it is, it is difficult to fix. My only suggestion would be to ensure that the VPN server’s public hostname can’t be resolved internally. That way you don’t have to use trusted network detection at all.

      Reply

Leave a Reply

Discover more from Richard M. Hicks Consulting, Inc.

Subscribe now to keep reading and get access to the full archive.

Continue reading