Source Ping on ASA

[wr3500]

Yeah I know this has been covered already. I have the following issue. I have a two segments on the firewall, behind these 2 segments I have two L3 devices. VL622 is the higher security interface at 80 while VL621 is lower at 70.

I have a static:
static (VL622,VL621) 10.100.104.128 10.100.104.128 netmask 255.255.255.128

I have a source in VL621 I need to have communicate with a dest in VL622. source is 10.100.162.45, dest is 10.100.104.141. From the ASA I can ping both hosts. ACLS for both VL622 and VL621 are ip any  because these guys are basically mainframe DMZs.

When 10.100.162.45 (VL621) attempts to open a connection to 10.100.104.141 (VL622) the cap I have running shows just the SYN. Logs show syn-timeout. Traffic is from VL621 to VL622 on TCP 5150

VL621 FW IP - 10.100.100.141/29

VL622 FW IP - 10.100.100.149/29

Route to the L3 devices behind it as follows:

S    10.100.104.128 255.255.255.128 via 10.100.100.145, VL622

S    10.100.162.0 255.255.255.0 [1/0] via 10.100.100.137, VL621

Long story short I tried a source ping as follows:

MAFATK22F# ping VL621 10.100.104.141 <-host on VL621
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.14.104.141, timeout is 2 seconds:
?????
Success rate is 0 percent (0/5)

It times out. Does the ASA really allow a source ping. Because it should seem to me that with routes configured as they are that should be doable. Basically I should be able to ping from one firewall interface through another and then get my response from the host on the other end of VL622.
The L3 devices behind the firewalls on VL621 and 622 respecitively default route back to another interface on the firewall at 10.100.100.16/28

After all this long winded description covering the above, I guess the question boils down to I want to ping from the VL621 interface 10.100.100.141 and get a response from 10.100.104.141 which is behind VL622

Thanks

[Panos Kampanakis · Accepted solution]

The answer to your question is no. The firewall will not allow icmp echoes or echo replies to a far end interface. In other words if you ping the firewall behind the inside interface then you can only ping the inside. Now, if you source a ping from the inside and the destination is the outside, when the reply is coming back from the outside and will try to come to the inside (far end) the firewall will not allow it. So that is why you are seeing what you are seeing with the source ping.

Now, as for your issue, if you are opening a conn from 621 and you see it leaving the 622 interface, then your issue is routing. Probably the 622 doesn't have a route back to 621 through the firewall. As a test, try to translate the host behind the 621, translate it on the firewall and make him look like a 622 ip address (if you are pinging also make sure icmp inspection is enabled). And you will see it will work...

I hope it helps.

PK

[wr3500]

I figured that would be the case. Makes me miss working on routers sometimes.

As far as the issue I am having goes I'll put your recommendations to a test. Thanks for responding.

[Panos Kampanakis]

Let us know if it solves the issue.

PK

[Maykol Rojas]

Here is the document from Cisco that states that you cannot ping the far end interface

"For  security purposes the security appliance does not support far-end  interface ping, that is pinging the IP address of the outside interface  from the inside network"

http://www.cisco.com/en/US/docs/security/asa/asa71/configuration/guide/trouble.html

Bit old but same thing applies.

Cheers

Mike

[wr3500]

Yeah I know. By design but it kind  kills a troubleshooting tool for firewall guys who can't get their routing and switching peers invovlved and are troubleshooting remotely on an issue with an end customer who isn't alway IP savvy. Would be nice if it was something that could be turned on/off as required from a CLI perspective. A feature reserved for enable 15.

Anyway thanks for the sounding board. Sometimes it helps to bounce stuff off of others when you have gone too far down the rathole.

[wr3500]

Funny thing happened on the way to the ping desitination, which by the way is a mainframe that happens to be doing RIP back to the L3 devices between the firewalls and mainframe. We suspect that the mainframe sees a better route in its own table. We tried what you recommeneded but with a twist and without the nat. The ping and trance passed all the way through. We basically used another another segment on the router and did the source ping there. We got the expected result.

Thanks.

[jumora]

Now, if you source a ping from the inside and the destination is the  outside, when the reply is coming back from the outside and will try to  come to the inside (far end) the firewall will not allow it. So that is  why you are seeing what you are seeing with the source ping.

Not actually correct, the ASA will not even forward the packet and just print out the next message:

%ASA-6-110003: Routing failed to locate next hop for icmp from NP Identity Ifc:192.168.2.1/0 to inside:4.2.2.2/0