11-16-2009 06:53 AM - edited 02-21-2020 03:48 AM
I have a Cisco 871 router sat behind my adsl router and i have configured it to accept vpn connections from clients from outside(partly configured by cli and partly by SDM).
It works ok, in that I can connect to my LAN and access my network resources inside, however i cannot access the web when connected via vpn.
Is this possibly down to nat? I'm hoping someone can see why in my config. Thanks.
Solved! Go to Solution.
11-16-2009 07:15 AM
Hi Chris ,
The only reason i understand here , clients loosing their ability to reach internet while connected through VPN is , as per the current configuration all traffic (including the NetBIOS) is going through the tunnel. So when a packet leaves the client's machine with a source of ip (one of the private ip address from pool defined) and destination 4.2.2.2 (could be any ip on internet) , there is no translation defined for the VPN client's ip address on the router.
Thus, packet coming from the client's machine with a NON-Routable address can't reach the internet for obivous reasons.
As a workaround try this.
access-list 5 per 192.168.1.0 0.0.0.255
(assuming 192.168.1.0 is the subnet VPN clients need to access)
Then,
crypto isakmp client configuration group home
key xxxx
acl 5 <<< binding the acl here.
By creating the acl 5 and binding it in the client configuration, am splitting the traffic for tunnel. In other words, traffic only destined to the subnet 192.168.1.x will go through the tunnel and rest will take the LOCAL ISP path.
Hope this helps...!!!
Regards
M.
11-16-2009 06:34 PM
I see the following configuration.
interface Dialer1
description $FW_OUTSIDE$
ip address negotiated
ip access-group 102 in
Surprisingly there is no acl 102 in the configuration , so can you please try to remove the statement " ip access-group 102 in" from interface.
Rest part of the configuration appears to be OK unless am not overlooking at something.
Also,run a continuous ping to 192.168.1.1
from client and let me know if you see decrypts growing in number.You can check this with the command below:
show crypto ipsec sa
That way we can make sure that packet from client is even going through the tunnel, probably then it would be easy to isolate the point of failure.
Just a thought , try this :-
Instead of using a standard "acl 5" for split tunneling , make an extended "acl 182" as
access-list 182 permit ip 192.168.1.0 0.0.0.255 192.168.10.0 0.0.0.255
and then call it under the client configuration like you did it before.
Regards
M
11-16-2009 07:15 AM
Hi Chris ,
The only reason i understand here , clients loosing their ability to reach internet while connected through VPN is , as per the current configuration all traffic (including the NetBIOS) is going through the tunnel. So when a packet leaves the client's machine with a source of ip (one of the private ip address from pool defined) and destination 4.2.2.2 (could be any ip on internet) , there is no translation defined for the VPN client's ip address on the router.
Thus, packet coming from the client's machine with a NON-Routable address can't reach the internet for obivous reasons.
As a workaround try this.
access-list 5 per 192.168.1.0 0.0.0.255
(assuming 192.168.1.0 is the subnet VPN clients need to access)
Then,
crypto isakmp client configuration group home
key xxxx
acl 5 <<< binding the acl here.
By creating the acl 5 and binding it in the client configuration, am splitting the traffic for tunnel. In other words, traffic only destined to the subnet 192.168.1.x will go through the tunnel and rest will take the LOCAL ISP path.
Hope this helps...!!!
Regards
M.
11-16-2009 07:33 AM
Mopaul
Thank you for pointing that out! You're suggestion works a treat. I am now able to connect to the web while connected via vpn.
Thanks again for the quick reply.
11-16-2009 07:38 AM
Glad i could help.
Have a good day ahead...!!!
Regards
M
11-16-2009 08:04 AM
It seems that now i am able to connect to the web, i cannot ping my default gateway or internal LAN while connected via vpn, can you see why? Thanks
11-16-2009 08:20 AM
Please try the following configuration step by step:-
access-list 105 deny 192.168.1.0 0.0.0.255 192.168.10.0 0.0.0.255
[to my understanding 192.168.10.x is the VPN client pool]
access-list 105 per ip 192.168.1.0 0.0.0.255 any
access-list 105 per ip 192.168.10.0 0.0.0.255 any
ip nat inside source list 105 interface Dialer1 overload
no ip nat inside source list 1 interface Dialer1 overload
Remove the above statement using the keyword "NO"
access-list 1 permit 192.168.1.0 0.0.0.255
access-list 1 permit 192.168.10.0 0.0.0.255
Let me know how it goes...
Regards
M
11-16-2009 08:56 AM
11-16-2009 06:34 PM
I see the following configuration.
interface Dialer1
description $FW_OUTSIDE$
ip address negotiated
ip access-group 102 in
Surprisingly there is no acl 102 in the configuration , so can you please try to remove the statement " ip access-group 102 in" from interface.
Rest part of the configuration appears to be OK unless am not overlooking at something.
Also,run a continuous ping to 192.168.1.1
from client and let me know if you see decrypts growing in number.You can check this with the command below:
show crypto ipsec sa
That way we can make sure that packet from client is even going through the tunnel, probably then it would be easy to isolate the point of failure.
Just a thought , try this :-
Instead of using a standard "acl 5" for split tunneling , make an extended "acl 182" as
access-list 182 permit ip 192.168.1.0 0.0.0.255 192.168.10.0 0.0.0.255
and then call it under the client configuration like you did it before.
Regards
M
11-20-2009 07:39 AM
Thanks Mopaul
That did the trick, all working great now.
11-20-2009 07:51 AM
Glad i could help.. Have a great day ahead...
Regards
M
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: