cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5471
Views
10
Helpful
9
Replies

Cisco 871 easy vpn setup

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.

2 Accepted Solutions

Accepted Solutions

mopaul
Cisco Employee
Cisco Employee

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.

Mohit Paul CCIE-Security 35496 P.S Please do rate this post if you find it helpful to make it easier for others seeking answers to similar queries

View solution in original post

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

Mohit Paul CCIE-Security 35496 P.S Please do rate this post if you find it helpful to make it easier for others seeking answers to similar queries

View solution in original post

9 Replies 9

mopaul
Cisco Employee
Cisco Employee

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.

Mohit Paul CCIE-Security 35496 P.S Please do rate this post if you find it helpful to make it easier for others seeking answers to similar queries

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.

Glad i could help.

Have a good day ahead...!!!

Regards

M

Mohit Paul CCIE-Security 35496 P.S Please do rate this post if you find it helpful to make it easier for others seeking answers to similar queries

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

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

Mohit Paul CCIE-Security 35496 P.S Please do rate this post if you find it helpful to make it easier for others seeking answers to similar queries

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.

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

Mohit Paul CCIE-Security 35496 P.S Please do rate this post if you find it helpful to make it easier for others seeking answers to similar queries

Thanks Mopaul

That did the trick, all working great now.

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


Regards

M

Mohit Paul CCIE-Security 35496 P.S Please do rate this post if you find it helpful to make it easier for others seeking answers to similar queries
Getting Started

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: