Syntactically, the following set of statements is valid (at least as of 8.3):

interface Ethernet0/0
  nameif OUTSIDE
  ip address
interface Ethernet0/1
  nameif INSIDE
  ip address

object network O_N_EXAMPLE1
object network O_N_EXAMPLE2
object service O_S_EXAMPLE1
  service tcp destination eq 60001
object service O_S_EXAMPLE2
  service tcp destination eq 60002
object-group network OG_N_EXAMPLEHOSTS
  network-object object O_N_EXAMPLE1
  network-object object O_N_EXAMPLE2

nat (OUTSIDE,INSIDE) source static any any destination static interface OG_N_EXAMPLEHOSTS service O_S_EXAMPLE1 O_S_EXAMPLE2

nat (INSIDE,OUTSIDE) after-auto source dynamic any interface

The second nat statement is fairly obvious -- it simply translates everything outbound to the WAN IP, in a typical hide-NAT/LAN-to-WAN scenario.

However, the first nat defines a (probably invalid) rule directing any inbound request for the WAN IP over TCP/60001 to be sent to either of or

The ASA command-line lets you enter it without error.

packet-tracer doesn't balk at it (at least, assuming an access-group permits):

  • packet-tracer input OUTSIDE tcp 12345 60001 "succeeds", in that it says the final action is to allow, and along the way it untranslates to and identifies the output interface as INSIDE.
  • packet-tracer input INSIDE tcp 60002 60002 "succeeds", in that it says the final action is to allow, and along the way it translates to, but does not indicate the ouput interface.

What it does not do (and what I think might have been the original intent) is distribute between the two target IPs, nor track which of the two hosts is up and establish a translation to an available node. I don't believe that ASA has any function for that (although I'm happy to be proved wrong!) beyond tracked routes, which are more to do with outbound, LAN-to-multi-WAN traffic.

In practice I expect it accepts the inbound and drops the reply traffic, resulting in a failed TCP handshake.

I note that splitting the nat statement into two statements results in an ovelap [sic] warning:

# nat (OUTSIDE,INSIDE) source static any any destination static interface O_N_EXAMPLE1 service O_S_EXAMPLE1 O_S_EXAMPLE2
# nat (OUTSIDE,INSIDE) source static any any destination static interface O_N_EXAMPLE2 service O_S_EXAMPLE1 O_S_EXAMPLE2
WARNING: mapped-address ovelap with existing static NAT.

So I wonder, how does the ASA interpret that first nat statement and, in particular, under what circumstances would it actually attempt to translate to

I understand what would happen if the NAT was a destination static between two object objects (a simple translation from the first to the second) or even two object-group objects with the same number of network-object entries (a one-to-one translation from the nth entry in the first group to the nth entry in the second group), but not in this case, with a one-to-many definition.

Does it just translate between the interface address and the first network-object, dicarding the second? Or does it work something out with regards to available ephemeral ports (e.g. the first 64K connections go to and the second go to Does it duplicate the traffic to both? Or something else entirely?

  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer.
    – Ron Maupin
    Nov 19, 2022 at 21:43

1 Answer 1


You are correct that the ASA does not track NAT objects to direct packets to objects that are "up". You are also correct that it does not load balance or share translations between hosts (at least when the NAT type is "static"). It also does not split the ports into pools and allocate them among objects.

The answer is contained here: https://www.cisco.com/c/en/us/td/docs/security/asa/asa91/configuration/firewall/asa_91_firewall_config/nat_overview.html#13402

For a many-to-few or many-to-one configuration, where you have more real addresses than mapped addresses, you run out of mapped addresses before you run out of real addresses. Only the mappings between the lowest real IP addresses and the mapped pool result in bidirectional initiation. The remaining higher real addresses can initiate traffic, but traffic cannot be initiated to them (returning traffic for a connection is directed to the correct real address because of the unique 5-tuple (source IP, destination IP, source port, destination port, protocol) for the connection).

What happens is that the ASA iterates the "translated" object/object-group until it gathers the correct quantity of hosts to satisfy the untranslated object/object-group. In your case above, the necessary quantity is 1. To the best of my understanding, under no circumstances will traffic be translated to based upon the configuration above, until someone removes from object-group network OG_N_EXAMPLEHOSTS.

Regarding your experiment where you split the NAT into two, I just wanted to add a little clarity. Despite that the ASA gave you an overlap warning, I believe it does accept the command and add it to the config and the NAT table. Manual NATs (or "twice NATs" as sometimes they are called) are processed in top-down, first-match order. So the second statement would never be hit. It is possible to reorder manual NAT rules.

As a closing thought, there is an alternate way to configure this NAT.

object network O_N_EXAMPLE1
 nat (INSIDE,OUTSIDE) static interface service tcp 60002 60001

and if you also attempted the following . . .

object network O_N_EXAMPLE2
 nat (INSIDE,OUTSIDE) static interface service tcp 60002 60001

. . . then it would also be added to the Auto NAT table following NAT Rule Order (https://www.cisco.com/c/en/us/td/docs/security/asa/asa91/configuration/firewall/asa_91_firewall_config/nat_overview.html#31590) and it would only be hit in the outbound direction (which will never happen since the server will not likely initiate a connection sourcing from a port where it has a listening daemon).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.