- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Content translations are temporarily unavailable due to site maintenance. We apologize for any inconvenience. Visit our blog to learn more.
02-11-2018 12:31 PM
Hello everbody,
I am most likely struggling with a NAT problem in a site to site VPN tunnel, hoping you have an idea or tip to this topic.
The setup is a site to site VPN tunnel between a PAN and a Cisco ASA.
There is a host (172.16.2.20) behind the PAN which should be reached through the VPN tunnel.
The problem is that the service provider behind the Cisco ASA access this hosts via a different IP address 172.44.33.20 so in my opinion I have to do NAT. The old firewall, which was from another vendor, had a DNAT rule configured for this.
The VPN tunnel looks good. If the service provider pings the 172.44.33.20 I see it in the traffic log. I allow ping via sec policy.
But the NAT rule doesn't work.
I read about this article: https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Configure-NAT-for-a-Network-Not-C...
which describes the NAT configuration for networks not conncected to the firewall.
I added the 172.44.33.0/24 network to the 172.16.X.X interface so the PAN knows the network and treats it as trust.
So the 172.44.33.20 is in the trust zone since I added the network to the 172.16.X.X interface.
The tunnel is in the zone VPN. As proxy ids for the tunnel I entered both networks to be sure but I think 172.44.33.0/24 is the right one cause the service provider with the ASA has this in his ACL.
I tested DNAT rule and Bi-Directional NAT rule:
Bi-Directional NAT:
source zone: trust
destination zone: VPN
destination interface: tunnel.4
source address: 172.16.2.20/32
destination address: any
service: any
source translation: static ip, 172.44.33.20/32, bi-direction:yes
destination translation: none
DNAT:
source zone: VPN
destination zone: VPN
destination interface: any
source address: any
destination address: 172.44.33.20/32
service: any
source translation: none
destination translaton: 172.16.2.20/32
VPN tunnel looks good, but ping goes through the tunnel to the 172.44.33.20 (which is a public IP) and there is no NAT to the real world ip address of the host 172.16.2.20.
I hope you have an idea where I am going wrong.
Thanks for your support!
Many greetings!
02-11-2018 11:27 PM
the DNAT policy will not work, as you attached the 172.44.33 network to your trust interface, (there is a route lookup prior to matching nat rules so this particular scenario would be vpn to trust)
if all else fails, stick the 172.44.33.20 on a loopback interface in the VPN zone, that will make your DNAT work
i would not use bidirectional NAT for this case as you're only looking to receive connections (plus the implied return policy has an 'any' for the source zone which I would personally try to avoid, with a destination of VPN which will not match due to the subnet being attached to your trust))
02-11-2018 11:27 PM
the DNAT policy will not work, as you attached the 172.44.33 network to your trust interface, (there is a route lookup prior to matching nat rules so this particular scenario would be vpn to trust)
if all else fails, stick the 172.44.33.20 on a loopback interface in the VPN zone, that will make your DNAT work
i would not use bidirectional NAT for this case as you're only looking to receive connections (plus the implied return policy has an 'any' for the source zone which I would personally try to avoid, with a destination of VPN which will not match due to the subnet being attached to your trust))
02-12-2018 04:18 AM
Hi reaper,
many thanks for the prompt reply.
With a loopback interface for the 172.44.33.20 and a DNAT from VPN to VPN it works 🙂
The any in the nat rule was only for testing purposes. Now I also changed the sec policy to allow only ping, icmp and rdp as application.
Many greetings
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!