vpn cant connect to local network

Unanswered Question
Jun 7th, 2008
User Badges:

I posted this in the remote access forum but this forum is probaly more suited for my problem.


I have been trying to get an 857w setup for VPN access for remote workers in my business. Please don't be too hard on me this is my first time setting up a cisco router and ive had to battle with it pretty much every step of the way. Here is my current problem:


remote vpn user "Cisco Systems VPN Client 4.8.02.0010" can connect, gets an ip address over VPN (also has an internal 192. ip address from her dsl modem)the gateway and dns servers are assigned as if she were here. but she cannot make use of any of the network shares in the main office. pinging the gateway or any other 10.10. ip results in timeouts. I have seen similar solutions to this type of problem witch im thinking might be access-list related. but I havent been able to implement them in my situation.

Any help on this would be greatly appreciated. Also any general advice on my running config would be helpful. The mtu settings in particular have given me a lot of trouble.


Thanks



Attachment: 
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.

Looks like the issue is in your nat rules. You are natting the return VPN traffic - try re-writing the access list from:-


access-list 100 remark SDM_ACL Category=19

access-list 100 permit ip 10.10.10.0 0.0.0.255 any

access-list 100 permit ip any any

access-list 100 deny ip 127.0.0.0 0.255.255.255 any

access-list 100 deny ip host 255.255.255.255 any


to



access-list 100 remark SDM_ACL Category=19

access-list 100 deny ip 10.10.10.0 0.0.0.255 10.10.10.0 0.0.0.255

access-list 100 permit ip 10.10.10.0 0.0.0.255 any

access-list 100 permit ip any any

access-list 100 deny ip 127.0.0.0 0.255.255.255 any

access-list 100 deny ip host 255.255.255.255 any


Test and troubleshoot.


HTH.

soyeltoby Sun, 06/08/2008 - 08:10
User Badges:

Thanks for the response! I made the changes you suggested to the access list. Unfortunately I still have basically the same issue.


The client connects, recieves an ip (10.10.10.200), along with assigning the gateway, dns, etc.

connections to network shares cannot be restored.

ping to 10.10.10.1 (the gateway/vpn server 857w) resulted in 2 timeouts and 2 responces from the public ip of the 857w.

ping to 10.10.10.175 (NAS) resulted in 4 timeouts


I also ran tests on the vpn using SDM, and I let it make the changes it suggested. First was the access list

access-list 100 deny ip any host {entry for each ip in the vpn dhcp pool}


The second change was after testing the tunnel I got this report:

A ping with data size of this VPN interface MTU size and 'Do not Fragment' bit set to the other end VPN device is failing. This may happen if there is a lesser MTU network which drops the 'Do not fragment' packets.

1)Contact your ISP/Administrator to resolve this issue. 2)Issue the command 'crypto ipsec df-bit clear' under the VPN interface to avoid packets drop due to fragmentation.


I set that crypto command to dialer1


Doing the VPN test again told me this:

Failure Reason(s)

The request from the Easy VPN Remote client 75.xxx.xxx.xxx received and server is responding to the client.

Recommended Action(s)

Ensure that the correct key or digital certificate is configured in the Easy VPN Remote client. This one I had no idea what it was talking about.


After making those changes the situation is basically the same. Also this is going over a 3Mb/512k adsl connection with no other traffic so the connection should be enough


My pcf file for the remote connection is fairly simple and I will attach a cleaned version of it along with my new running conf although I believe I listed all the changes since the last version.






Attachment: 
soyeltoby Mon, 06/09/2008 - 04:13
User Badges:

Initially I was having a problem with my internet connectivity. At that time I think i had the dialer set to 1492 mtu and everything else was at 1500. The problem I was having with web pages partly loading and loading more on refreshing got me the diagnosis of my mtu size being too large. I did the ping test and found that 1452 was the largest size getting through. Which was the size recommended by several PPPoE troubleshooting posts.

So I knew I needed to adjust some of my mtu settings, but tbh I had no idea where I should set the mtu.


Also I wasn't sure if my mtu settings should be consistent across the different interfaces. I went with trying to basically set a global setting of 1452 (excluding the remote vpn clients who got their nic set to 1300.)

The tcp adjust mss came from http://www.cisco.com/en/US/tech/tk175/tk15/technologies_tech_note09186a0080093bc7.shtml

I dont really understand the functional difference in mtu or mss but it seems the mss should always be 40 lower than the mtu (from the end of the linked article). Like I said I'm not sure if I should have only set the mtu on the dialer interface.

All that being said after I set all the mtu's web surfing at the office seems to be doing fine.

soyeltoby Mon, 06/09/2008 - 11:45
User Badges:

Yes everything is working except vpn client's cant access anything on the network. should I change the subnet for both the vpn and the local client pools? and something like 255.255.254.0 would work?


i have "DHCP Pool" called "sdm-pool" for interface BVI 1 10.10.10.1-100


and "Local Pool" called "dyn-pool" used by my vpn connections 10.10.10.200-230


Thanks again for your help on this. I'm sorry if I wasn't clear before that the vpn clients are the only ones with issues.


To start with I would just chabge the IP pool for the VPN clients. I would choose something in the range 172.16.x.x or 192.168.x.x. Is this device your Primary layer 3 routing device? Is so cool - if not, you will have to put a static route for the new ip subnet pointing back!

soyeltoby Tue, 06/10/2008 - 13:39
User Badges:

Ok I changed the dynpool to:

ip local pool dynpool 172.16.1.10 172.16.1.15


sdm added this to the acl

access-list 100 deny ip any host 172.16.1.10

access-list 100 deny ip any host 172.16.1.11

access-list 100 deny ip any host 172.16.1.12

access-list 100 deny ip any host 172.16.1.13

access-list 100 deny ip any host 172.16.1.14

access-list 100 deny ip any host 172.16.1.15


access-list 101 permit ip host 172.16.1.10 any

access-list 101 permit ip host 172.16.1.11 any

access-list 101 permit ip host 172.16.1.12 any

access-list 101 permit ip host 172.16.1.13 any

access-list 101 permit ip host 172.16.1.14 any

access-list 101 permit ip host 172.16.1.15 any


one thing i noticed was the new gateway being assigned was 172.16.0.1 which im not sure if thats a problem or not. Attached is the results from ipconfig etc. from one of my vpn clients



Actions

This Discussion