- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
06-20-2014 05:13 AM
Hi all,
While trying to setup LSVPN on our HQ Palo Alto device, we ran into a U-Turn NAT issue. Let me first explain the setup:
We setup an OCSP responder using a loopback Interface on the PA firewall. The private IP address of that loopback interface is 10.99.99.1/32. The private IP is not being used outside the firewall. Instead, all "clients" in the External AND Trusted cloud connect to "ocsp.company.com" which resolves to 100.1.1.1 in both clouds.
Now access to "ocsp.company.com" from the External cloud is easy. That works well. However, so far we didn't manage to create a working U-Turn NAT rule for access from the Trusted cloud. Any ideas how this could be accomplished?
What we tried so far (not successful):
(We couldn't easily visualize the fake IP address in the "Source Translation" section in the first rule. But we tried with 10.1.1.1/24 as Source Translation IP.)
Thank you in advance.
Regards,
Oliver
06-20-2014 07:32 AM
Hi Oliver
Did you add the loopback interface to the external zone ? You would normally not need to do source nat as the ip is located in a different zone, but you will need to make sure the nat rule you create is above your generic "outbound" nat so you don't do hide-nat when accessing this loopback
your nat rules should look like this more or less:
06-20-2014 06:10 AM
Have you seen this example configuration on U Turn NAT walks through the process.
06-20-2014 06:19 AM
Yes, I've seen that. I also posted a comment on that post a while back 🙂
We do have other U-Turn NATs in place but none with a single-IP loopback interface...
06-20-2014 07:32 AM
Hi Oliver
Did you add the loopback interface to the external zone ? You would normally not need to do source nat as the ip is located in a different zone, but you will need to make sure the nat rule you create is above your generic "outbound" nat so you don't do hide-nat when accessing this loopback
your nat rules should look like this more or less:
06-21-2014 04:42 AM
Just to confirm, I think your oscp.company.com resolves to the loopback address 10.99.99.1 in your diagram.
If so, I think your rules need to have 10.99.99.1 as the destination address and then put 100.1.1.1 as the translated destination.
keep the source translation as it is now.
You are basically doing a double nat on both source and destination to create the U-turn for your setup.
07-02-2014 02:34 AM
Sorry for my late reply on this. I was too busy with other tasks unfortunately.
You're right tpiens, the loopback interface is in the External zone. When I removed the SNAT entry, it worked like a charm!
Thanks a lot for your hint.
07-02-2014 02:39 AM
Thank you for your post Steven. The DNS name "ocsp.company.com" resolves to an external IP on internal clients as well. We do have other situations where we actually do use the internal IP address of a loopback interface when we access it from a trusted zone. There we have Split-DNS active. On the setup described here we don't have Split-DNS available which finally caused the issue. Now that this is resolved we're good to go ahead.
07-02-2014 04:13 AM
Glad to hear you have this working.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!