If you'd like to know more about U-Turn NAT, or hairpinning, and how to configure it with a Palo Alto Networks firewall, then youll want to take a look at this video.
This is Tom Piens with the Palo Alto Networks Community team. In this week's video tutorial, I'm going to explain U-Turn NAT and how to configure and test it.
The term U-Turn is used when the logical path of a connection traverses the firewall from inside to outside and back in, by connecting to an internal resource using its external IP address. U-Turn NAT is a configuration trick to accommodate a deployment where the external IP needs to reach an internal resource.
In some environments, an internal host may require an external IP address to run a certain service, for example, a locally hosted web server or mail server. Internal hosts may need to use the external IP address due to the absence of an internal DNS server or other requirements specific to the service.
In the example, using regular destination NAT configuration, any connections originating from the laptop directed to the server on its external IP address, 198.51.100.230, are directed to the default gateway, as the IP address is not in the local subnet. It then gets translated to destination IP address 192.168.0.97, without applying source NAT, which causes the web server to send return packets directly to the workstation, resulting in an asymmetric flow.
Note: Asymmetric flows are discarded by the firewall due to their potential to be malicious.
With U-Turn NAT configured, outbound packets from the laptop also have source NAT applied to them.
The source NAT causes the server to send reply packets directly to the firewall rather than sending to the laptop. Sending packets directly to the firewall prevents asymmetry and allows the firewall to still apply content scanning to the session.
We'll first take a look at the current configuration, which reflects what a common setup looks like without U-Turn NAT.
The security policy has an inbound rule that allows inbound connections from the Internet onto the internal web server with application web-browsing, which is default port 80. Further, we have a simple outbound security policy that allows any users to go to the Internet on any application. Finally, we have the two implied rules that allow intrazone traffic, for example, trust to trust, and the denied intranet zone that prevents sessions from reaching other zones without an explicit policy permitting it.
The NAT policy has an inbound rule to allow connections from anywhere to the external IP address to be translated to the server's internal IP address and a hide-NAT rule to allow internal connections to go out to the Internet and get source-translated behind the firewall's external interface IP address.
When we look at the client PC, if I open a browser and try to access 198.51.100.230, which is the Internet-facing IP address of my internal server, you'll see the page is not loading. If I bring up Wireshark, you'll see a syn packet is being sent to the external IP, a syn/ack is being received from the internal IP address 192.168.0.97, and a reset is being sent as the client doesn't understand what's going on.
If we now go back the to firewall and open the NAT policy, we see that the inbound NAT rule has been set up to accept any source zone and translate that to the proper internal server IP address.
Name — internal access
Destination address —198.51.100.230
Under the Translated Packet tab:
Destination address —192.168.0.97 (IP address of the web server in question)
Source address translation —Dynamic IP / Port
Switch address type —Interface
Interface — ethernet1/2 (Internal Interface of the Firewall)
IP Address —192.168.0.230/24
If we add a new rule, name it internal access, go to the original packet tab and set the source zone to trust, destination zone to untrust, and set the destination address to 198.51.100.230. Then move on to the translation packet tab and set the destination, as with the regular rule, to 192.168.0.97, then also enable source address translation by setting it to dynamic IP and Port, switch address type to interface address.
You can set the Address Type to translated address and choose an address in the IP range assigned to the interface, in this example we'll stick with the IP address assigned to the interface, for ease of use.
Select the trust zone interface from the dropdown and set its IP, then click OK.
NOTE: Be sure to place the new NAT rule above the inbound rule, or the original NAT rule will take precedece over the newly created one.
Commit the configuration and return to the client PC.
If we open the webpage now, the internet information server 7 default page loads and the web server is accessible from the inside on its external IP address.
If we take a look at the Wireshark packet capture, the client is receiving its returning packets from the external IP, because the firewall can now perfom NAT on both directions of the flow.
Thanks for watching!