Destination NAT Example—One-to-One Mapping
The most common mistakes when configuring NAT and security rules are the references to the zones and address objects. The addresses used in destination NAT rules always refer to the original IP address in the packet (that is, the pre-translated address). The destination zone in the NAT rule is determined after the route lookup of the destination IP address in the original packet (that is, the pre-NAT destination IP address).
The addresses in the security policy also refer to the IP address in the original packet (that is, the pre-NAT address). However, the destination zone is the zone where the end host is physically connected. In other words, the destination zone in the security rule is determined after the route lookup of the post-NAT destination IP address.
In the following example of a one-to-one destination NAT mapping, users from the zone named Untrust-L3 access the server 10.1.1.100 in the zone named DMZ using the IP address 1.1.1.100.
Before configuring the NAT rules, consider the sequence of events for this scenario.
Host 1.1.1.250 sends an ARP request for the address 1.1.1.100 (the public address of the destination server). The firewall receives the ARP request packet for destination 1.1.1.100 on the Ethernet1/1 interface and processes the request. The firewall responds to the ARP request with its own MAC address because of the destination NAT rule configured. The NAT rules are evaluated for a match. For the destination IP address to be translated, a destination NAT rule from zone Untrust-L3 to zone Untrust-L3 must be created to translate the destination IP of 1.1.1.100 to 10.1.1.100. After determining the translated address, the firewall performs a route lookup for destination 10.1.1.100 to determine the egress interface. In this example, the egress interface is Ethernet1/2 in zone DMZ. The firewall performs a security policy lookup to see if the traffic is permitted from zone Untrust-L3 to DMZ.
The direction of the policy matches the ingress zone and the zone where the server is physically located.
The security policy refers to the IP address in the original packet, which has a destination address of 1.1.1.100.
The firewall forwards the packet to the server out egress interface Ethernet1/2. The destination address is changed to 10.1.1.100 as the packet leaves the firewall.
For this example, address objects are configured for webserver-private (10.1.1.100) and Webserver-public (1.1.1.100). The configured NAT rule would look like this:
The direction of the NAT rules is based on the result of route lookup.
The configured security policy to provide access to the server from the Untrust-L3 zone would look like this:
Destination NAT with Port Translation Example
In this example, the web server is configured to listen for HTTP traffic on port 8080. The clients access the web server using the IP address 1.1.1.100 and TCP Port 80. The destination NAT rule is configured to translate both IP address and port to 10.1.1.100 and TCP port 8080. Address objects are configured for webserver-private (10.1.1.100) and Servers-public (1.1.1.100).
The following NAT and security rules must be configured on the firewall:
Use the show session all CLI command to verify the translation.
Destination NAT Example—One-to-Many Mapping
In this example, one IP address maps to two different internal hosts. The firewall uses the application to identify the internal host to which the firewall forwards the traffic.
All HTTP traffic is sent to host 10.1.1.100 and SSH traffic is sent to server 10.1.1.101. The following address objects are required:
Address object for the one pre-translated IP address of the server Address object for the real IP address of the SSH server Address object for the real IP address of the web server
The corresponding address objects are created:
Servers-public: 1.1.1.100 SSH-server: 10.1.1.101 webserver-private: 10.1.1.100
The NAT rules would look like this:
The security rules would look like this:
Source and Destination NAT Example
In this example, NAT rules translate both the source and destination IP address of packets between the clients and the server.
Source NAT—The source addresses in the packets from the clients in the Trust-L3 zone to the server in the Untrust-L3 zone are translated from the private addresses in the network 192.168.1.0/24 to the IP address of the egress interface on the firewall (10.16.1.103). Dynamic IP and Port translation causes the port numbers to be translated also. Destination NAT—The destination addresses in the packets from the clients to the server are translated from the server’s public address (80.80.80.80) to the server’s private address (10.2.133.15).
The following address objects are created for destination NAT.
Server-Pre-NAT: 80.80.80.80 Server-post-NAT: 10.2.133.15
The following screen shots illustrate how to configure the source and destination NAT policies for the example.
To verify the translations, use the CLI command show session all filter destination 80.80.80.80 . Note that a client address 192.168.1.11 and its port number are translated to 10.16.1.103 and a port number. The destination address 80.80.80.80 is translated to 10.2.133.15.
Virtual Wire Source NAT Example
Virtual wire deployment of a Palo Alto Networks firewall includes the benefit of providing security transparently to the end devices. It is possible to configure NAT for interfaces configured in a virtual wire. All of the NAT types are allowed: source NAT (Dynamic IP, Dynamic IP and Port, static) and destination NAT.
Because interfaces in a virtual wire do not have an IP address assigned, it is not possible to translate an IP address to an interface IP address. You must configure an IP address pool.
When performing NAT on virtual wire interfaces, it is recommended that you translate the source address to a different subnet than the one on which the neighboring devices are communicating. The firewall will not proxy ARP for NAT addresses. Proper routing must be configured on the upstream and downstream routers in order for the packets to be translated in virtual wire mode. Neighboring devices will only be able to resolve ARP requests for IP addresses that reside on the interface of the device on the other end of the virtual wire. See Proxy ARP for NAT Address Pools for more explanation about proxy ARP.
In the source NAT and static NAT examples below, security policies (not shown) are configured from the virtual wire zone named vw-trust to the zone named vw-untrust.
In the following topology, two routers are configured to provide connectivity between subnets 1.1.1.0/24 and 3.1.1.0/24. The link between the routers is configured in subnet 2.1.1.0/30. Static routing is configured on both routers to establish connectivity between the networks. Before the firewall is deployed in the environment, the topology and the routing table for each router look like this:
Route on R1:
Destination Next Hop
3.1.1.0/24 2.1.1.2
Route on R2:
Destination Next Hop
1.1.1.0/24 2.1.1.1
Now the firewall is deployed in virtual wire mode between the two Layer 3 devices. All communications from clients in network 1.1.1.0/24 accessing servers in network 3.1.1.0/24 are translated to an IP address in the range 2.1.1.9-2.1.1.14. A NAT IP address pool with range 2.1.1.9-2.1.1.14 is configured on the firewall.
All connections from the clients in subnet 1.1.1.0/24 will arrive at router R2 with a translated source address in the range 2.1.1.9-2.1.1.14. The response from servers will be directed to these addresses. In order for source NAT to work, you must configure proper routing on router R2, so that packets destined for other addresses are not dropped. The routing table below shows the modified routing table on router R2. The route ensures the traffic to the destinations 2.1.1.9-2.1.1.14 (that is, hosts on subnet 2.1.1.8/29) will be sent back through the firewall to router R1.
Route on R2:
Destination Next Hop
2.1.1.8/29 2.1.1.1
Virtual Wire Static NAT Example
In this example, security policies are configured from the virtual wire zone named Trust to the virtual wire zone named Untrust. Host 1.1.1.100 is statically translated to address 2.1.1.100. With the Bi-directional option enabled, the firewall generates a NAT policy from the Untrust zone to the Trust zone. Clients on the Untrust zone access the server using the IP address 2.1.1.100, which the firewall translates to 1.1.1.100. Any connections initiated by the server at 1.1.1.100 are translated to source IP address 2.1.1.100.
Route on R2:
Destination Next Hop
2.1.1.100/32 2.1.1.1
Virtual Wire Destination NAT Example
Clients in the Untrust zone access the server using the IP address 2.1.1.100, which the firewall translates to 1.1.1.100. Both the NAT and security policies must be configured from the Untrust zone to the Trust zone.
Route on R2:
Destination Next Hop
2.1.1.100/32 2.1.1.1

Related Documentation