In your AnyConnect config, you can specify your office subnets as LAN subnets so AnyConnect won’t automatically connect.
I had to do this for some road warriors, so they would automaticly connect to VPN while on the road, but if they were in the office on the LAN or Wifi AnyConnect would not automatically connect.
Initially, we reached out to Cisco TAC for assistance, and their recommendation was to block the public IP addresses on the FTD for each of the 28 offices. However, we are hesitant to follow this advice because the circuits frequently change
So do it the other way around: block the anyconnect IP and port on all the offices firewalls.
GlobalProtect has an internal host detection feature.
Perhaps AnyConnect has something similar? I couldn’t find anything on a quick search.
Fuck, I just assumed not being able to connect with AnyConnect inside the network was default behavior. Apparently I did something right by accident.
The DNS options already suggested are the best route to take. As has also been mentioned it doesnt work 100% of the time.
In additon i run a script every minute on the client. If the device has an ip address on our subnet the script disconnects the VPN. And vice versa. Our subnet is pretty unique. So far it’s not been an issue for devices outside our office that need to connect.
just use if/else
/s
i don’t do sysadmin im just here to learn
I didn’t see anyone suggest the “Direct Access” way of solving it, if I recall correctly it used NRPT. This would be a windows only solution, but can be done with group policy. I’d still prefer the anyconnect specific way (I think it’s TND) or DNS over this, but it never hurts to know all your options.
We just blocked the VPN from. Working on the network. Easy
This might be an unpopular answer, sometimes training is the answer.
Staff need to understand what a VPN is, and what it is for and then use it properly.
A big user-facing benefit of the “BeyondCorp” (or usually “zero-trust”, now) paradigm is that the workflow is identical, and maximally efficient, regardless of where the endpoint is situated.
It takes effort to fit webapps and workflows with proper authentication, but the advantages are worth it. Everything is a lot easier today than when we started on it in 2012.
If the VPN software can’t be configured simply and automatically do the right thing then you should get software that works.
Stop making them come to the office 
Just use always on VPN from Prisma and call it a day. Or just create rules
2 thoughts, on the firewall for each of the 28 sites block them from communicating with FTD, that wouldn’t require any updates if the circuit changes or change the internal DNS entry for your FTD to something that isn’t the FTD
Customer had a similar issue but with the Azure always on VPN.
The 2 work arounds was using your on prem firewall block the VPN endpoint from connecting and using group policies to disable the VPN if they are connected to the corp Lan.
Simple.
Wifi is separated from all the network resources. If you connect to wifi, you have to vpn in anyway.
Yeah… Here we have to be on a VPN with 2fa to Remote Desktop into other machines.
I had OpenVPN set up in an always-on configuration, so I used Windows Firewall to block it from connecting when on the domain profile. That’s only really applicable for company-owned devices though.
Forticlient has different profiles for on/off fabric, so users get different settings based on their public IP. No idea if Anyconnect has a similar option.
But the guy that said the DNS thing is spot on. Although it should make for some interesting troubleshooting while you work out the kinks.
this is a training/management issue more than a technology issue.
how hard is it to NOT connect to VPN when your’e in the office, just dont pick ‘connect’ before trying to work.
This is one of those ‘CC the manager’ tickets. make them log a connectivity issue ticket, close it with instructions NOT to connect to the VPN in the office, and cc the manager.