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 172.16.10.11 needs to communicate with WAN Internet, so the NSX Edge can translate it to a 192.168.100.50 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 172.16.10.11.
NSX Edge DNAT mapping configuration is created so that the users from outside connect to 192.168.100.51 and NSX Edge translates this IP address to 172.16.10.11.
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.
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.
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 172.16.10.11 needs to communicate with the WAN, the firewall rule needs to be:
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 192.168.100.51, this packet will be checked against this FW rule and then the NAT will change the destination IP address to 172.16.10.11.
Users from outside need to access an internal web server connecting to its public IP address.
The server internal IP address is 172.16.100.11, the NAT IP address is 192.168.100.6.
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 192.168.100.0/24 IP subnet.
Note: the main IP address is marked with a black Ddot (192.168.100.3).
For this example the DNAT IP address is 192.168.100.6.
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 192.168.100.6. This implies that the fw rule needs to allow this access.
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 192.168.100.6, and after the NAT translation the packet destination IP address is changed to 172.16.10.11.
The output of the command:
The output of the command:
show firewall flow
We can see that packet is received by the Edge and destined to the 192.168.100.6 address, the return traffic is instead originated from the different IP address 172.16.10.11 (the private IP address).
That means DNAT translation is happening here.
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 192.168.110.10 and destination is 192.168.100.6
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
Capture edge on internal interface vNic_1 we can see destination IP address has changed to 172.16.10.11 because of DNAT translation:
All the servers part of VXLAN segment 5001 (associated to the IP subnet 172.16.10.0/24) need to leverage SNAT translation (in this example to IP address 192.168.100.3) on the outside interface of the Edge to be able to communicate with the external network.
Edge Firewall Rules:
Allow to 172.16.10.0/24 to go out
The output of the command
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:
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 172.16.10.0/24) need to be translated to the Edge outside interface address 192.168.100.3.
- SNAT Rule 2:
Web-SRV-01a on VXLAN 5001 needs its IP address 172.16.10.4 to be translated to the Edge outside address 192.168.100.4.
In the configuration example above, traffic will never hit rule number 4 because 172.16.10.4 is part of subnet 172.16.10.0/24, so its IP address will be translated to 192.168.100.3 (and not the desired 192.168.100.4).
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 172.16.10.4, whereas rule 4 will apply to all the other devices part of IP subnet 172.16.10.0/24.
another useful command
show configuration nat