The NATfather, part II

[reaper]

Only a few weeks ago, I wrote about how deceptive NAT policies could be and how to tackle inbound NAT in I'm gonna make him a NAT rule he can't refuse and along comes new community member @OMatlock and runs into a snag: 

Much like U-turn NAT (which is a little too complex, look for a link with a more elaborate article at the end of this post), trying to reach an external IP address attached to your untrust interface can get really interesting.

Let's recap real quick: The Palo Alto Networks firewall is a zone-based firewall that will apply security and NAT policy, based on your packet traversing the firewall and being matched to a certain source and destination zone, based primarily on the routing table. Depending on the source and destination zone, specific policies will be hit.

When you are trying to reach an IP on the external interface (most commonly the interface IP of the untrust interface), it is often overlooked what the exact chain of events are when the packet arrives at the firewall:

Because the source is trust and the destination is untrust (public IP is located in the untrust zone, according to the routing table), the packet will be processed by the generic outbound 'hide'NAT policy, intended for your internet connections. 

The only problem here: because the NAT rule will translate the source IP to the untrust interface's IP, this creates a special type of packet that causes a LAND attack* to be detected and the packet to be discarded.

*A LAND attack is when a host receives a packet with the same source and destination IP address, which could cause it to create an endless loop of the host replying to itself, constituting a DoS attack against the host.

The solution to the above 'issue' is to create a NAT policy specific for sessions from the trust zone destined for the public IP space. This policy will need to be above the hide-nat policy and will not apply any translation: 

With this policy in place, any connections from the trust zone to an IP address on the untrust interface will now succeed, making the GlobalProtect portal available if configured, making the external interface pingable if the profile has been enabled and any servers in the DMZ can now be reached on their public IP.

Caveat: see 'u-turn NAT' for any servers running in the trust zone

Interested in learning more? Below are a couple of more elaborate articles regarding NAT:

Getting Started: Layer 3, NAT, and DHCP

Getting Started: Network Address Translation (NAT)

How to Configure U-Turn NAT

Hope this was helpful!

@reaper out!