Unable to ping remote LAN ip using cisco VPN client for remote access

Answered Question
Jul 8th, 2009

Hi Folks,

I have a site to site VPN constructed using a Cisco 1841 and ASA 5520. The 1841 serve as a spoke and ASA 5520 is the hub. Now I would like to

turn on client remote access VPN on the 1841 with the config attached.For now, I am able to connect successful using the cisco VPN client but unable to ping

10.224.5.5 (cisco switch) or any 10.224.5.x devices. It is also noted that I was able to ping the loopback interface 10.234.1.23. Any idea what could be wrong?

Attachment: 
I have this problem too.
0 votes
Correct Answer by thotsaphon about 7 years 6 months ago

Chai Kok Soon,

What about this? (grin)

!

ip access-list extended nonat

no deny ip 192.168.1.0 0.0.0.255 10.0.0.0 0.255.255.255

deny ip 10.0.0.0 0.255.255.255 192.168.1.0 0.0.0.255

!

!

ip access-list extended [email protected]

no permit ip 192.168.1.0 0.0.0.255 10.0.0.0 0.255.255.255

permit ip 10.0.0.0 0.255.255.255 192.168.1.0 0.0.0.255

Please let us know how things work out

HTH,

Toshi

Correct Answer by xcz504d1114 about 7 years 6 months ago

It looks like your NAT statements are wrong.

So a remote user connects to the fa 0/0 interface, your nonat ACL is applied to that interface, it looks like it is written so that when 10.224.5.0 talks to anything with a deny, then it isn't NAT'd out.

You have a deny statement:

deny ip 192.168.1.0 0.0.0.255 10.0.0.0 0.255.255.255

So what about when the 10.0.0.0 network wants to talk to the 192.168.1.0 network? It will be NAT'd.

Change that deny statement to read:

deny ip 10.0.0.0 0.255.255.255 192.168.1.0 0.0.0.255

I don't believe you need the:

deny ip 192.168.1.0 0.0.0.255 10.0.0.0 0.255.255.255

statement, as the direction is applied going outbound, but i may be wrong, you might want to test both, with it and without it.

HTH,

Craig

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Correct Answer
xcz504d1114 Thu, 07/09/2009 - 08:52

It looks like your NAT statements are wrong.

So a remote user connects to the fa 0/0 interface, your nonat ACL is applied to that interface, it looks like it is written so that when 10.224.5.0 talks to anything with a deny, then it isn't NAT'd out.

You have a deny statement:

deny ip 192.168.1.0 0.0.0.255 10.0.0.0 0.255.255.255

So what about when the 10.0.0.0 network wants to talk to the 192.168.1.0 network? It will be NAT'd.

Change that deny statement to read:

deny ip 10.0.0.0 0.255.255.255 192.168.1.0 0.0.0.255

I don't believe you need the:

deny ip 192.168.1.0 0.0.0.255 10.0.0.0 0.255.255.255

statement, as the direction is applied going outbound, but i may be wrong, you might want to test both, with it and without it.

HTH,

Craig

Correct Answer
thotsaphon Fri, 07/10/2009 - 06:15

Chai Kok Soon,

What about this? (grin)

!

ip access-list extended nonat

no deny ip 192.168.1.0 0.0.0.255 10.0.0.0 0.255.255.255

deny ip 10.0.0.0 0.255.255.255 192.168.1.0 0.0.0.255

!

!

ip access-list extended [email protected]

no permit ip 192.168.1.0 0.0.0.255 10.0.0.0 0.255.255.255

permit ip 10.0.0.0 0.255.255.255 192.168.1.0 0.0.0.255

Please let us know how things work out

HTH,

Toshi

ChaiKokSoon Sun, 07/12/2009 - 16:15

Hi Toshi,

Thanks, the problem has been resolved as you and Craig have pointed out.

ChaiKokSoon Sun, 07/12/2009 - 16:13

Hi Craig,

Thanks for pointing it out and that resolve the problem.Much appreciated.

Actions

This Discussion