FTD allows ICMP requests but not reply's

[brian.schoenrock]

FTD 2140 running 7.0.5

I need to allow ICMP from outside to an inside server.  The requests make it through the FTD's and the log on the server shows it receiving and responding.  The Analysis on the FTD never shows the reply and the initiating device never receives a reply.

Pings from the internal server to sites on the web work without issue.  This ICMP traffic is flowing over the same NAT and ACLs.

I believe IP inspection is enabled, as showing the service-policy on the FTD CLI shows lines for ICMP inspection - and my understanding is that pings from the internal server out to the web wouldn't work without ICMP inspection.

I'm new to firewall configuration.  Any advice on where I should be looking?

[MHM Cisco World]

the reply is NATing that why 
you need to use NAT exception here.

More details:-

You mention you config NAT' but are NAT you config is really NATing reply traffic or there is other NAT rule NATing reply.

What NAT mode you use 

Before after 

Auto or manual NAT?

[brian.schoenrock]

The translated traffic is working both directions.  The server in this case is a Meraki MX100 that is hosting around 70 VPN's.  Traffic hitting the public IP is being translated to the internal and traffic from the Meraki's IP is being translated to the public IP.

As far as I can tell, the only traffic that isn't currently working are the ICMP reply's.  When I run a packet trace, the packets are dropped:

"Drop-reason: (inspect-icmp-seq-num-not-matched) ICMP Inspect seq num not matched, Drop-location: frame 0x000000aaaca215d4 flow (NA)/NA"

[MHM Cisco World]

you have only one ISP or two ?

[brian.schoenrock]

More than one.  

We've run a packet trace on active pings to the public IP and this is the reason for the drop: "(no-adjacency) No valid adjacency".  I don't know how it's possible the FTD doesn't have a valid next hop for a response to a packet it just received.  Again, only the ICMP replies are being dropped.  ICMP requests in either direction are forwarded without issue.

This doesn't make any sense to us and I'm opening a TAC case.

[MHM Cisco World]

Ok' more than one do you config policy route map'

What this error meaning is you have asymmetric routing.

[brian.schoenrock]

I don't see how - this internal IP is only allowed to this NAT.  But I will definitely check into it more.  I'm leaving for a three day weekend but will dig into it on Monday.  Thanks for the advice.

[Aref Alsouqi]

How routing to the ISP is configured on the FTD? I'm just thinking that potentially this could be caused by asymmetric routing, maybe the ICMP return traffic takes a different path and because of this the FTD drops it. You can run packet capture on the FTD of the ASP drops and see if you see that traffic dropped.

[brian.schoenrock]

The traffic leaves from and returns to the same internal interface.  It is policy mapped to the NAT interface.  The reply traffic is routed the exact same way as outbound request traffic and it works fine.  Only the reply traffic fails.

[Aref Alsouqi]

Could it be that the server is configure with a gateway that is not the FTD? or maybe it is not configured with any gateway?

[Aref Alsouqi]

"Pings from the internal server to sites on the web work without issue.  This ICMP traffic is flowing over the same NAT and ACLs."

Actually re-reading this it means the server has a default gateway, but not sure if the default gateway is the FTD or a downstream L3 device that maybe doesn't have a route back to the initiator?

[brian.schoenrock]

It's a downstream L3 core switch and it is communicating without issue.  The server in this case is a Meraki MX100 that is a VPN concentrator and it has around 70 VPN's constantly working.  This issue is definitely within the FTD's and how they handle ICMP.