I am currently testing out the Umbrella module in AnyConnect and it is working well. The one thing I can't seem to get working is Trusted Network Detection.
I got Trusted Network Detection working while I was in the office, so while I was in the office and not connected to the VPN, the Umbrella module was inactive.
Now I am trying to make the Umbrella module inactive while connected to our Meraki split-tunnel VPN at home since all of my DNS while on the VPN goes back to my internal DNS servers anyway, but it doesn't seem to be working.
While connected to the VPN, the DNS protection status still says "Protected" and Encryption as "On". I have tried various changes in the VPN profile to see what would trigger the VPN to be a Trusted Network, and still no go.
Has anyone gotten the Trusted Network Detection to work properly while connected to a split-tunnel Meraki AnyConnect VPN?
before delving deeper into TND, let me start by describing my preferred setup:
In most cases, I tend to solve this one by using "Traffic Forwarding on Umbrella Protected Networks".
This way, the Umbrella module will realize that it's within a protected network and will not activate itself. Everytime the client is roaming, it will be protected even if your VPN connection to the headquarter is off.
Much simpler (in my point of view) and because you don't have to fiddle around with all the bells and whistles regarding TND. Apart from that, it raises your security because it doesn't matter if your VPN is running or not.
If this is not what you want, we can continue to assist you with your troubleshooting. 🙂
Thank you for your response, but I already have that setting enabled.
And in the documentation for this settings seems to point to why it's not auto-disabling in my case:
The local DNS servers must be configured to use Umbrella as the sole DNS forwarders.
This is true for me
The DHCP scope must be configured to hand out the IPs of the internal DNS servers.
This is true for me
The local network must allow direct access to either 53 or 443 UDP with a destination of 18.104.22.168.
This is true for me
The workstation's egress IP must match the configured local DNS server's egress IP's registered network.
This is not true for me. (At least based on how I understand it) My computer, while connected to the VPN, queries my internal DNS servers, which points to Umbrella and has the external IP of my datacenter. My local machine is using split-tunneling for the VPN, so my external IP would not match the IP of the DNS query external IP of my corporate network.
I wonder if I set the VPN to tunnel 22.214.171.124 back over the VPN if that would cause this to work.
That's exactly my point (if I'm not completely getting you wrong): by tunneling your DNS requests via your HQ, you're missing this features functionality.
From my point of view:
1) You're in the HQ and are protected by your local DNS servers forwarding to Umbrella. Verything is working as you'd expect
2) You're off-site and relying on your VPN connection. By letting your endpoint querying Umbrella directly (without pushing DNS over the tunnel), you're evenly protected, at least if your policies are set up accordingly.
I currently only have 1 default policy in place for both Network and Roaming Computers, so there is no concern with consistency.
And I have our domains set up properly I think in the Umbrella dashboard, so even when my queries are going to Umbrella instead of my DNS servers, I am still able to access internal resources while connected to the VPN.
My thought was that maybe it was best practice to always use our DNS servers when they are reachable?
With how I have things set up for my testing this Umbrella module, everything is working as desired. Just when I saw that queries were going to Umbrella instead of my DNS servers while connected to the VPN, instead of treating it like a "Protected Network", I thought I was doing something wrong.
You'd always want to use your internal DNS servers for resolving internal destinations. With Umbrella, you have the chance to resolve every external DNS request directly and still be protected by Umbrella wherever you are.
This also solves other issues like "local" M365 access for endpoints that roam internationally: by letting them resolve everything not internally resolvable via Umbrella, the client will always receive the "nearest" Microsoft datacenter.