We help IT Professionals succeed at work.

How to get Cisco VPN Client to allow local lan access?

yatesit
yatesit asked
on
We have several users that connect to our network using the Cisco VPN Client. We check the option to "Allow Local LAN Access" but when they are connected they cannot see the local LAN. If you look under Status\Statistics you see that the Local LAN is "Disabled" in spite of the fact that you have made the "Allow Local LAN Access" selection. Where the subnet is 192.168.1.2/24 I can open a command prompt and type, route delete 192.168.1.0 and the Local LAN is then accessible. This only lasts, though, until the user disconnects and then re-connects to the VPN- then we're back to square one. We need a permanent solution. Any ideas. Really stumped on this one.
Comment
Watch Question

Director, SD-WAN Solutions
BRONZE EXPERT
Commented:
Is the remote LAN subnet the same as the local LAN subnet?

Commented:
Even though the option appears on the client, it's actually controlled by the VPN server policy.
The configuration you're looking for is called Split Tunnelling.

Author

Commented:
We are having this problem so far only on the 192.168.1.0/24 local subnets - and one of our internal LANs on our WAN is a match for this - we have modified several of our local LANs so they do not conflict in this way - up until now the only reason we did that was because we had IP Conflicts that sometimes prevented connections - but never this issue- The thing about the 192.168.1.2/24 subnet is that it is very common in motels, at homes, etc... and our users (and there are many of them) need to be able to connect from whereever they may be and access our network - are you suggesting that this issue in itself could be causing this- because we do have some locations where we have 192.168.1.0/24 as the local subnet but they are still connecting okay- I understand that things are what they are and that changing the local subnet might clear the issue but we can't change the local subnets everywhere they go- for us to change the internal LAN that conflicts with this subnet would be a major deal

Author

Commented:
By the way - aarontomosky- thanks for the response and please offer any other thoughts or  suggestions you may have- thx

Author

Commented:
Frabble- thx for the response- I read a little about that but am not sure that I understand everything i read- is this something we would need to set up in the main firewall
Aaron TomoskyDirector, SD-WAN Solutions
BRONZE EXPERT

Commented:
having the same subnet is a bad idea. I have users with the same situation and most things usually work fine for them. However I generally set "send all traffic" (thats the setting in my vpn software, not cisco) as split tunnels don't work when your gateways have the same address (192.168.1.1). Then as long as there are no duplicate ip's, things work ok.
Qlemo"Batchelor", Developer and EE Topic Advisor
SILVER EXPERT
Top Expert 2015

Commented:
Yes, the Split Tunneling setting has to be set on your Cisco device. But you do not want to switch it off, as that would block LAN access for all peers.

On subnets conflicting, your only choice is indeed to manipulate the routes, and even then you need to define a precedence for conflicting IP addresses.
If your target IPs (having to use the VPN) are few, those few should be routed as host routes (/32), or at least as more specific subnet routes (/28 or the like), while deleting the subnet route created by the VPN client.
The other way round, local IP subnets or host could be added as route, to allow access to those specific local IP addresses.
In any case you loose accessibility - either on the local or remote side.

Should you want to walk that path, you would need to start the VPN client via commandline interface, and then apply all necessary route changes. Something like:
@echo off
%ProgramFiles%\Cisco Systems\VPN Client\ipsecdialer.exe" -c -sd YourConnection
REM or use the following line instead:
REM %ProgramFiles%\Cisco Systems\VPN Client\vpnclient.exe" connect YourConnection
for /F "tokens=1,5" %%A in ('2^>nul %exec% netsh interface ip show ipaddress ^| find "Cisco"') do set newGate=%%A
route delete 192.168.1.0 mask 255.255.255.0 gateway %newGate%
route add 192.168.1.111 %newGate%
route add 192.168.1.222 %newGate%

Open in new window

which will allow remote access to .111 and .222 .

Commented:
Yes, you would configure split tunnelling on your main firewall if that is what the VPN clients connect to.
By default, all traffic is tunnelled through the VPN connection, however you can set split tunnelling to either have the client local network (whatever it is) or an access list of specific networks to be routed locally.

The address overlap you have between your local network and the remote client network is another problem. There is no need to do anything separately on the client since a split tunnel ACL can also include denys for any specific host, for example, which will then cause this traffic to tunnelled. It's not a tidy solution and if there is a real need for your clients to access local networks which are the same as yours when the VPN client is active, the best way to go is for you not to use those networks - a major deal you said so it's your call.

Commented:
you can try with policy nat  . You can nat your network 192.168.1.0/24 before tunnel to client with other network  .  You must reconfigure your vpn parameters  considering your internal network with new  p address


ex.
access-list  natvpnclient   permit ip   192.168.1.0 255.255.255.0   <VPN CLIENT NETWORK>

static (inside,outside) 10.254.1.0   access-list natvpnclient

in this case the vpn client will see your inside network with new ip address .  10.254.1.0  and every client or server of your network will be nat 1 to 1 to new network  for example your internal ip 192.168.1.10 will be , for your vpn client  10.254.1.10 a so on .

this way permit to  change ip for vpn client but not inside your network.

split tunnel is necessary too .