cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
747
Views
5
Helpful
10
Replies

Unable to ping through UP L2L VPN.

Hello.

In an L2L VPN, the local endpoint is an ASA5525. The remote side is NATted. There is evidence of packets being encrypted and decrypted on this VPN.

Question: In a vanilla configuration, why am I unable to ping the either the pre/or post NATTed address? (If there is something blocking ping, how do I know/ what could it be?)

Thank you.

2 Accepted Solutions

Accepted Solutions

@jmaxwellUSAF initiated locally from the ASA itself you mean? unlikely unless the ASA interface is specified in the crypto ACL. Test traffic from a device behind the ASA rather than from the ASA.

By default interface ACLs are ignored for traffic traversing a VPN (from inside to outside) if traffic is specified as interesting traffic in the crypto ACL.

Yes, packet-tracer will identify any issues.

View solution in original post

@jmaxwellUSAF so if the packet-tracer syntax simulated a real flow and was correct, then your ASA configuration is possibly correct.

Confirm with the peer that their firewall is not blocking ICMP to the destination and that the device you are pinging does not have a host based firewall that could also block pings from your remote network.

View solution in original post

10 Replies 10

@jmaxwellUSAF run packet-tracer on your ASA to determine if inadvertently blocked by an ACL/VPN filter.

Confirm with the peer that their firewall is not blocking ICMP to the destination and that the device you are pinging does not have a host based firewall that could also block pings.

ASAs confuse me. Will the ASAs default config allow ping traffic to the remote VPN device if the ping is initiated locally? What if the pings are initiated from a device in the internal network?

How do I determine that the ping is not being blocked by the ASA-- do I use Packet tracer?

 

@jmaxwellUSAF initiated locally from the ASA itself you mean? unlikely unless the ASA interface is specified in the crypto ACL. Test traffic from a device behind the ASA rather than from the ASA.

By default interface ACLs are ignored for traffic traversing a VPN (from inside to outside) if traffic is specified as interesting traffic in the crypto ACL.

Yes, packet-tracer will identify any issues.

OK. Packet tracer shows "Allowed" through all its checks with pings sourced from the local endpoint subnet defined in the Tunnel ACL.

But this does not satisfy my final validation-- I would like to achieve successful pings, but I would rather not RDP into the local endpoint subnet server (I would need server admin permissions which I do not have.)

The packet tracer data does not show (something like) "!!!!! success 5 of 5 packets sent successfully."

How can i see successful pings to the remote l2l VPN endpoint?

@jmaxwellUSAF so if the packet-tracer syntax simulated a real flow and was correct, then your ASA configuration is possibly correct.

Confirm with the peer that their firewall is not blocking ICMP to the destination and that the device you are pinging does not have a host based firewall that could also block pings from your remote network.

Quick question-- is there an ASA5525 command that can only show me the names of existing access lists, without showing me all the entries within all the ACLs?

@jmaxwellUSAF show access-list would display all entries, but if you were to apply a filter on "element" that would display the first line only. i.e., show access-list | inc element

access-list OUTSIDE_IN; 3 elements; name hash: 0xe01d8199
access-list DMZ_IN; 2 elements; name hash: 0x229557de

 show runnning-config access-group will list all the ACLs in use.

This was so helpful! Thank you!

From the local ASA that is the local L2L VPN tunnel endpoint, If I ping the L2L remote server, from what local ASA interface and IP address are these pings originating?

@jmaxwellUSAF the outside interface IP address.