Should an inside host be able to ping the ASA DMZ interface IP?

[Joseph Da Rosa]

Simple question (I hope): I've got an ASA with an IP address of 10.1.1.1 on its inside interface and an IP address of 10.6.6.6 on its DMZ interface.  I have an inside host, 10.1.1.2, which is able to ping the ASA's inside IP of 10.1.1.1.  Should this host also be able to ping the ASA's DMZ IP of 10.6.6.6?

What I'm seeing is that it can't.  When I ping the ASA DMZ IP of 10.6.6.6 from the host at 10.1.1.2, I get an error like the following on the ASA:

   %ASA-6-110002: Failed to locate egress interface for ICMP from inside:10.1.1.2/63320 to 10.6.6.6/0

So the ASA says it can't find the egress interface for 10.6.6.6--even though 10.6.6.6 is its own interface IP address.  And this happens when I try to ping *any* of the ASA's other interface IPs from 10.1.1.2.  The only interface IP I can ping from an inside host is the inside IP address (10.1.1.1).  By the way, the host at 10.1.1.2 *can* ping any other hosts on the DMZ network (e.g. 10.6.6.7, 10.6.6.8, and so on)...it's just the ASA interface IP of 10.6.6.6 that it can't ping.

I'm guessing this is just a limitation of the ASA (I seem to remember the same limitation on the PIX as well); pinging the "other side" of interfaces works on routers, but doesn't seem to work on ASAs.  If anyone can verify that one way or another I'd appreciate it.

[Joseph Da Rosa]

Found the answer:

"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."

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

Sure wish the ASA would give a better/less misleading error in this situation than "Failed to locate egress interface for ICMP", but that's what we're stuck with.

[Julio Carvajal]

Hello,

Exactly, you will not be able to ping a far-end interface ( Security desing)

Please mark the question as answered so future users can learn from this

[Joseph Da Rosa]

Despite Cisco's explanation in that document (and what you've said), I don't see how this has anything to do with security; it seems to me it's more a limitation of the ASA that's been carried over from the PIX.  The very fact that the error message points to a packet routing problem seems to me to be evidence that this is just an implementation shortfall that's being explained away as a feature.

If someone has an explanation for how this improves security, I'd like to hear it.  Otherwise, I'd like to see Cisco remove this limitation from the ASA code, since it's unintuitive, confusingly signposted in terms of the error it generates, and--if Internet searches are any indication--has cost a lot of people a lot of time trying to figure out why it doesn't work.

[Julio Carvajal]

What if you just want to permit access to the ASA on the inside interface ( so some internal users can access it from their INTERNAL PC'S) so we enable SSH,ASDM access on the inside interface of the box, and then automatically DMZ  users ( GUEST USERS)  try to access it and they connect succesfully!!!

Do you see the security vulnerability here???? I mean the ASA can do plenty of stuff ( A huge amount of stuff), if this were a limitation don't you think developers could have already fixed this??

I do understand you, I got the same confusion at the beginning of my ASA journey but my friend this is how the ASA behaves and will behave until the end of times .

So any kind of traffic going to a distant, far-end interface will not be accepted by the ASA

[Joseph Da Rosa]

Thanks for the response, but it's not the beginning of my ASA journey; I've been doing PIX/ASA work for well over a decade.

Do you see the security vulnerability here????

Nope, sorry, but your scenario doesn't follow from the premise.  First, I've only mentioned ICMP, and second, what you're talking about would require that the ASA abandon every other security measure it uses; you're apparently thinking "if they allow A they'd have to allow B and C and D as well!", but that's not what I (or any of the many other people I've seen ask about this) have suggested.

We're talking here solely about why the ASA doesn't support ICMP from inside hosts to the other interface IPs (I mentioned DMZ, but people typically ask about outside).  A reasonable limitation to put on that would be that ICMP is only implicitly allowed from higher security interfaces to lower security interfaces, and obviously it should be subject to the ASA's entire regimen of access lists, icmp statements, etc.  I don't see any security issue whatsoever in allowing inside hosts to ping the outside interface IP, assuming that that access is allowed by all the standard ASA access control mechanisms.

I mean the ASA can do  plenty of stuff ( A huge amount of stuff), if  this were a limitation  don't you think developers could have already  fixed this??

Thanks, that's the best one I've heard all day.

Consider that the error message above was "%ASA-6-110002: Failed to locate egress interface for ICMP from inside:10.1.1.2/63320 to 10.6.6.6/0".  That in itself is practically a bug, since the ASA should never "fail to locate" one of its own interface IPs.  If this is designed behavior, the ASA should generate a meaningful message like "Far-end interface traffic rejected for ICMP from inside:10.1.1.2/63320 to dmz:10.6.6.6/0".  The "Failed to locate egress interface" message makes it seem likely that this is just a limitation of the route lookup  code--possibly a remaining artifact of the PIX's inability to route between interfaces.

[Julio Carvajal]

Hello,

Okay not to offend but if you have a lot of experience with the ASA/PIX you should already know this is the expected behavior and there is nothing we can do to change that as managment traffic ( Including ICMP ) will not be allowed to a distant interface.

The ASA is a firewall so apart to split the broadcast domain as any other L3 device it will also enquire you to try ( test connectivity to the box ) only from the directly connected interface,

I mean I have worked on several cases with this particular scenario , question, doubt ,etc,etc, etc and it does not matter if its from outside to inside, inside to outside, dmz to inside, inside to dmz the limitation based on the security meassure is there ( I am not inventing this)

Taken from cisco documentation:

You are not able to ping interfaces on the "far side" of the PIX or ASA in any version

Now if we were talking about VPN we could do the following

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a0080094e8a.shtml#topic0

So you are to test connectivity by pinging another host ( not the ASA interface Ip address) on the other interface,

Hope I could help

[Joseph Da Rosa]

Yes, I know this has been expected behavior in the past (I said as much in my initial posting).  The reason why it threw me in this case was that the extremely misleading error message from the ASA points to a route lookup failure; that's why it seemed possible that recent ASA releases had lifted this limitation, and I was just running into some other issue that was preventing it from working.

I didn't say you're inventing this (and there's no need to cite Cisco documentation for it when I've already done so myself).  But you're also not offering a reasonable explanation as to how it increases security.  That's fine--I can live with it just being a limitation of the ASA just as it was a limitation of the PIX.  Regardless, I'd say Cisco should change the error message that's generated in this case.

[Julio Carvajal]

Hello,

Agree with you on the fact that the error message could be more specific ( people may want to read packet being dropped as traffic to a far-end interface is not allowed ) but the log:

%ASA-6-110002: Failed to locate egress interface for ICMP from inside x.x.x.x to y.y.y.y

is also accurate as based on the Accelerated Security Path algorightm used by the ASA , it will not be able to locate the egress interface as it's written on it's code that traffic to a far-end interface cannot happen, it's receiving invalid traffic.

Anyway I hope I could help you on this,

[david.tran · Accepted solution]

If you want to be able to ping the far-end IP of a firewall, goes with Checkpoint Firewall

[Joseph Da Rosa]

Great answer.

[Julio Carvajal]

Agree with you on the fact that the error message could be more specific ( people may want to read packet being dropped as traffic to a far-end interface is not allowed ) but the log:

%ASA-6-110002: Failed to locate egress interface for ICMP from inside x.x.x.x to y.y.y.y

is also accurate as based on the Accelerated Security Path algorightm used by the ASA , it will not be able to locate the egress interface as it's written on it's code that traffic to a far-end interface cannot happen, it's receiving invalid traffic.

Also a good answer

Now if you have a contract ( A Valid Contract with us) you can contact your Account Manager in order to open an enhacement request, that is not a problem for us.

Now if you think that just because ICMP traffic to a particular host does not work and that is enough to move forward to another company ( whatever the brand is ) then yes you should go to Checkpoint,etc,etc.

Now as you have 10 years working with CISCO ASA's I dont think you are going somewhere else as you know the ASA can do a lot of stuff , the rest of the brands can't

Anyway have a good one my friend

[david.tran]

jcarvaja wrote:
 
Now as you have 10 years working with CISCO ASA's I dont think you are going somewhere else as you know the ASA can do a lot of stuff , the rest of the brands can't

can you tell me which features that ASA can do that other firewall brands can not?  I would like to know

[Julio Carvajal]

Check on the CSC, there are a lot of posts refering to that specific topic

I am studying right now so I cannot focus on the CSC,

Kind Regards,

[david.tran]

jcarvaja wrote:
Check on the CSC, there are a lot of posts refering to that specific topic

Are you referring to Content Security and Control (CSC) Service module?  Let see here:

Comprehensive malware protection:  also available in Checkpoint as well a long time ago

Advanced content filtering:  also available in Checkpoint as well a long time ago

Integrated message security:  also available in Checkpoint as well a long time ago

Customization and tuning capabilities:  also available in Checkpoint as well a long time ago

Ease of management and automatic update capabilities:  also availabe in Checkpoint a long time ago

I know a few things that are supported by Checkpoint firewall but not Cisco ASA:

- Checkpoint firewall can run BGP.  ASA can not (at least in version that I use 8.2.1),

- you can combine 16 checkpoint physical firewalls into an Active-Active....Active firewall cluster.  I don't think you can combine 16 ASA firewall into a single firewall cluster.

- At least in version 8.2.1 that I use, Active-Active in ASA is really Active/Active for different context.  Within a single context, it is really Active/Standby.  In other words, it is HSRP with different group within ASA

Here is something that Cisco ASA can do but Checkpoint can not:

in the static NAT, or PAT, you can specify embryonic connection for each NAT in ASA but you can not do that with Checkpoint (I've not used Checkpoint Gaia yet so I don't know.  It may be there but not in NGx R71.30).

As someone who work with firewall technologies, I use both Cisco and Checkpoint and like them both.  They both have strenghs and weaknesses.  I don't think it is correct to say that Cisco ASA can do a lot of stuffs that other brands can not. 

One can also argue that other firewall brands can do a lot of stuffs that Cisco ASA can not as mentioned above.