VPN tunnel and NAT rules

[buck1]

I have to create a VPN tunnel between two businesses.  The main objective is that company A needs to provide access to the following subnets to company B:

10.10.1.144/28

10.1.2.144/28

I've got all the tunnel info set up, and there is just a public IP address on each firewall as the peer IP.

For company A where the subnets are located, I'm struggling with the NAT rule needed to allow access to this range of IPs.

Would it look something like this:

source zone: vpn_untrust

destination zone: inside_trust

destination interface: any

source address: public IP of company B

destination address: public IP of company A

destination translation: subnets listed above

[reaper]

hi @buck1

no

but first: is NAT at all needed? (is there an IP conflict on both sites?)

if there is no IP conflict then no nat is needed, just routing

if both sites have identical IP subnets, you will need to set up NAT, depending on which direction you need to communicate to

if site A only needs to connect to site B, you could replace these subnets at siteA with 2 different ones

eg. 192.168.0.0/28 + 192.168.0.16/28 while doing source nat to 192.168.0.250/24

SiteA

source zone: trust

destination zone: vpn

source address: lan subnet

destination address: 192.168.0.0/28 + 192.168.0.16/28

source translation: 192.168.0.250/24

route these (0 + 16) subnets into the tunnel

and set the tunnel ip to 192.168.0.250/24

siteB

rule1

source zone: vpn

destination zone: vpn

source address: 192.168.0.250

destination address: 192.168.0.0/28

destination translation: 10.10.1.144/28

rule2

source zone: vpn

destination zone: vpn

source address: 192.168.0.250

destination address: 192.168.0.16/28

destination translation: 10.1.2.144/28

and set the tunnel interface to 192.168.0.251/24

• destination zone is vpn because the tunnel interface belongs to the subnet of the destination IP in the packet (a pre-nat route lookup will determine the destination zone for NAT rules) see https://live.paloaltonetworks.com/t5/Tutorials/Getting-Started-Network-Address-Translation-NAT/ta-p/...
• setting the 2 tunnel interfaces to the 192.168.0.0/24 subnet will create a 'shared' network of which the IPs can be used to mask the destination and source of packets (one end can source nat, the other destination-)

[LCMember20111]

@reaper - 

If I may bump this for a QQ -

If I am converting from Cisco ASA s2s VPNs to Palo's, do I need to configure the "nonat" like I have on the ASA?

Based on your above response, that answer is no? Is this accurate?

Thanks in advance,

[aleksandar.astardzhiev]

Hi @LCMember20111 ,

The answer really depends on your setup. You need to understand why NONAT was required for Cisco ASA to understand why it may not be required for PAN FW.

As you may know ASA was implementing the "policy based" VPN. This means that traffic for the tunnel is still routed to your outside/untrusted zone, but before leaving ASA is checking "the policy" (the crypto map) if this traffic needs to encrypted with ipsec or not. But you still have your hide NAT that will translate any source leaving through the outside/untrusted zone/interface. I hope you see the problem - VPN and Internet traffic are associated with same interface, so you need to have the no-nat exception to tell traffic doesn't need hide nat.

Palo Alto FWs on other hand apply "route based" VPN, so you need to create logical interface associated with that IPsec tunnel. You can abstract from the IPsec for a moment and treat this interfacase as any other physical interface. You associate this tunnel interface with a zone and you can have static routes and rules to and for that zone. If you put the tunnel inteface in zone separate from the outside/untrusted you will not need NO-NAT rule - why? Because the default hide NAT rule will not match this traffic. PAN FW security and NAT rules are matching source and destination zone (based on route lookup). So when you try to go to internet destination zone will match your default route and will match your default hide nat. But if you try to reach something over the ipsec, your destination zone will be different, because the static route is pointing to the tunnel and that tunnel is in different zone. You don't have to excplicetly tell the firewall that these are different - they already are, because they are related to different zones.

If you put the VPN tunnel interface in the same zone as your unstrusted/outside (which you may see as recommended in some very old PAN documents), that you way need the no-nat. But still really depends, if you configure your default hide nat with destination zone and destination interface, your vpn traffic will still not match the hide nat, because fw will see that destination interface is the logical tunnel and not your public interface.

Because NAT policy become much more easy to manage and because of the "Zero-Trust approach" you may consider creating separate zone for each IPsec tunnel, phyiscal or sub-interface.

Some time ago I tend to put all IPsec tunnels into single "IPsec-VPN" zone, which could be fine if you have tones of IPsec tunnels on small box (limited numbers of zones), but not that often anymore (it is hard to come up with zone names thou)

[LCMember20111]

Thanks @aleksandar.astardzhiev for the deep dive explanation.

My situation is very simple -

1. This pair of 3220's sole purpose is terminating site to site VPN tunnels.

2. Each "partner" has their own tunnel.x interface and zone specific to them.

3. I route the remote side traffic into the related tunnel.x interface in the VR

4. There is no hide-nat (again, these 3220's won't be used for generic internet access)

Based on your response, I shouldn't need the NoNat, correct? And you are correct in  how the ASA treats traffic and the need for the NoNat.

Thanks in advance

[aleksandar.astardzhiev]

Hi @LCMember20111 

Yes, you don't need no-nat rule.

The fact that you don't have default hide NAT makes you solid.

It is good approach to have separate zone for each tunnel if this device is deisgnated as VPN concentrator.

[LCMember20111]

Thanks @aleksandar.astardzhiev. I appreciate the feedback.