We help IT Professionals succeed at work.

Cisco ASA Client VPN was working but can no longer access internal network

Steve Bantz
Steve Bantz asked
on
I have a Cisco ASA 5505 that I had set up with client vpn access using Cisco VPN client.  It was authenticating to a radius server on a Windows domain controller and was working just fine allowing me access to my internal networks without troubles.  I got rid of the domain controller that was providing radius auth and I am the only one using it now anyway, so I changed the VPN to use Local accounts on the ASA for authentication.  I created a local account to use.  I am able to connect to the VPN with the local user credentials and authenticate properly. The problem is, I can no longer access the internal network like I used to.  The only thing I changed was how it authenticates ... from RADIUS to Local.  Did I miss something?  I can't ping any hosts internally.  Again, all I did was change how it authenticates the user.
Comment
Watch Question

Do you have a firewall between the Internal network and the ASA 5505?
You mentioned that the RADIUS server was also a domain controller. That means it was probably a DNS server as well. Does pinging internal ip addresses work? If so, it is only your name resolution which fails. Changing the group policy on the firewall to point to a valid DNS server should do the trick.
Steve BantzIT Manager

Author

Commented:
The Asa is the only firewall.  I can't ping any internal ip addresses either.  Before I made the change to the authentication method I could access anything by name or ip.  Now neither works. The DNS server is specified correctly and my client has the correct ip configuration yet no access to the internal network is granted.  Again the only change I made was authenticating to a local database rather than radius.
please post the output from this command (while having a VPN client connected)

packet in inside TCP <internal ip address> 8888 <ip address of VPN client> 80

It should tell us if the internal logic of the firewall forwards the traffic to the client.
Steve BantzIT Manager

Author

Commented:
Well, I used the trace as you suggested and figured out that it was trying to NAT to get to the internal network.  I had to put the nonat statement back in and then I was able to get to all IPs and hostnames I needed.  All I did was change the authentication method from RADIUS to Local so I have no idea why it took the nonat statement out.  That kind of bothers me, but that's why you have backups to reference.  Thanks.