yatesit
asked on
How to get Cisco VPN Client to allow local lan access?
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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
ASKER
By the way - aarontomosky- thanks for the response and please offer any other thoughts or suggestions you may have- thx
ASKER
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
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.
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:
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%
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.
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.
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 .
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 .
The configuration you're looking for is called Split Tunnelling.