Firepower PAT bug ?

[rmathieson7]

Hi,

I noticed that port scans had been querying all the internal hosts with bidirectional NATs defined which is obviously expected.  But I also noticed that odd internal hosts that shouldn't be routable were also in scope on occasion.  Further investigation shows that this is happening when the port scan targets our default internet breakout PAT address which is obviously a dynamic unidirectional PAT.  The packet I'm seeing is nothing out of the ordinary, just a syn with a sequence number of 0.

If I use packet tracer to try to replicate the traffic it correctly drops it as there isn't anything in the state table to match.  Has anyone else seen this before ?  I certainly don't think it's expected behavior but can't seem to find any mention of a bug that would explain what I'm seeing.

[rmathieson7]

I did a packet trace the other day when I noticed this and have just done another and as expected a random IP with random TCP port gets dropped with the reason '(nat-no-xlate-to-pat-pool) Connection to PAT address without pre-existing xlate'

But I've had time this morning to repeat the test by checking the xlate table first and select a port number already in there against the public PAT IP then it does in fact un-nat and try to route to the corresponding inside host.  The traffic is then blocked during the Snort phase due to hitting the deny rule at the bottom or our ruleset.   I don't see any mention of the state table though, my expectation would be that it would lookup against the state table and if the IP / port number matched then it would be allowed.  The fact that it seems to be getting as far as the ruleset from a completely different IP is again a concern.

Anyone think this is expected / unexpected ?

[Ilkin · Accepted solution]

If there is an existing xlate entry for the source address a.b.c.d created for an outbound session (from inside to ouside) and there is another inbound connection (outside to inside) from a different source to the mapped IP address and port of a.b.c.d, then that existing xlate entry will be used for a translation, no matter what the new source IP address is. For this new connection UN-NAT will be performed using existing xlate and then access-list check will be performed. 

NAT is not a security technology and is not enforcing any security checks.

[rmathieson7]

This is a dynamic unidirectional outbound Nat so there are no connections in the table inbound. Just many outbound that should allow traffic back in as per the state table, but I would argue only from ips that we have initiated connections with ?

[rmathieson7]

Thanks, I have since tested this on a lab on an ASA and it behaves in exactly the same way.  Happy to accept this as a solution, the more I thought about it the more sense it made and also sounded familiar.  Thanks again for the explanation.