Internal Servers Unable to Reach Each Other On Their Public IPs with Static Bi-directional NAT

Issue

When internal servers are configured with static bi-directional NAT addresses, some servers are unable to communicate with each other via their public IP addresses. This is expected behavior due to how policies are evaluated on the Palo Alto Networks devices. This document proposes an alternative configuration as a workaround.

Cause

Palo Alto Networks firewalls evaluate NAT policies in a top-down fashion. When a rule is matched, that rule is selected to process the packets and no further lookup is performed. To understand how this behavior affects the connectivity to servers, consider the scenario below:

Srv A: Private IP = 192.168.89.206, Public IP = 10.66.25.101, FQDN = myserverA.com

Srv B: Private IP = 192.168.89.210, Public IP = 10.66.25.102, FQDN = myserverB.com

Srv C: Private IP = 192.168.89.209, Public IP = 10.66.25.103, FQDN = myserverC.com

Communication should not be a problem for the three servers if they communicate through their respective private IP addresses. The issue occurs if each server only knows of the other servers' Public IP addresses or FQDN names, and each of the servers has a static bi-directional NAT policy.

For each of the bi-directional NAT statements written, there are 2 policies created in the dataplane:

• One for the source NAT
• One for the destination NAT

These NAT policies are arranged in the order that you have configured them, and so configuring bi-NAT1, bi-NAT2 and bi-NAT3 for the three servers will appear in running configuration in the following order:

bi-NAT1(s_NAT1)

bi-NAT1(dNAT1)

bi-NAT2(s_NAT2)

bi-NAT2(dNAT2)

bi-NAT3(s_NAT3)

bi-NAT3(dNAT3)

Below is a snippet of the NAT policies configured on the GUI and how the bi-NAT1 appears in CLI.

Note: bi-NAT2 and bi-NAT3 CLI outputs are further below but not shown in this example. To view the full NAT policies in dataplane, issue the 'show running nat-policy' command in CLI.

With this configuration, when traffic is sourced from Srv_A (192.168.89.206), going to destination myserverB.com (10.66.25.102), the bi-NAT1(s_NAT1) gets matched due to the top-down policy evaluation but the communication never works. The resulting traffic appears as follows:

When traffic is sourced from Srv_C (192.168.89.209), however, going to the same destination myserverB.com (10.66.25.102), note that the communication is successful because the correct destination NAT bi-NAT2(dNAT2) gets matched. The logic finds a match for the destination IP and only that IP gets translated. The resulting traffic appears as follows:

Notice also that for the working translation, the from-Zone and to-Zone are both trust-L3 (which is correct). For the non-working translation, however, the from-Zone is trust-L3 and the to-Zone is untrust-L3, and Srv_B never receives the ping packet.

Resolution

To ensure that the servers communicate with each other via their public IP addresses, we need to write distinct destination and source NAT statements for each server, and then position those destination NATs above the source NATs. Note that the destination NAT statements should have the Source Zone set to 'any' to permit incoming traffic from any zone.

The following is how the NAT statements look after they have been re-configured:

Also, verify that Srv_A can successfully communicate with all internal servers.

owner: tasonibare