FTD showing several nat-no-xlate-to-pat-pool for asp drops

[ABaker94985]

We have an Firepower 4110 running 7.0.4 managed by an FMCv running 7.0.4. We've been dealing with a nat exhaustion problem recently, so I've been watching asp drops to make sure the issue is resolved. In the meantime, I've noticed the firewall is reporting around 100 packets/sec for asp nat-no-xlate-to-pat-pool. Over half of these have the FIN or RST flag set, so I'm not worried about these, and it's possible the rate isn't considered excessive anyway. The remaining drops are actual data traffic that probably belonged to a flow as shown below. I'm not hearing any reports about issues the past few days, but I'd appreciate someone weighing in as to whether or not this is significant and what could be the resolution. 

393: 12:56:37.624494 146.112.240.72.443 > our_public_ip.52645: . ack 2168596390 win 83 Drop-reason: (nat-no-xlate-to-pat-pool) Connection to PAT address without pre-existing xlate, Drop-location: frame 0x0000562d24140aa7 flow (NA)/NA

Thank you.

[MHM Cisco World]

https://itecnotes.com/network/cisco-regarding-the-manual-nat-in-cisco-asa/

I think you need to rearrange the NAT order 

[ABaker94985]

I don't understand how this would help. There are already xlate and connection entries - it's as if the translations timed out.

[tvotna]

Firewall would never drop the frame with this ASP drop code if there is a conn and xlate for it. If traffic rate isn't high, you can try to collect regular capture and ASP drop capture simultaneously to better understand what's going on with the connection.

In general, this drop code was introduced in ASA 9.0 software. E.g. after the change it's no longer possible to FTP from 172.16.0.1 (dmz) to 10.0.0.1 (inside) with this NAT configured:

nat (inside, dmz) source static obj-10.0.0.0 obj-10.0.0.0 destination static obj-172.16.0.0 obj-172.16.0.0 service http-80 http-8080

Instead you need to configure:

nat (inside, dmz) source static obj-10.0.0.0 obj-10.0.0.0 destination static obj-172.16.0.0 obj-172.16.0.0

So, this drop is most typical for NAT configs with ports. And the root cause is that mapped IP is added to PAT pool which is created by the system behind the scenes. In other words, below config:

object network my-ftp-server
 host <real-server>
 nat (inside,outside) static <mapped-server> ftp ftp

is now equivalent to:

object network my-ftp-server
 host <real-server>
 nat (inside,outside) static <mapped-server> ftp ftp

object network <internal>
 nat (inside,outside) dynamic <mapped-server>

There can be other scenarios when traffic is hit a pool IP, but xlate doesn't exist for it (probably your case).

[ABaker94985]

I understand exactly what you are saying, tvotna, but what you describe would affect the SYN packets. What I'm saying is that practically none of these are SYN packets - they are packets in the middle or end of a session. I also don't think they're bogus, because the asp-drop below is an ACK from MS Office. I don't think they should be dropped.

315: 08:17:40.060787 52.109.20.82.443 > 192.231.91.9.45101: . 2004346402:2004347782(1380) ack 3945935767 win 2044 Drop-reason: (nat-no-xlate-to-pat-pool) Connection to PAT address without pre-existing xlate, Drop-location: frame 0x0000562d24140aa7 flow (NA)/NA

[MHM Cisco World · Accepted solution]

what I need to Lab and until that time you can check some point 
the traffic have ACK and RST so it TCP traffic 
Inside-FW-Outside 
if Inside initiate traffic to Out then 
A- FW will add Conn 
B- FW will add Xlate entry 

each Conn and Xlate have timeout, Conn also can immediate end when client or Server send FIN. 
https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/115992-long-asa-xlate-idle-values-00.html

can you check the log message is for delete Conn traffic or not ?

[tvotna · Accepted solution]

Is it possible that connection was torn down right before the ACK packet arrived?

[MHM Cisco World]

I will try lab it today 

[ABaker94985]

I presume you're correct - the session probably did time out, but let me watch the logs for this. Thanks for the ideas.

[ABaker94985]

The problem appears to be caused by "timeout pat-xlate 0:00:30," so the translation is timing out. Thanks for your assistance with this.