- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
12-09-2019 08:48 AM
Hi All,
Can someone help me with a NAT over VPN. What I thought was correct isn't working and I have tried a number of combinations that all fail.
The encryption domains are (based on Palo) Remote 85.90.253.239, local 192.168.90.228, to reach a server on IP 10.0.8.82.
What would the NAT look like? Every combination that I think is correct doesn’t see the NAT rule hit. Probably so simple I'll headbutt the desk but for now....it's eluding me - albeit I've spent the weekend migrating 5 large councils to a Palo Solution so very worn out.
Regards
Adrian
12-09-2019 10:06 AM
Hi @a.jones
According to what you described local site is 192.168.90.228, remote external IP is 85.90.253.239 and destination IP is 10.0.8.82 and you want to NAT the source.
1) you need to include local IP NAT address in proxy ID of the tunnel.
2) Check "Enable NAT Traversal" on the ike gateway advanced options.
3) create NAT rule with the ipsec tunnel as the destination interface for translating the source.
4) make sure your security policies include the NAT address if you created specific source IP address.
I use this source for ipsec tunnel using nat configuration.
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClopCAC
Good Luck
12-09-2019 10:33 AM
I have a differing perspective on how to configure this.
Encryption Domain terminology implies that you are using a policy based product (like CP? :P)
The PANW uses static route based solution.
The policy based technologies require a complimentary SA/DA pair configured on both sides. This is a proxy ID
The PANW does not use complimentary proxy IDs, so you will need to create them.
On the PANW, modify your IPSec tunnel, click on ProxyID and enter the local (from the PANW side) and the remote subnet.
Now you will have a complimentary proxy ID for both sides to be exchanged.
You do NOT need to enable "NAT Traversal", unless your PANW firewall is NOT performing and a L3 switch (north of the PANW is)
This is typically for virtual FWs that have private IPs vs public interface IP.
You should NOT need any NAT at all in NAT policies.
Your routing table should take your private IP, fwd it across the VPN to the remote side, without the need to NAT.
I have been teaching PANW edu classes and doing PS for 8 years, so I am available for a phone call if you want to chat offline about this.
Let me know.
12-13-2019 12:24 AM
This was a strange setup but I got it working by a source and destination nat. The remote end are seeing the traffic now.
We were taking over another companies solution so have been replicating their setup to a degree. We cannot inherit their equipment so have migrated to our own solution. Some things they have done is a mess. This instance they claim to have had a working solution which I copied and it turned out that was not true.
Regards
Adrian
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!