12-11-2011 10:44 AM - edited 02-21-2020 05:45 PM
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.
Solved! Go to Solution.
12-11-2011 04:49 PM
Hey Joseph,
Most likely you are hitting this bug:
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 |
HTH,
Raga
12-11-2011 10:55 AM
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
12-11-2011 10:57 AM
Andrew - thanks. I made sure it was there, plus just in case I deleted everything and re-added it (plus the icmp allow).
12-11-2011 04:49 PM
Hey Joseph,
Most likely you are hitting this bug:
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 |
HTH,
Raga
12-11-2011 05:14 PM
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....
12-11-2011 05:18 PM
Sure man, I'm glad to hear that I was able to help and thanks for sharing the solution you used
02-09-2012 11:46 AM
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
02-09-2012 01:00 PM
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
02-09-2012 05:32 PM
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
02-09-2012 08:51 PM
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
02-10-2012 08:46 AM
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
10-01-2016 09:58 AM
This fixed a problem I had with version asa916-k8.bin
04-24-2017 10:19 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide