I'm gonna make him a NAT rule he can't refuse

[reaper]

 Most of the time, your NAT rules will be pretty simple, there's going to be a trust to untrust so your users can go out and surf the web, and then there's the untrust to untrust so your webserver is accessible to the outside

***record scratch***

Hold on! Untrust to untrust?

Yes! The Palo Alto Networks firewall is a zone-based firewall, and to determine when a NAT rule needs to trigger, the source and destination zones are determined based on the routing table for the source and destination IP address in the original SYN packet.

For a packet coming from the internet, the source zone will be untrust as the default route 0.0.0.0/0 points out of the untrust interface to the ISP router. The destination zone will also be untrust as the original destination IP (in the unaltered SYN packet) is that of the untrust interface.

There's more to NAT than meets the eye, especially considering the 'zone' factor:

In a multi ISP environment it may be preferable to keep both ISP interfaces in the same zone to keep the security policy simple, but this could pose some interesting NAT challenges as both policies look the same. Adding a destination interface (as determined by routing or policy based forwarding) to the NAT rule will keep things clean and simple:

In responce to a recent discussion forum question "Configure NAT with multiple ports", there's several ways to achieve port translation.

Allow me to demonstrate 4 different ways (each with its own implications)

Rule #1 simply and only translates port 22 to the external IP to port 22 on the internal server, all other ports will be ignored by this policy.

Rule #2 does the same as rule #1 but it takes a different external destination port (7777) and translates it to port 443 on the webserver, the client is connecting to port 7777 and doesn't realize he's actually connected to port 443.

Rule #3 is going to translate a set of several different TCP and UDP ports and will translate them one-to-one on the server. The caveat here is that, because we are setting up the original packet with a grouping of services, we cannot change these ports to a different port as we did in rule #2.

Rule #4 is going to translate all ports one-on-one to the server. The kicker to this rule is that it will also allow other protocols than simply TCP or UDP, so it will enable ping and GRE which cannot be accounted for by the previous rules.

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!