Solved: ASA - upgrade to 8.4, unable to ping inside interface over IPSec VPN

joevivona · ‎12-11-2011

we have configured a 5 site, site-to-site VPN scenario. Over the past week, we've upgraded 2 of the ASA 5505 devices to 8.4.2. Prior to the upgrade our monitoring software would ping the inside interface of the remote devices to confirm the VPN tunnels were established, along with some of the remote equipment addresses and the outside of the ASA. While we were on 8.2, remote equipment was successful in pinging the inside interface. After we upgraded to 8.4.2 we are unable to ping that interface. We have looked at the logs and we are seeing the ICMP traffic listed in the log, but the remote equipment is not receiving the icmp traffic back. We can ping the inside interface successfully from local equipment and the outside interface successfully from remote equipment. In addition we can ping equipment behind both devices in both directions successfully.

we also cannot remotely manage the device through the VPN tunnel

So, net/net is:

ASA #1 inside 10.168.107.1 (running ASA 8.2)

ASA #2 inside 10.168.101.1 (running ASA 8.4)

Server 1 (behind ASA #1) 10.168.107.34

Server 2 (behind ASA #2) 10.168.101.14

Can ping Server 1 to Server 2

Can ping Server 1 to ASA 1

Can ping Server 2 to ASA 2

Can ping Server 2 to Server 1

Can ping Server 2 to ASA 1

Can ping ASA 2 to ASA 1

cannot ping ASA 1 to ASA 2

cannot ping Server 1 to ASA 2

cannot get to ASA 2 https interface for management, nor can the ASDM software

Here's the config on ASA 2 (attached).

Any thoughts would be appreciated.

raga.fusionet · ‎12-11-2011

Hey Joseph,

Most likely you are hitting this bug:

CSCtr16184 Bug Details

To-the-box traffic fails from hosts over vpn after upgrade to 8.4.2.

Symptom:
After upgrading the ASA to 8.4.2, all management traffic to-the-box(including
icmp/telnet/ssh/ASDM) from hosts over the VPN (L2L or Remote ACcess VPN) may
fail when destined to the management-access interface IP address.

Conditions:
1. Issue is observed if ASA is on 8.4.2. Not observed on 8.4.1.
2. Users directly connected to the internal interfaces face no issues with
icmp/telnet/ssh/asdm to their respective interfaces.

Workaround:
The problem can be traced to a Manual NAT statement that overlaps with the
management-access interface IP address. The NAT statement must have both the
source and destination fields. Adding the "route-lookup" keyword at the end of
the NAT statement resolves the issue.

Ex:
ASA's Management-Access Interface IP address is 192.168.1.1.

! Overlapping NAT statement:
nat (inside,outside) source static obj-192.168.1.0 obj-192.168.1.0 destination
static obj-vpn obj-vpn

! New Statement:
nat (inside,outside) source static obj-192.168.1.0 obj-192.168.1.0 destination
static obj-vpn obj-vpn route-lookup

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtr16184

HTH,

Raga

View solution in original post

andrew.prince · ‎12-11-2011

make sure you still have "management-access inside" configured ( I have not looked a the attachment) ignore my post if it is configured.

Sent from Cisco Technical Support iPad App

joevivona · ‎12-11-2011

Andrew - thanks. I made sure it was there, plus just in case I deleted everything and re-added it (plus the icmp allow).

raga.fusionet · ‎12-11-2011

Hey Joseph,

Most likely you are hitting this bug:

CSCtr16184 Bug Details

To-the-box traffic fails from hosts over vpn after upgrade to 8.4.2.

Symptom:
After upgrading the ASA to 8.4.2, all management traffic to-the-box(including
icmp/telnet/ssh/ASDM) from hosts over the VPN (L2L or Remote ACcess VPN) may
fail when destined to the management-access interface IP address.

Conditions:
1. Issue is observed if ASA is on 8.4.2. Not observed on 8.4.1.
2. Users directly connected to the internal interfaces face no issues with
icmp/telnet/ssh/asdm to their respective interfaces.

Workaround:
The problem can be traced to a Manual NAT statement that overlaps with the
management-access interface IP address. The NAT statement must have both the
source and destination fields. Adding the "route-lookup" keyword at the end of
the NAT statement resolves the issue.

Ex:
ASA's Management-Access Interface IP address is 192.168.1.1.

! Overlapping NAT statement:
nat (inside,outside) source static obj-192.168.1.0 obj-192.168.1.0 destination
static obj-vpn obj-vpn

! New Statement:
nat (inside,outside) source static obj-192.168.1.0 obj-192.168.1.0 destination
static obj-vpn obj-vpn route-lookup

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtr16184

HTH,

Raga

joevivona · ‎12-11-2011

Luis - I guess I need to pay more attention to that bug database... That solved it.

OK for anyone else who comes in and reads this, to resolve it you have to do one of 2 things

1 - if your NAT rules are duplicated, but one is inside, outside and one is inside, any - just delete the inside, any rule and then change the inside, outside to do the route lookup

2 - if your NAT rule does not allow you to do route lookup, then one end of your interface is set to any as the interface. Change that to the correct interface and then you can set route lookup.

thanks to everyone....

raga.fusionet · ‎12-11-2011

Sure man, I'm glad to hear that I was able to help and thanks for sharing the solution you used

nickhesson · ‎02-09-2012

I'm have the same problem but my NAT statment already had the route-lookup. My problem is from my 8.4(2) ASA i can't ping anything other then the inside interface of the remote ASA.

L2L VPN bewteen 8.4 (2) ASA1 to 8.2 (5) ASA2.

From ASA2 I can ping everything, inside interface ASA1 and any host on the inside network.

From ASA1 I can ping inside interface ASA2, but can not ping any hosts on the inside network.

ASA1 Config:

nat (inside,outside) source static inside_NET inside_NET destination static TXD_NET TXD_NET no-proxy-arp route-lookup

object network obj_any

nat (inside,outside) dynamic interface

access-list inside_OutsideACL extended permit icmp any any

access-group inside_OutsideACL in interface outside

management-access inside

What am i missing? Thanks for your time and help,

Nick

Varinder Singh · ‎02-09-2012

You need to check the confgiuration for Nat exempt on ASA2.

Can you paste the output for the following command?

Sh run nat

vpn traffic should be part of nat exempt list

nat (inside) 0 access

where nonat includes the interesting traffic that needs to be exempted.

Varinder

Regards, Varinder P.S. Please mark this post as 'Answered' if you find the above information helpful so that it brings goodness to other community users

nickhesson · ‎02-09-2012

ASA2# sh run nat

nat (inside) 0 access-list nonat

nat (inside) 1 0.0.0.0 0.0.0.0

ASA2# sh run access-list nonat

access-list nonat extended permit ip inside_NET 255.255.255.0 PS_NET 255.255.255.224

This is the ACL line for the site. On ASA2 is were the problem can be?

Thanks,

Nick

Varinder Singh · ‎02-09-2012

Yes problem is most likely with ASA2.

You need to try these things:

1. Apply capture on inside interface of ASA2

access-list cap permit ip host INside_host host PS-net-host

access-list cap permit ip host PS-net-host host INside_host

Capture cap interface inside access-list cap

sh capture cap

it will show if there is any return packet for PS-net

2 You might want to check route on inside core network for PS_NET. It should be pointing towards inside of ASA2

Let me know if it helps

Varinder

Regards, Varinder P.S. Please mark this post as 'Answered' if you find the above information helpful so that it brings goodness to other community users

nickhesson · ‎02-10-2012

Funny story. Yesterday shortly after my reply back to you on here, I get an email saying that more then half the people still do not have access. But yet the IPSec sa are created on both sides. Hmm... Well it was the local clients pointing to a different router, we added the route there. And that fixed my problem too.

So you niled it with number 2. That was a waste of 2 hours, when it wasn't even my fault!

Thanks for the support,

Nick

bmurray · ‎10-01-2016

This fixed a problem I had with version asa916-k8.bin

Freemen · ‎04-24-2017

Thanks my case i miss out this command.

When using VPN, you can allow management access to an interface other than the one from which you entered the ASA (see the management-access command). For example, if you enter the ASA from the outside interface, the management-access feature lets you connect to the inside interface using ASDM, SSH, Telnet, or SNMP; or you can ping the inside interface.