Does the Post-NAT Zone for security policy is for Source zone and Destination Zone?

[rmeddane]

I read the following from the palo alto study guide:

A Security policy rule requires a source IP, destination IP, source zone, and destination zone. If you use an IP address in a Security policy rule, you must add the IP address value that existed before NAT was implemented, which is called the pre-NAT IP. After the IP address is translated (post-NAT IP), determine the zone where the post-NAT IP address would exist. This post-NAT zone is used in the Security policy rule.
A simple way to remember how to configure Security policy rules where NAT was implemented is to memorize the following: “pre-NAT IP; post-NAT zone.”

Ok I fully understand the concept of post-nat zone when building a security policy rule.

In the documentation, the following example is used to explain the concept of post-nat zone, but the security policy shown below describes only about the Post-NAT Zone of the destination zone, in other words the destination zone that is used in the security policy is the final zone the translated IP belongs to.

My question is what about the SOURCE ZONE in the security policy below, is it considered as the post nat zone? because only the destination zone is highlighted as the Post-NAT Zone.

[reaper]

your source zone will never change, that is where the packet is coming from

after nat the destination may change (packet may be redirected to a different zone), but that will not change where the original packet came from (you can change the source IP but not the source zone)

this is because you're doing a 'forward' lookup in the routing table pre and post NAT

only when you receive the reply packet will the firewall need to do the reverse, so when you did source nat, the reply destination requires a zone change, but since this is a reply packet, it is already part of a session (in the session table) so the firewall does that part "automagically" not requiring a security policy in the opposite direction

[Raido_Rattameister]

It is easier to understand the reason where pre-nat IP and post-nat zone comes from if you look how packet flows through Palo.

When packet comes in then forward lookup is performed (pbf, routing table) and it is easy to change destination zone in packet metadata (#1).

All security checks are performed after destination zone is updated but destination IP is still original (#2).

When all security checks (service, appid, decryption policy, security profile etc) allow traffic through then destination IP is changed in the packet right before packet is sent to the wire (#3).

It makes no sense to change destination IP in the packet during "NAT Policy Evaluation" step and waste cpu cycles calculating packet checksums etc if packet might be dropped by so many steps in between being sent out.