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

Answered Question
Dec 11th, 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.

I have this problem too.
0 votes
Correct Answer by raga.fusionet about 2 years 4 months ago

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

  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 4.3 (4 ratings)
andrew.prince@m... Sun, 12/11/2011 - 10:55

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 Sun, 12/11/2011 - 10:57

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

Correct Answer
raga.fusionet Sun, 12/11/2011 - 16:49

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 Sun, 12/11/2011 - 17:14

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 Sun, 12/11/2011 - 17:18

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

nickhesson Thu, 02/09/2012 - 11:46

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

varinsin Thu, 02/09/2012 - 13:00

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

nickhesson Thu, 02/09/2012 - 17:32

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

varinsin Thu, 02/09/2012 - 20:51

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

nickhesson Fri, 02/10/2012 - 08:46

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

felixduivenvoorden Thu, 03/29/2012 - 07:58

Thank you!

This was for me a solution to manage my firewall again behind a VPN.



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.



-Felix

Actions

Login or Register to take actions

This Discussion

Posted December 11, 2011 at 10:44 AM
Stats:
Replies:11 Avg. Rating:4.33333
Views:18268 Votes:0
Shares:1
Categories: ASA
+

Related Content

Discussions Leaderboard