FTD NAT theory question - same real IP / service - different mapped IP

[brettp]

I have a theoretical question that I should be able to definitively answer myself, but pitifully, I can't say that I can... though I do have an idea on it. I was hoping someone here has the answer.

On a Cisco ASA/FTD, without specifying both source and destinations in the NAT, can you NAT the same "real" IP / same service to two different "mapped" IPs without causing issues if it's really only necessary for reply traffic?

For example:

Outside Client A connects to 1.1.1.1:443 which NATs internally to 192.168.1.1:443
Outside Client B connects to 1.1.1.2:443 which NATs internally to 192.168.1.1:443

Because Client A initiates the connection to 1.1.1.1, the FTD is aware of that connection. When the webserver responds, will the FTD correctly NAT to 1.1.1.1 because it has already seen the reverse traffic?

Because Client B initiates the connection, the FTD is aware of that connection. When the webserver responds, will the FTD correctly NATs to other IP of 1.1.1.2 because it has seen that reverse traffic already?

Because the source/destination information is not in the xlate table, I think there will be conflicts and this will not work as the FTD is not aware of which connection a particular NAT translation belongs to. Only clients connecting to the first matching NAT will work correctly whereas those connecting to the other will have problems. Is that correct? Or is there some secret table that causes the FTD to pair NAT translations with connections?

Of course... The real solution is to specify both source and destination in the NAT.

[buffkata]

I have seen what you are describing and it was working correctly. Unfortunately it was not set by me and I do not have the details. 

I just remembered it was working - hope that helps. 

[brettp]

Thank you for your reply, though I'm still uncertain if it would work correctly in the real world as it does not seem like it would to me... but I don't know!

[Sheraz.Salim · Accepted solution]

This can be done and it will work on ASA. if work on ASA on FTD it will work too. As long as the inititator is the public IP address it will work.

object network INSIDE_SERVER-1
 Host 192.168.110.14
 nat (inside,outside) static 1.1.1.1
!
object network INSIDE_SERVER-2
 Host 192.168.110.14
 nat (inside,outside) static 2.2.2.2
!
access-list inbound line 1 extended permit tcp any object INSIDE_SERVER-1 eq 443
access-list inbound line 2 extended permit tcp any object INSIDE_SERVER-2 eq 443

(or)

Object PublicA
 host 1.1.1.1
!
object PrivA
 host 192.168.1.1
!
object PrivA_Map
 host 172.1.1.1
!
nat (inside,outside) source static PrivA PrivA_Map destin static PublicA PublicA
!


Object PublicB
 host 1.1.1.2
!
object PrivB
 host 192.168.1.1
!
object PrivB_Map
 host 172.1.1.2
!
nat (inside,outside) source static PrivB PrivB_Map destin static PublicB PublicB

[brettp]

Thank you. It's very interesting that it works -- but of course when the initiator is outside as I suspected. I guess it means translations are aware of connections (or at least current translations are aware of both the source and destination.) I could not find any documentation on this.