Thanks to Francis Guillier Max Ardica and  Tiran Efrat of the overview and feedback.

One of the most important NSX Edge features is NAT.
With NAT (Network Address Translation) we can change the Source or Destination IP addresses and TCP/UDP port. Combined NAT and Firewall rules can lead to confusion when we try to determine the correct IP address to which apply the firewall rule.
To create the correct rule we need to understand the packet flow inside the NSX Edge in details. In NSX Edge we have two different type of NAT: Source Nat (SNAT) and Destination NAT (DNAT).



Allows translating an internal IP address (for example private IP described in RFC 1918) to a public External IP address.
In figure below, the IP address for any VM in VXLAN 5001 that needs outside connectivity to the WAN can be translated to an external IP address (this mapping is configured on the Edge). For example, VM1 with IP address needs to communicate with WAN Internet, so the NSX Edge can translate it to a IP address configured on the Edge external interface.
Users in the external network are not aware of the internal Private IP address.




Allow to access internal private IP addresses from the outside world.
In the example in figure below, users from the WAN need to communicate with the Server
NSX Edge DNAT mapping configuration is created so that the users from outside connect to and NSX Edge translates this IP address to


Below is the outline of the Packet flow process inside the Edge. The important parts are where the SNAT/DNAT Action and firewall decision action are being taken.

packet flow

We can see from this process that the ingress packet will evaluate against FW rules before SNAT/DNAT translation.

Note: the actual packet flow details are more complicated with more action/decisions in Edge flow, but the emphasis here is on the NAT and FW functionalities only.

Note:  NAT function will work only if firewall service is enabled.

Enable Firewall Service



Firewall rules and SNAT

Because of this packet flow the firewall rule for SNAT need to be applied on the internal IP address object and not on the IP address translated by the SNAT function. For example, when a VM1 needs to communicate with the WAN, the firewall rule needs to be:

fw and SNAT

 Firewall rules and DNAT

Because of this packet flow the firewall rules for DNAT need to be applied on the public IP address object and not on the Private IP address after the DNAT translation. When a user from the WAN sends traffic to, this packet will be checked against this FW rule and then the NAT will change the destination IP address to

fw and DNAT

DNAT Configuration

Users from outside need to access an internal web server connecting to its public IP address.
The server internal IP address is, the NAT IP address is



The first step is creating the External IP on the Edge, this IP is secondary because this edge already has a main IP address configured in the IP subnet.

Note: the main IP address is marked with a black Ddot (

For this example the DNAT IP address is


Create a DNAT Rule in the Edge:


Now pay attention to the firewall rules one the Edge: a user coming from the outside will try to access the internal server by connecting to the public IP address This implies that the fw rule needs to allow this access.



DNAT Verification:

There are several ways to verify NAT is functioning as originally planned. In our example, users from any source address access the public IP address, and after the NAT translation the packet destination IP address is changed to

The output of the command:

show nat

show nat

The output of the command:

show firewall flow

We can see that packet is received by the Edge and destined to the address, the return traffic is instead originated from the different IP address (the private IP address).
That means DNAT translation is happening here.

show flow

We can capture the traffic and see the actual packet:
Capture Edge traffic on its outside interface vNic_0, in this example user source IP address is and destination is

The command for capture is:
debug packet display interface vNic_0 port_80_and_src_192.168.110.10

Debug packet display interface vNic_0 port_80_and_src_192.168.110.10

debug packet 1

Capture edge on internal interface vNic_1 we can see destination IP address has changed to because of DNAT translation:

debug packet 2

SNAT configuration

All the servers part of VXLAN segment 5001 (associated to the IP subnet need to leverage SNAT translation (in this example to IP address on the outside interface of the Edge to be able to communicate with the external network.


SNAT config

SNAT Configuration:

snat config 2

Edge Firewall Rules:

Allow to to go out

SNAT config fw rule



The output of the command

Show nat

show nat verfication

DNAT with L4 Address Translation (PAT)

DNAT with L4 Address Translation allows changing Layer4 TCP/UDP port.
For example we would like to mask our internal SSH server port for all users from outside.
The new port will be TCP/222 instead of regular SSH TCP/22 port.

The user originates a connection to the Web Server on destination port TCP/222 but the NSX Edge will change it to TCP/22.


From the command line the show nat command:

PAT show nat

NAT Order

In this specific scenario, we want to create the two following SNAT rules.

  • SNAT Rule 1:
    The IP addresses for the devices part of VXLAN 5001 (associated to the IP subnet need to be translated to the Edge outside interface address
  • SNAT Rule 2:
    Web-SRV-01a on VXLAN 5001 needs its IP address to be translated to the Edge outside address

nat order

In the configuration example above, traffic will never hit rule number 4 because is part of subnet, so its IP address will be translated to (and not the desired

Order for SNAT rules is important!
We need to re-order the SNAT rules and put the more specific one on top, so that rule 3 will be hit for traffic originated from the IP address, whereas rule 4 will apply to all the other devices part of IP subnet

nat reorder

After re-order:

nat after reorer


another useful command

show configuration nat