Due to design we are unable to use the recommended method of detecting whether a network is internal or external prior to VPN establishment. Instead we are using the “The client runs on a computer that can access its active directory domain.” Which seems to work for the most part, but we’ve discovered an issue I’d like to get some feed back on.
The instance where it doesn’t seem to work correctly is if a client was outside of an office and let their computer go to sleep instead of shutting down. If they were to arrive at an office and resume their computer, the VPN auto-connect would kick in and connect them. Looking through the helpdesk log and trac log indicates the client is in a “WAIT FOR SERVER” or “UNKNOWN” network location state. You can disconnect the VPN and reconnect it while it is like this. However, if you were to reboot the device it would work correctly and not auto-connect due to being inside the network.
If a computer is shutdown while away and booted up in office there doesnt seem to be an issue, it senses the device is IN network and does not connect.
And anyone worked through this before?
Can you explain a bit the design that forbids you from using the Anyconnect on-perm detection ?
Like walk away? We have vpns established for 6 to 7 hours while they are on network and shouldn’t be. So it never disconnects once connected
The recommended setting that we cannot use is 'if communication comes from internal interface". These firewalls do not sit inline for most of our SDWAN traffic, so there is not way to force the traffic through an internal interface while on network to classify has in network.
I see, and the recommended setting was ?? Because I have never heard of “if communication comes from internal interface”.
The communication towards ASA VPN will come to the OUTSIDE interface, and I doubt it that you have that routed via INSIDE interface. Our ASA doesn’t reside in-path, as it’s in our DataCenters.
I suppose that the same thing happens with Checkpoint too.
Because we are using the Trusted Network Detection, like it’s explained here and we have no issue.
One other way to assure that the VPN doesn’t happen internally, was to drop the VPN DNS resolution from internal DNS servers. I believe you have a way to do that from SDWan side too.
I’m not sure if there is an option for trusted network detection on Checkpoint VPN, but I’ll have a look and come back.
I see that you havean option to do AD checks, we’re you using that?
They’ll have to reboot to get it to work correctly. Its not huge issue, with MEP the devices are connecting to the firewall onsite for VPN so there is really no latency. I just dont like that it is connecting at all when it shouldnt.
Yeah, so Network Location Awareness for Checkpoint is what you are calling Trusted Network Detection with Cisco. There are three options of detection:
- Client connect to gateway through one of its internal interfaces (recommended)
- Client connects from this network or group (list of networks)
- Client runs on a computer that can access its AD domain
The first option doesn’t work for us like I said earlier because the gateway doesn’t sit inline between our clients and the internet. Using MEP, the clients do not resolve to IP address after the initial site build. They continue to use the cached list of external IP addresses which hits the external interface of the GWs.
The second option doesn’t work for us because we use many different types of connectivity for our facilities which change external IP addresses very commonly. So a static list of external addresses is useless.
The third option works for the most part, except for when a client comes out of sleep on-prem. Network Location Awareness goes into a “WAITING FOR SERVER” or “UNKNOWN” state which allows the VPN to connect while “IN” network.