VPN Clients can connect but not access inside

[Andy Street]

I haven't needed to use the VPN client for quite a while so I can't say how long this has been an issue for, but my clients can connect successfully but not access any resources. When I ping the inside int. I get replies from the outside int. and pinging any host fails. I'm sure it is an access-list issue, but after a couple of days of web searches and experiments I'm stumped. The VPN seems to be connected to the loopback interface, certainly removing "set ip next-hop 172.16.1.2" had an effect. Oh and I have tested from multiple clients.

Config attached (public IPs and keys removed), assistance will be gratefully received.

[Marvin Rhoads]

So the clients are from pool VPNCLIENTS and the ACL is VPN. That looks all OK.

Your NAT does not appear to exempt the VPNCLIENTS pool though so that may be a problem.

Add deny statements in the ip access-list extended NAT to tell the router not to NAT from 192.192.192.0/24 and 192.168.192.0/24 to 10.0.0.0/24 (VPNCLIENTS).

ip access-list extended NAT 
 deny ip 192.192.192.0 0.0.0.255 10.0.0.0 0.0.0.255
 deny ip 192.168.192.0 0.0.0.255 10.0.0.0 0.0.0.255

Relevant sections of current config:

ip local pool VPNCLIENTS 10.0.0.1 10.0.0.254

ip nat inside source list NAT interface GigabitEthernet0/0 overload

ip access-list extended NAT 
 deny ip 192.192.192.0 0.0.0.255 192.168.254.0 0.0.0.255
 deny ip 192.168.192.0 0.0.0.255 192.168.254.0 0.0.0.255
 permit ip 192.192.192.0 0.0.0.255 any
 permit ip 192.168.192.0 0.0.0.255 any

[Andy Street]

Is there a button for a partially correct answer? Appending those denies to the end of the NAT list (do they need to go before the permits?) means that replies to pings at the inside int now come from it. So progress certainly, however the rest of the LAN is still not accessible. Could I be missing some corresponding allows?

Thanks for your help!

[Marvin Rhoads]

Sorry - I should have mentioned they should go before the permits.

Access-list entries are processed in order from top to bottom. First match ends the ACL logic step and moves on to the next phase in the router's order of operations.

[Andy Street]

Thanks, that rang a vague bell. I'm offsite at the moment and am worried about loosing access if I try that now remotely. Although I expect there is a safe method, as I'm due back tomorrow, I think I'll try then. I'll let you know.

Thanks

[Marvin Rhoads]

Changing ACLs remotely is always a bit tricky.

Doing it wrong is a mistake we seldom make more than once. :)

With an extended ACL you can edit it interactively vs. remove and replace method.

I also sometime (if it's permitted) temporarily open up remote access so that I can ssh directly into the unit vs. coming in via the VPN I'm trying to modify.

And then there's always the trick of starting with the command "reload in 5". In case you lock yourself out, that will reboot the system and revert to the startup-config in case all goes south during your changes.

[Andy Street]

OK my NAT access-list now looks like this:

deny ip 192.192.192.0 0.0.0.255 192.168.254.0 0.0.0.255
deny ip 192.168.192.0 0.0.0.255 192.168.254.0 0.0.0.255
deny ip 192.192.192.0 0.0.0.255 10.0.0.0 0.0.0.255
deny ip 192.168.192.0 0.0.0.255 10.0.0.0 0.0.0.255
permit ip 192.192.192.0 0.0.0.255 any
permit ip 192.168.192.0 0.0.0.255 any

However the problem remains. I can currently access the inside int of the router, but not the rest of the LAN. I've tested to hosts on both internal ranges, with the same result.

Because I'm back onsite, I've been able play with Wireshark. Although I'm inexperienced with it, I can see that the ping requests hit the test host and replies are sent back. 

It feels like we are close to the solution. What next?

[Andy Street]

Hello?

I've spent a few more hours trying to figure this out and I'm still struggling. Anyone?

[Marvin Rhoads]

Try something other than ping. Unless you're inspecting icmp, that won't work by default.

I usually check with a tcp-based protocol like telnet, ssh or opening an RDP session (the latter only for Windows hosts of course).

[Andy Street]

Now I should have mentioned that also tried telnet to our mail server and RDP to multiple hosts (just not with WireShark). I've just tried again to be sure. Something still seems to be preventing traffic entering the tunnel at the router end. If it isn't an access list what else could it be?

[Marvin Rhoads]

Going back to your original posting you mentioned the VPN seems to be terminating on your loopback interface.

That would be very unusual especially considering that interface Lo1 is a private IP address and should not be routable to the distant end. What is showing you that?

Can you check:

show crypto isakmp sa
show crypto ipsec sa

...while the tunnel is up?

[Andy Street]

The reason I thought the loopback int was related (I could be wrong) is that removing the next-hop meant that I could get responses to pings but not other traffic. I figured the next-hop must be there to send traffic to the loopback, that route-map is related, no?  I later restored the config to a point before I started trying to fix it, before posting here.

Test results attached.

[Andy Street]

Has anyone got any last ideas before I go any buy a SMARTnet and file a TAC request?