Creating NAT rules
Unless you are one of the lucky few organizations that were able to get their very own A (/8) or B (/16) class subnets, your internal network segments will most likely be made up of one or several of the well-known RFC1918 private IP address allocations: 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16. NAT is needed for your hosts to be able to reach the internet and your customers and partners to reach publicly available resources hosted in your data center. NAT rules can be configured through Policies | NAT.
For this section, keep the following interface setup in mind:
Figure 3.38 – Interface zone and IP configuration
Address translation comes in different flavors depending on the direction and purpose, each with its own nuances. Let's first review Inbound NAT.
Inbound NAT
For Inbound NAT, it is important to remember that the firewall is zone-based and the source and destination zone are determined before the NAT policy is evaluated:
Figure 3.39 – Packet flow stages
This means that for inbound NAT, the source and destination zone will be identical. The routing table will determine the source zone based on the default route and the destination zone based on the connected network, which is configured on the external interface.
For example, if the 203.0.113.1 internet IP is connecting to the 198.51.100.2 firewall IP to reach the 10.0.0.5 server, the firewall will look up 203.0.113.5 in its routing table and find that it only matches the default route, 0.0.0.0/0, which points out of the ethernet1/1 interface, which is in the Untrust-L3 zone. It will then look up 198.51.100.2 (the original destination IP in the packet header) and find it in the 198.51.100.0/24 connected network on the ethernet1/1 interface, which is in the Untrust-L3 zone.
The Original Packet tab needs to have the following:
- The same source and destination zones.
- Source Address can be Any for generic internet sources, specific IP addresses, or subnets if the source is known.
- Destination Interface indicates which interface the packet is headed to. This can be important in cases where there are multiple interfaces with overlapping routes.
- Service can be used to restrict which destination port is allowed in the received packets. This will help in cases where the IP space is restricted and Port Address Translation (PAT) is required to host different services on the same external IP and will prevent over-exposing an internal host.
- DESTINATION ADDRESS needs to be a single IP for a one-to-one destination NAT (don't add a subnet). Having a subnet-based destination NAT is possible, but only for Session Distribution:
Figure 3.40 – Original Packet NAT translation
In the Translated Packet tab, you can set what needs to be changed for the external client to be able to reach the internal server:
- Source Address Translation will usually be set to None, but it can be set to match an internal interface subnet or loopback interface if required. This would let the server receive a packet sourced from an internal IP, rather than the original internet IP.
- Destination translation to a static IP, also known as one-to-one NAT, changes the destination IP to a single internal server.
- Translated Port can be used if the internal service runs on a different port than the externally advertised one. For example, externally, a web server could be reachable on default SSL port 443, while on the server itself, the service is enabled on 8443:
Figure 3.41 – Translated Packet NAT translation
Next, let's take a look at address translation in the opposite direction.
Outbound NAT
Outbound NAT rewrites the source IP addresses of internal clients to the interface associated with a different zone. This could be an internet-facing zone or one connecting to a partner, VPN, or WAN, as in the following screenshot:
- The source zone will reflect the interface that the clients are connected to.
- The destination zone and destination interface will reflect the egress interface that a routing lookup determines based on the original packet:
Figure 3.42 – Outbound NAT Original Packet
Important note
When using an IP pool for source translation, the firewall will use proxy ARP to gain ownership of IP addresses. This means that you don't need to physically configure all of the IP addresses on an interface, but it is recommended that you have at least the subnet configured on an interface so that the firewall knows which interface is used to broadcast the proxy ARP packets. If the subnet does not exist on an interface, proxy ARP will be broadcast out of all the interfaces.
Hide NAT or one-to-many NAT
The most common implementation of outbound NAT is the infamous hide NAT, or many-to-one, which changes the source IP addresses of all internal clients to the external IP(s) of the firewall. It is best to place this rule near the bottom of the rule base as it will catch any non-specific sessions and rewrite the source IP to that of the firewall.
The best option for this type of NAT is Dynamic IP and Port (DIPP). DIPP rewrites the source IP to that of a selected interface or a manually entered IP, IP-range, or subnet, and assigns a random source port to the session on egress, as you can see here:
Figure 3.43 – DIPP to an interface IP or manual selection
DIPP supports around 64.000 concurrent sessions per available source IP, multiplied by the oversubscription factor supported by the platform you are deploying these rules on. As a rule of thumb, smaller platforms commonly support 2x oversubscription, larger platforms support 4x, and extra-large platforms up to 8x. When multiple IPs are available, DIPP assigns a rewrite IP based on a hash of the source IP so that the same source always gets the same translation address. Once the concurrent allowance for a given translation address is depleted, new sessions will be blocked until existing sessions are freed up.
You can check the current oversubscription ratio by using the following command:
admin@PA-220> show running nat-rule-ippool rule <rule name>
VSYS 1 Rule <rule name>:
Rule: <rule name>, Pool index: 1, memory usage: 20344
-----------------------------------------
Oversubscription Ratio: 2
Number of Allocates: 0
Last Allocated Index: 0
If more than 64.000 x oversubscription ratio concurrent sessions per source are needed, or source ports need to be maintained, you can opt to use Dynamic IP instead of DIPP. Dynamic IP will simply "hop" to the next available IP in its assigned translation addresses for a given source IP while maintaining the source port. As a fallback, if the available IP pool does get depleted because Dynamic IP does not support oversubscription, you can enable DIPP. The IP used in the fallback should not overlap with any of the main IP pools:
Figure 3.44 – Dynamic IP with two subnets and DIPP fallback
In some cases a server or host on the network will need to "own" its own IP address, which can be achieved with one-to-one NAT rules.
One-to-one NAT
Static IP will always translate a source into the same translation IP and maintain the source port. An IP range can be set, in which case the source IPs will be sequentially matched to the translated IPs, but it is important that the source range and translation range are identical in size; for example, 10.0.0.5-10.0.0.15 translates to 203.0.113.5-203.0.113.115.
The bi-directional option creates an implied inbound NAT rule to allow inbound translation for the same source/translated-source pairs. This implied rule reuses the destination zone set in the rule and any as the new source zone. The 'Translated source' address of the configured rule will be used as the 'Original destination' address, and the 'Original Source' of the configured rule will be used as the 'Translated destination' of the implied rule.
For the outbound rule, as you can see in the following screenshot, you have the following:
- Source: Trust-L3
- Destination: Untrust-L3
- Original source: serverfarm
- Translated source: serverfarm-public
For rules that have bi-directional set, the following implied NAT rule will be created:
- Source: any
- Destination: Untrust-L3
- Original destination: serverfarm-public
- Translated destination: serverfarm
Figure 3.45 – Static IP NAT with the Bi-directional option
In some cases "double NAT" needs to be applied to sessions that need to take an unusual route due to NAT. These types of NAT rules are called U-turn or hairpin NAT rules.
U-turn or hairpin NAT
If an internal host needs to connect to another internal host by using its public IP address, a unique problem presents itself.
For each session, only one NAT rule can be matched. When the client connects to the public IP, the routing table will want to send the packet out to the internet, which will trigger the hide NAT rule, which translates the source IP. The packet should then go back inside as the destination IP is also owned by the firewall, but a second NAT action can't be triggered, so the packet is discarded.
Important note
If the hide NAT IP is identical to the destination IP, which is common in environments with few public IP addresses, the packet will be registered as a land attack:
admin@PA-220> show counter global | match land
Global counters:
Elapsed time since last sampling: 26.05 seconds
name value rate severity category aspect description
-------------------------------------------------------------
Flow_parse_land 1 1 drop flow parse Packets dropped: land attack
A workaround to this problem, if changing the internal DNS record or adding an entry to the host file of the client is not possible, is to configure a U-turn or hairpin NAT.
Important note
If you are using PAN-OS 9.0.2 or later, refer to the following Enable DNS Rewrite section.
This type of NAT combines the destination and source NAT and must be placed at the top of the rule base to prevent the hide NAT rule from catching these outbound sessions. The reason the source NAT is required is to make the session stick to the firewall so that no asymmetric routes are created.
If you were to configure the destination NAT to rewrite the public IP for the internal IP without translating the source, the server would receive a packet with the original source IP intact and reply directly to the client, bypassing the firewall. The next packet from the client would be sent to the firewall, which would try to perform TCP session sanity checks and determine whether the TCP session was broken, discarding the client packet. Adding source translation would force the server to reply to the firewall, which would then forward the translated packet back to the client:
Figure 3.46 – U-turn NAT
This type of complication can also be addressed by changing the DNS query to the internal IP of the final destination.
Enable DNS Rewrite
Enable DNS Rewrite was introduced in PAN-OS 9.0.2 and later and enables the NAT policy to be applied inside DNS response packets:
- It reverse translates the DNS response that matches the translated destination address in the rule. If the NAT rule rewrites 198.51.100.2 to 10.0.0.5, the reverse rewrite will change the DNS response of 10.0.0.5 to 198.51.100.2.
- It forward translates the DNS response that matches the original destination address in the rule. The forward DNS rewrite changes the DNS response of 198.51.100.2 to 10.0.0.5.
This could be useful in a scenario where internal hosts need to query a DNS server in the DMZ for an FQDN of a server also hosted in a DMZ where they receive the external IP in the DNS response. This could lead to odd routing issues (see the U-turn or hairpin NAT section) as the destination IP will match the external zone, but both the client and server are on internal zones:
Figure 3.47 – Enable DNS Rewrite
If a service is hosted on several physical servers (the original destination is an FQDN that returns several IP addresses), the destination translation settings can be set to Dynamic IP (with session distribution). The firewall will rewrite the destination IP according to the chosen method:
Figure 3.48 – Dynamic IP (with session distribution)
With this information you will now be able to resolve any Network Address Translation challenges you may face.