Recently I’ve deployed always on vpn device tunnel.
From ~200 onsite computers about 10-20 different and seemingly random ones each day connect to it, despite being set not to within XML config, specifically this part: <TrustedNetworkDetection>office.company.com</TrustedNetworkDetection> where office.company.com is internal domain, it is set in DHCP option 015 and all computers successfully get it - both those who do connect to vpn while they shouldn’t and those who do not connect like they should.
I’m struggling how to troubleshoot that?
I don’t see any logs anywhere neither client nor server side, and looking through usual place for answers about anything-alwaysonvpn (richard hicks’ blog) doesn’t shed light on that issue too.
I ran into this same issue and ‘fixed’ it by removing the Always On VPN dns record from our internal DNS, so even if the TND fails it can’t resolve the hostname and fails to connect while inside our network.
May not be the answer you are looking for but as you’ve already seen this kind of detection isn’t reliable. It’s also likely east to spoof from an attacker’s perspective, imagine I setup a network with the right dhcp option, could I get your users not use the vpn? I don’t have a suggestion for fixing the detection but it might also be worth asking the question could you tolerate having them just using the vpn all the time? If it causes other problems to be on the vpn, any chance it might be worth to fix those instead?
Maybe you’ve considered all this already. The vpn setups I have seen with reliable detection like you are looking for usually have an endpoint agent that tries to mutually authenticate to a nac/802.1x solution with a certificate and then requires a vpn and/or applies some other policy if it cannot. The mutual authentication piece makes the detection much more black and white.
Ah, so basically whatever vpn hostname is, like vpn.company.com for example, you make it unresolvable internally? A bit clunky but will work indeed, thank you.
I understand what you mean. First thing first - that shouldn’t-be-vpn connection doesn’t really cause problems, or at least I haven’t seen any so far. It’s just that it shouldn’t be like that and that’s why I’m looking into it, not because something broke. Sort of preemptive measures in case it indeed will mess with something later.
As for vpn/security stuff - that’s device tunnel, it’s basically used for logging in in remote locations where there’s no site2site vpn, for certificate enrollment for WFH users and stuff like that - not something users need for their day to day job.
PTR for your trusted network detection A record. Let’s say I create an A record for trustednetwork.contoso.com and set it to 169.254.169.254. Palo Alto’s client GlobalProtect does a (reverse) DNS lookup for 169.254.169.254 and because in the client settings you’ve told the client that trustednetwork.contoso.com should resolve to 169.254.169.254, it’s looking for a DNS response to it’s nslookup of 169.254.169.254 with the hostname trustednetwork.contoso.com. If it doesn’t receive a response or receives a different hostname in the response, it determines it’s not on a trusted network and will initiate the VPN connection.
Well in my case trustednetwork from xml is office.company.com. It doesn’t have specific IP, it’s a network after all, am I missing something?
If I nslookup office.company.com it resolves into all DC IPs (5 in my case). If I nslookup -type=PTR ip I’ll get hostname of whatever DC’s IP I’m nslookup’ing, for example dc3.office.company.com. None of that resolves specifically into office.company.com.