cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
339
Views
0
Helpful
7
Replies

ALLOW LOCAL LAN ACCESS is not working properly on some clients !

FARSAN
Level 1
Level 1

We have split tunnel client VPN server on Meraki, which it set to send traffic for 192.168.0.0/16 to the server. 

A client has 192.168.1.0/24 in his local network which is smaller subnet and should have priority to /16. 

And he also check-marked ALLOW LOCAL LAN ACCESS, but he still can't access to his local printer. 

I took a look at his route table and noted a higher prior route is added by CAC to his route table to force that /24 to go to tunnel as well (see attached) . Is this normal ?

Screenshot 2023-12-13 162020.jpg

 

7 Replies 7

balaji.bandi
Hall of Fame
Hall of Fame

You mean to say your VPN also have same subnet wit /16 and your local net also have /24.

not to make complicated is this possible to change local LAN to different subnet ?

 

BB

***** Rate All Helpful Responses *****

How to Ask The Cisco Community for Help

tvotna
Spotlight
Spotlight

This is 100% expected behavior and is documented (somewhere). If it were ASA you'd need the following in order to allow access to local LAN:

access-list split-include-ACL standard deny 192.168.1.0 255.255.255.0
access-list split-include-ACL standard permit 192.168.0.0 255.255.0.0

group-policy <name> attributes
split-tunnel-policy tunnelspecified
split-tunnel-network-list value split-include-ACL

I don't know how Meraki is configured.

Allow local LAN access is still needed on the client side with the above config.

 

I forgot to mention that it is possible to allow access to *ALL* local LANs (on all client interfaces), no matter if they belong to split-tunnel supernet, if, for example, specific local client subnet is not known in advance. In this case replace above "deny" statement with the following one:

access-list split-include-ACL standard deny host 0.0.0.0

 

 

Only use standard not extended acl

And try again 

MHM

This has nothing to do with standard vs extended ACLs. This is to do with security: the split ACL configured on the headend device must always has priority. If it says that 192.168/16 must be tunneled, it must be tunneled no matter which IP address is assigned to client interface (remember that you can be in the hotel or airport and the IP address can be assigned dynamically from an arbitrary subnet).

 

Friend it dont have any relate to policy' the split tunnel is use to add route in VPN client RIB point to GW (asa or meraki).

And we use standard since we need to specify only route using source of standard acl there is no meaning of destiantion IP if we use extended' instead it can be issue if client or gw dont know which IP need to use to add route.

MHM

Test and make sure that "deny" statement I mentioned solves customer issue.