MgmtTunnel socket handle when LanAccess is not allowed

[ohlstand]

Hi!

Could not find a thread regarding my particular issue and hope someone here can explain it.

On W10, if I provide a VpnMgmtTunProfile.xml for the clients but for any reason, let's say the client doesn't have a valid certificate or it might has been revoked - why does the client have full internet access even though I have specified explicitly in the .XML that LanAccess is not allowed?

My understanding is that AnyConnect reads the .XML once the service is started and if I have specified that LanAccess is not allowed - the application has a handle on the socket until requirements are fulfilled within the .XML.

What I also noticed, which seems confusing, is if I provide a UserProfile.xml with LanAccess also set to false in C:\ProgramData\Cisco\Cisco AnyConnect\Profile  - the socket is handled by the application - but if I only provide C:\ProgramData\Cisco\Cisco AnyConnect\Profile\MgmtTun\VpnMgmtTunProfile.xml without any UserProfile.XML- it "discards" it. Like it cannot find the .XML.

(The tunnel itself is not the issue, everything works as expected, I'm just wondering about the behaviour for AnyConnect).
Am I missing something obvious? Are there any cache anywhere that I'm missing? Is it a bug?

[Cisco_Virtual_Engineer]

Based on the information found, it seems that your issue might be related to specific settings in the AnyConnect profiles and group policies on your VPN headend (either ASA or Firepower). You should ensure they are correctly configured for local LAN access.

Another important aspect to consider is checking for any conflicts or errors in the AnyConnect logs on both the client and server sides, which could be very helpful in diagnosing the problem. You might also want to check the compatibility of your AnyConnect versions with the LAN access settings.

It is unclear why exactly the application is discarding the VpnMgmtTunProfile.xml file if there isn't a UserProfile.xml file, and it might be a question worth posing directly to Cisco Support or the Cisco Community for more specific assistance and troubleshooting steps tailored to your environment and setup.

The behavior you're noticing does not seem to be a common or expected one, and no obvious solutions or workarounds were found in the initial search. I would recommend direct engagement with Cisco support for a more thorough investigation of this problem.