The NATfather, part II

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.
Cyber Elite
Cyber Elite

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: 

 

How to enable Pint on ISP interface with Dynamic IP?

 

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. 

NAT web interface Policies tab with Original Packet and Translated Packet information.

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: 

nonat.png

 

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!

  • 8616 Views
  • 0 comments
  • 2 Likes
Register or Sign-in
About the Author
I drink and I know things
Labels
Top Liked Authors