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! 😉
Eirik Haver
/ November 9, 2021Thanks 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.
echo
/ January 16, 2023By 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).
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.
John Quile
/ March 15, 2021Hi 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?
Richard M. Hicks
/ March 16, 2021I’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.
Chris
/ April 6, 2021Not 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.
Richard M. Hicks
/ April 6, 2021I 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.
Remon
/ April 19, 2021Hey 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…
Richard M. Hicks
/ April 23, 2021Unusual. Have you configured Network List Manager policies using group policy?
Remon
/ April 26, 2021Hey Richard, no we have not configured Network List Manager policies in the on-premise environment.
Richard M. Hicks
/ May 3, 2021Ok. 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!
Chris
/ May 3, 2021We 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?
Richard M. Hicks
/ May 3, 2021So the VPN interfaces both have the pubic firewall profile enabled when they are established?
Chris
/ May 4, 2021Yes 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?
Richard M. Hicks
/ May 5, 2021Not 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, 2021That 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.
Richard M. Hicks
/ May 14, 2021I 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.
Rob D
/ May 14, 2021Pretty 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.
Richard M. Hicks
/ May 14, 2021You 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.
Rob D
/ May 16, 2021Thanks, 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.
Richard M. Hicks
/ May 17, 2021Yes, 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.
Nico
/ May 19, 2021We 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?
Richard M. Hicks
/ May 20, 2021That 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.
Jeffrey
/ May 27, 2021Hello 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.
Richard M. Hicks
/ May 27, 2021In your XML configuration file, you have TrustedNetworkDetection set to ‘true’, correct? FYI, it must be lower case! ‘True’ won’t work. 🙂
Jeffrey
/ May 27, 2021Hello 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?
Richard M. Hicks
/ May 28, 2021No, 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, 2021Hello 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?
Richard M. Hicks
/ May 28, 2021Sorry for the confusion. TND does not support “true” or “false”. Have a look at my previous comment for clarification.
Remon
/ May 27, 2021Hey 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.
Richard M. Hicks
/ May 28, 2021It 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.
Ashish Arya
/ June 2, 2021Hi 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.
Richard M. Hicks
/ June 4, 2021I 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.
Dave
/ July 23, 2021I 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!
Richard M. Hicks
/ July 23, 2021That’s expected and by design. The device tunnel remains connected even when the user logs on and establishes their own tunnel. 🙂
sukafun
/ August 10, 2021Hi 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?
Richard M. Hicks
/ August 11, 2021I 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.
sukafun
/ August 17, 2021I’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.
Richard M. Hicks
/ August 24, 2021Even 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.
JeffVader
/ September 7, 2021Hi 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?
Richard M. Hicks
/ September 8, 2021That’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.
CK
/ September 15, 2021Hi 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
Richard M. Hicks
/ September 16, 2021It’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.
NH
/ November 25, 2021Hi 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 ?
Richard M. Hicks
/ November 29, 2021Trusted 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.
Ross Baker
/ November 30, 2021Thanks 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.
Ross
/ November 25, 2021Hello 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
Richard M. Hicks
/ November 29, 2021If 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.
psychodata91
/ May 3, 2023FYI – 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!
Richard M. Hicks
/ May 5, 2023That’s quite interesting. Another option is to ensure that your clients can’t resolve the public hostname when they are on the internal network. 🙂
RNalivaika
/ May 26, 2023Check out the new CSP options for managing network profiles:
https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-list-manager-policies
https://www.petervanderwoude.nl/post/automatically-switching-the-windows-firewall-profile-on-azure-ad-joined-devices/
Richard M. Hicks
/ May 26, 2023Great to hear!
Peter Blaines
/ November 7, 2023Hi 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?
Richard M. Hicks
/ November 7, 2023I’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.