Hello everyone,
I have a question regarding Site-to-Site VPN and NAT.
I want to establish a tunnel with a new client however I discovered their remote subnet is already in use and overlaps with one of our existing customers.
Both customers use 192.168.1.0/24 as a remote subnet.
I asked the new client if its possible to change their remote subnet. If they can’t change their remote subnet what would be the best possible way to route traffic to the new customer? Would NAT be the anwser? How would I go about implementing this?
Overlapping networks are common, whether in another office or with a vendor. What you will use is Source Hide NAT. Though you may not be hiding, as this is used often when connecting to untrusted networks, it’s also used for overlapping networks.
My NAT Configuration Workbook can help you start to understand the configuration you may need with the NAT and Security policies. Definitely good advice from everyone here, but the workbook can help with some visuals.
Jeff
https://packetpassers.com/palo-alto-nat-config-workbook/
- You can carve out a network to NAT on your side.
- You can hide-nat behind your interface
- Same 2 above suggestions apply to the peer side
I do both depending on what I need.
I think the new customer has to do NAT on his side to fix this.
Not necessarily. You could do source and destination NAT for outbound and inbound on your end.
Pick a range to use instead of their 192.168.1.0 (e.g. 10.1.1.0) making sure you’re using another subnet of equivalent size (e.g. both are /24).
Create a Bi-Directional STATIC NAT on your Palo and (in the case of a /24) you’ll get a 1:1 mapping in the last octet of the address.
Example:
You send traffic to 10.1.1.76.
It reaches the firewall (because that’s where you routed 10.1.1.0/24 to).
Firewall NAT’s your destination from 10.1.1.76 to 192.168.1.76. Last octet is preserved but the first three are translated.
In your case, you’ll need to make this rule a source NAT AND a destination NAT. Otherwise, you’ll appear at the other end with an IP in 192.168.1.0/24 and you’ll not get a response. So you’ll need another range to do the source too.
Your traffic will always be destined for hosts in 10.1.1.0/24 and your customers will need to expect your traffic from the other range you pick (e.g. 10.1.2.0/24).
They get to keep the current address on their network and do none of the NAT work. You do ALL the NAT work but also don’t need to replace the address on your network.
Note: when building your NAT rule, if you get an error on commit, the chances are you’ve used lopsided addresses. I.e. one side of the NAT has a bigger network than the other (/24 one side and /26 the other for example).
It depends if you want to have bilateral communication or only publish services to them or acces services from them
Adding:. The range static nat is a great tool that’s often ‘missed’ as it’s more ‘advanced’. Very slick if you can use it.
Was gonna post about it but you covered it very well.
Oh, and bear in mind that NAT’ing into a VPN will affect the encryption. By which I mean, if you’re using Proxy ID’s (encryption domains - whatever you call them) the post NAT addresses should be used, not the “real” addresses.