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.

That is interesting about the MTU issue - as when you install the VPN client it reduces the NIC MTU to 1300 - to allow the TCP/IP & Encryption overheads.

I also notice you are using the tcp adjust mss - is there a specific reason why you have set 1412??

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.

So everyting apart from the remote VPN clients is working?? Have you tried changing the IP pool addresses - to a different subnet?

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!

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