Cisco 871 easy vpn setup

Answered Question
Nov 16th, 2009

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.

I have this problem too.
0 votes
Correct Answer by mopaul about 7 years 3 weeks ago

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

Correct Answer by mopaul about 7 years 3 weeks ago

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (4 ratings)
Loading.
Correct Answer
mopaul Mon, 11/16/2009 - 07:15

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.

chris.bourroughs Mon, 11/16/2009 - 07:33

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.

mopaul Mon, 11/16/2009 - 07:38

Glad i could help.

Have a good day ahead...!!!

Regards

M

chris.bourroughs Mon, 11/16/2009 - 08:04

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

mopaul Mon, 11/16/2009 - 08:20

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

chris.bourroughs Mon, 11/16/2009 - 08:56

I have applied the config but still have the same issue, i cannot ping my lan on it's 192.168.1.x addresses.

My vpn client pool is 192.168.10.x as you thought.

I have attached the running config now i have applied the changes.

Thanks.

Attachment: 
Correct Answer
mopaul Mon, 11/16/2009 - 18:34

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

mopaul Fri, 11/20/2009 - 07:51

Glad i could help.. Have a great day ahead...


Regards

M

Actions

This Discussion