AnyConnect 4.X didn't allow local LAN access

[zexinfinite]

I have two version of AnyConnect client - v3.1 and v4.8, and I notice when I use v3.1 client and it allow local LAN access, it will only configure the routes which is apply by split tunnel (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). But when I use v4.8 client, it will direct all of route into tunnel even I try to delete route or change metric.

I also try to enable LocalLanAccess on client profile or enable LocalLanAccess on AnyConnect client UI, but it's not really effective.

Did I miss something?

[marce1000]

 - Check if you can find some guidelines here :

              https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/70847-local-lan-pix-asa.html

 M.

[zexinfinite]

Yes, I use this way to advertise secure routes and I didn't advertise 192.168.100.0 on list.

[Cristian Matei]

Hi,

  Looking at the routing table between v3.x and v4.x of Anyconnect, i see that for 3.x you have a secure route for 192.168.0.0/8, while on 4.x you have a secure route for 192.168.100.0/8, where 192.168.100.0/24 is also the LOCAL LAN; this looks like a miss-configured split-tunnel ACL on the VPN headend and also an inconsistent policy, should 192.168.100.0/24 be tunnelled or not. Ensure the split tunnel ACL is standard and contains only the following: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. Connect with AnyConnect and from the VPN GUI, on Route Details, ensure these exact prefixes are tunnelled, only. See if Local LAN Access works, once you enable it as well on the client side.

   If it still doesn't work, it may be because as of 4.x version of AnyConnect, including 4.8, you need to have an AnyConnect XML profile active (either locally configured or pushed over from the ASA upon connection time, the second option is the easiest one to do). Do this, and afterwards Local LAN Access should work. If not, try using the latest version of 4.8, or downgrade to the latest version of 4.7 (in order to avoid bugs), it has to work.

Regards,

Cristian Matei.

[zexinfinite]

Hi Cristian,

Unfortunately, I use same policy and same device with different Anyconnect client, so the policy is consistent.

I also notice this issue on v4.3 and v4.7, so I guess all of Anyconnect client with 4.X version have same issue.

I try to enable Local LAN access on client profile and it's not working.

I notice if I just apply secure route for 192.168.99.0/24 then 192.168.100.0/24 won't be impact, but if I apply secure route and it's include 192.168.100.0/24 (192.168.96.0/21 or 192.168.0.0/16), then it will be impact.

Maybe there have something different on v4.X clients...

[Cristian Matei · Accepted solution]

Hi,

   From my point of view, and how i've done all deployments, the current version of 4.x works correctly, what you see is expected. You can't tell to AnyConnect that 192.168.100.0/24 is a secure route (so all traffic for that destination needs to go through the tunnel), and at the same time that 192.168.100.0/24 is a non-secure route, local LAN (so it cannot go through the tunnel).

  There is a conflict in there, resolved by who takes precedence at the kernel level, which is AnyConnect. So if you want to have local LAN access to 192.168.100.0/24, you should not send that as secure route, remove it from the split-tunnel ACL.

Regards,

Cristian Matei.

[zexinfinite]

I think there may have some misunderstanding on my previous response.

I didn't tell AnyConnect that 192.168.100.0/24 is a secure route, and I also didn't configure it in split-tunnel list.

I only configure 192.168.0.0/16 in split-tunnel list, and 192.168.100.0/24 is one of subnet in 192.168.0.0/16, that's the reason why AnyConnect  v4 client generate secure route with 192.168.100.0/24 automatically.

If I replace 192.168.0.0/16 with 192.168.1.0/24 in split-tunnel list, then AnyConnect client will not generate secure route with 192.168.100.0/24 automatically, because 192.168.100.0/24 didn't include in 192.168.1.0/24, and if I replace 192.168.1.0/24 with 192.168.6.0/23, then it will happen again.