Cannot ping across a tunnel

[WStoffel1]

What am I missing?  I have a 5540 which has a static route to 192.168.157.0 255.255.255.0 and I'm able to ping addresses on that network:

ping 192.168.157.190

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.157.190, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

My 5540 has a L2L tunnel to a 5505 and everything is working.  However I'm unable to ping the same 192.168.157.190 address, it just times out.

Where should I start looking?

Thanks...

[Jouni Forss]

Hi,

First need to clarify where you are doing the ICMP that is working and where you are doing it when its not working? Is this done on the ASA in both cases?

If you are simply sending ICMP echo on the local ASA then naturally it uses the interface IP address of the closest interface towards that network as the source and its likely that it will receive a reply.

On the remote site however if you are sending ICMP Echo directly from the ASA then the ASA will use the "outside" interface as the source IP address for the ICMP Echo which will naturally fail as it will head out to the Internet instead of the L2L VPN between the sites.

If the above was not the case then will have to look at something else.

You say that everything is working? Are you saying that some TCP connections that are formed through the L2L VPN are generally working but the ICMP to this single host is timing out from the remote site? Is it possible that the actual host which is pinged is blocking the ICMP echo?

Is there any restrictions on either end which would prevent ICMP echo being sent?

Naturally you can always configure a traffic capture on the ASA closes to the host being pinged and confirm if you are seeing the initial ICMP echo from the remote site and if you are seeing the ICMP Echo reply back from the host. This should already narrow down the troubleshooting.

- Jouni

[WStoffel1]

It's amazing when you're looking at everything in the middle of an issue how easy it is to forget to put in all the necessary info so someone else can understand:)

Yes i'm talking about pinging from the asa's themselves in both cases.

Ultimately i would like to be able to just ping that one host (192.168.157.190) from the remote end of the tunnel from the 5505 itself (while I'm SSH'd in).

192.168.157.190 is an address that's local to the 5540, so it pings out that interface as the source, and 190 responds, its a windows server on that segment.

My problem is I dont have access to the windows workstation on the remote end of the tunnel, which is 172.29.10.100.  In theory since that person can get to the server, tunnel's up, access lists are correct, which is what i meant by its all working.

I was just trying to test something when there was an issue and realized i could not ping that 192.168.157.190 host from the remote ASA.  So it's really just for my own education. 

I thought debugging icmp would help (this is the remote 5505, it doesnt reach the local 5540):

remote# debug icmp trace 255

debug icmp trace enabled at level 255

remote# ping

Interface: inside

Target IP address: 192.168.157.190

Repeat count: [5]

Datagram size: [100]

Timeout in seconds: [2]

Extended commands [n]: y

Verbose? [no]: y

Validate reply data? [no]: y

Data pattern [0xabcd]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.157.190, timeout is 2 seconds:

Reply data will be validated

Unknown echo response type 0x20

Unknown echo response type 0x20

Unknown echo response type 0x20

Unknown echo response type 0x20

Unknown echo response type 0x20

Success rate is 0 percent (0/5)

remote# traceroute 192.168.157.190

Type escape sequence to abort.

Tracing the route to 192.168.157.190

1  10.239.64.1 20 msec 0 msec 10 msec

2  24.24.16.44 20 msec 0 msec 10 msec

3  24.58.149.192 10 msec 10 msec 10 msec

4   *  *  *

5   *  *

remote# sh run icmp

icmp unreachable rate-limit 1 burst-size 1

remote# sh run policy-map

!

policy-map type inspect dns preset_dns_map

parameters

  message-length maximum 512

policy-map global_policy

class inspection_default

  inspect dns preset_dns_map

  inspect ftp

  inspect h323 h225

  inspect h323 ras

  inspect netbios

  inspect rsh

  inspect rtsp

  inspect skinny

  inspect esmtp

  inspect sqlnet

  inspect icmp

  inspect sunrpc

  inspect tftp

  inspect sip

  inspect xdmcp

packet-tracer input inside tcp 172.29.10.100 32000 192.168.157.190 443 det

Result:

input-interface: inside

input-status: up

input-line-status: up

output-interface: outside

output-status: up

output-line-status: up

Action: allow

So traffic is allowed.  I know I'm just missing something probably blatantly obvious

I'll be able to do a packet cap later today...

Thank you!

[Jouni Forss · Accepted solution]

Hi,

Well the only thing I can think of is including the "outside" IP address of the remote ASA in the encryption domain of the L2L VPN connection between the ASAs.

Then the ICMP source directly from the remote ASA would probably be encrypted/encapsulated on the L2L VPN and reach the local sites server.

On the local ASA you would have to do the same addition of the remote ASA public IP address to the L2L VPN encryption domain. You would also have to configure NAT0 between the local network and the destination public IP address.

Naturally depending on where you are initiating connections to the remote ASA this might be a problem. If you are initiating management connections from OUTSIDE both of these networks then you shouldnt run into any problems but if you are managing the remote ASA from the local network then naturally those connections would start to go through the L2L VPN rather than the Internet without VPN.

- Jouni

[WStoffel1]

ouch, the remote end outside address is not static.  i was convinced i was simply missing an icmp config. 

"Then the ICMP source directly from the remote ASA would probably be encrypted/encapsulated on the L2L VPN and reach the local sites server." as you mention was the big piece here i was overlooking.

As always thanks for your time, i believe this one to be a big lesson in futility.  I will instruct the user to ping that address from the workstation should she think theres a connection problem in the future.  Frankly shes a real pain and i avoid talking to at all costs

Thanks again!