Symptom:

 Configuring Network Address Translation on Palo Alto Networks firewalls is different than on other vendors’ products.

Problem:

 Traffic subject to NAT must be explicitly permitted by the security policy when that traffic traverses multiple zones.

Solution:

When using multiple IP addresses in the same subnet on the Outside, The PAN-OS proxy-arps for destination NAT addresses (documented in “Understanding NAT” PDF).

To ensure ARP, you can define additional “Static” IP addresses on the interface.   Enter an IP address and network mask for the interface in the format ip_address/mask, and click Add. You can enter multiple IP addresses for the interface.

For HA clusters with ARPs, you will also need “Layer 3 Floating IP Deployment”.
This deployment option allows for the creation of floating IP addresses that can move between the HA devices when a link failure or device failure occurs. The port that owns the floating IP address responds
to ARP requests with a virtual MAC address. Floating IP addresses are recommended when VRRP-like functionality is required. Floating IP addresses can be used in VPN and Network Address Translation (NAT) configurations, allowing for persistent connections when a failure occurs on the device offering those services.

Palo Alto Network Address Translation notes:

• Security policies always use the original IP addresses of the packet, even for NAT.  The actual NAT address translation does not happen until the packet is permitted and egresses the firewall.
• NAT, Security, and other rules will ALWAYS reference the original source ingress zone.
• The ONLY address or zone that may change from the original packet is the Destination Zone.
• When exposing DMZ servers to the Internet, the NAT rules for each server will go from the Outside (or Untrust) Source zone, to the Outside Destination zone.  However, the Security policy will be written for the post-NAT destination zone, so Security policy will go from the Outside Source zone, to the DMZ Destination zone.     If internal users need to access the DMZ server using the Internet-public IP address, a “U-turn” rule will need to be written (see attachment).

See also the section starting on Page 137 of ” PA-4.1_Administrators_Guide.pdf”, selected notes from the admin guide follow:

NAT rules must be configured with the zones associated with pre-NAT IP addresses.  E.g.  when translating outgoing web-browsing traffic to a public IP address, it is necessary to configure NAT policy with a source zone corresponding to the private IP addresses of those hosts (e.g. the “trust” zone). The pre-NAT zone is required because this matching occurs before the packet has been modified by NAT.   Generally for outbound web-browsing, you want to select a ” Source Translation” of ” Dynamic IP And Port”.  With this setting, you can NAT all internal clients to one IP, but allow rewriting the source port.  This supports 64K concurrent sessions (128K per IP on a PA-2050).  To support more concurrent sessions, use a range of consecutive IP addresses.

When configuring NAT on the firewall, along with the NAT policy, a security policy must also be configured to allow the NAT traffic. Security policy will be matched based on the post-NAT destination zone and the pre-NAT IP address.  Within the NAT policy, the address translation rules are based on the source and destination zones, the source and destination addresses, and the application service (such as HTTP). Like security policies, the first matching NAT policy is applied.   Traffic subject to NAT must be explicitly permitted by the security policy when that traffic traverses multiple zones.

The “tag” field in NAT and Security policies allows you to mark policies with a string “tag” that you can later use for searching or filtering, for example, so you can limit your view to just the policies with a specific tag.   Mostly useful when a single firewall group has a very large policy list.

Comments:

See also the section starting on Page 137 of ” PA-4.1_Administrators_Guide.pdf”,