Site to Site VPN cannot use any private network range

[cheez]

Hello,
I have to set up a Site-to-Site VPN so our users can access some resources on a clients network. As we had here a lab firewall, another Palo Alto, I set up a test between our production and lab. This worked and I was able to connect. For the actual connection to the client, their side is a Cisco ASA. I provided our Peer IP(Public IP) and internal subnet on my end from which to expect the tunnel traffic, 192.168.8.0/21. They informed me that this range is already in use for another client. From there I researched what could be done to make this work. I came this link, https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClSGCA0 and that all made sense. I went back to the client to inform them of the new subnet, 10.8.0.0/21 and they again said its in use. I asked if any 172.16. networks could be used and they said no. And that I should use a public IP for PAT intstead of an alternative private range. My question is, can I re-use the Public IP address that is being used in the existing NAT/PAT rule for internet access, to PAT the connections to through the client tunnel. Will this affect the non-tunnel traffic. I am trying to simulate in the lab set-up but wanted to see if anyone has had configure a Site to Site VPN in this manner.

Thanks in advance for any advice.

[BPry]

@cheez,

You can't re-use a public IP address in the firewalls routing table. 

[cheez]

Thanks for your reply.

I should have known that.

We have another IP from the block we bought that is not in use.

If I use that will the regular web traffic be affected? The tunnel is in its own zone

[BPry]

@cheez,

I'm slightly confused by your question. If the IP you utilize is not in use elsewhere it won't effect traffic to a different IP that is serving your web traffic. You'll just need to verify that you actually have your route table setup correctly. 

[aleksandar.astardzhiev]

Hey @BPry,

Apologies, but I am confused by your reply for the routing table...

@cheezif understand your question correctly you want to:

- create site-to-site IPsec tunnel

- inside this tunnel hide NAT your private source behind public IP (which also used for ike peer)

- use the public (peer) IP local encryption domain (proxy-id)

I haven't personaly done it, but I have seen it multiple time on other tunnel. And it shouldn't be any problem to achive this:
a) on the palo the decision if traffic should be encrypted with given tunnel is based on routing (aka route-base vpn), so it doesn't matter what source are you using (as long you have a rule of course)

b) when you are creating your hide NAT rule you need to specify source zone your lan and destination zone your vpn zone (where the tunnel interface is), and also match based on original destination - this will assure that only traffic to the vpn is NAT-ed

[BPry]

@aleksandar.astardzhiev,

I'm not sure how well what you are suggesting would actually work on the firewall (full disclosure, I've never needed to do this with a Public IP already in use). If you utilize a NAT translation for your VPN traffic to the other company, you would still require the associated route statements to actually direct the traffic to the right location. The issue with this that I see is simply that when the firewall does the route lookup you would have the same Public IP addresses assigned two different routes.

If the above does actually function, the next hurdle you would need to deal with is the other parties continued access to resources already published with that Public IP you are using for translation. If I have a website published to 192.168.1.1 for example and then utilize that address as a translation the other party is going to need to have a route directing traffic to 192.168.1.1 through the tunnel. 

[aleksandar.astardzhiev]

@BPry,

If you utilize a NAT translation for your VPN traffic to the other company, you would still require the associated route statements to actually direct the traffic to the right location.

That is pretty much the same what I have said - you only (or mainly) need route for the remote networks to point to the right tunnels.

But my understanding here is not the remote network overlapping with existing tunnels or local networks, but that the local network is in used behind the remote peer.

Also based on the @cheez explanation I got the expression that only traffic initiated from local to remote will pass through the tunnel.

Which should means:

- simple route to remote_network via tunnel.1
- source nat, with dynamic ip and port for traffic from:local_lan to:remote_network
- ipsec tunnel with proxy id local:natted_ip remote:remote_network

At this point it really doesn't matter what ip you will user for the source nat, as long the remote side accept it

[BPry]

@aleksandar.astardzhiev 

Right, I think were both fully in agreement with what OP needs to do to address the issu . My original post was simply stating that you wouldn't want to use the same public ip you were already using to publish other services. 

[cheez]

Thank you Both for your guidance on this.

I believe I have enough to set up a test tunnel from My lab firewall to production.

I will use an IP that's not currently being used for NAT 

And @alexander.Astardzhiev:

Yes, it will be our end only initiating the traffic to access a few servers on the Client side.

I will add the route to those on the via the tunnel.

[cheez]

Thanks, Both for your advice.

I have a lab connection successfully set up now.