Best Practices for Site-to-Site IP/Interfaces?

[jsalmans]

Hi all,

I've currently got a site-to-site VPN tunnel already configured for one of our cloud services but we've got a request to add another service from another provider.  Our current config has a single floating IP address with the associated tunnel configuration and assigned to a "Site-to-Site" security zone.

I'm wondering what best practices are concerning multiple site-to-site configurations.  I've already started creating separate Crypto configs and, obviously, I'll need a separate actual IPSec Tunnel config.  What I'm wondering is if it is best practicles to re-use the same public floating IP, loopback, tunnel interface, etc. or is best practices or common just to create a whole new setup?

[BPry]

I keep the public IP the same, other than that I modify everything else specific to that tunnel besides the zone as I have one IPSec zone that terminates all site-to-sites. I'm not sure if that is really the 'proper' way to do it but I find it easy enough to manage and it hasn't given me any issues so far. 

[jsalmans]

@BPry so you keep the public IP and the associated virtual loopback interface the same but create a new virtual tunnel interface (configured with no IP... just used in the IPSec Tunnel config)?

[BPry]

@jsalmans,

I actually don't use the loopback interface and assign the tunnel interface a private IP address strictly for monitoring. The tunnels all have one shared local public IP address. I imagine that you could do the same thing without issue utilizing the loopback instead. 

[davanderson]

You can have a single public IP that represents your systems and then have this IP address as the "local-address" crossing into multiple VPN tunnels.  Each site-to-site VPN tunnel should terminate into it's own interface and it's own zone.

tunnel.1 = zone VPN-PartnerName1

tunnel.2 = zone VPN-PartnerName2

This allows you to write specific security rules and NAT rules that match your traffic.  This gives you full control over each tunnel and won't allow traffic to cross from tunnel to tunnel.  Putting them into a single zone could allow the u-turn or hair-pin type traffic and could allow VPN to VPN flows (inadvertently).

Each VPN tunnel will have a Phase2 configuration (IPSec Tunnels in the PA).  On the PROXY-ID's tab, this is where you create your interesting traffic list (think crypto map for vendor VPN's).  Your Local entry will be the public "local-address" (from above) and the Remote will be the unique IP address that your VPN partner is using.  This is what allows you to re-use your single IP into mutiple tunnels.

[jsalmans]

Thanks for the feedback guys.  I have the loopback involved mainly because it is tied to a floating IP since we're running A/A.

I had originally thought to do all Site-to-Site as the same zone and do the policy rules all according to IP addresses but I can definitely see how having them in separate zones will make things a little clearer and provide an extra layer of functionality against accidental or unintended traffic flow.

[BPry]

@jsalmans,

I'm not sure of your platform but before you start assigning every single site-to-site a new security zone specific to that tunnel I would look at your max zone capability and how many tunnels you actually plan on forming during the expected lifetime of your firewalls. I've had to help a few people cut zone count retroactively because they haven't thought about it being a ceiling for them, it's not a very fun process.  

[jsalmans]

@BPry

We're on the PAN-5060 platform.  It looks like it supports 900 security zones and we've only got 10 or so now I think.

[BPry]

@jsalmans,

Sweet that should be good to go then. Some of the smaller firewalls have insanely limited zone counts where you could easily hit the max if you start setting up site-to-sites like this. Once you get past the 3000 series it really becomes a non-issue 🙂

[OtakarKlier]

Hello,

Anothing thing to think about when using zones, is that you can have one VPN zone and still seperate the traffic by IP address's. This way you dont run low on zones or try to keep them all seperated.

i.e. 

Source IP range x.x.x.x/x zone VPN

Source IP range y.y.y.y/y zone VPN

Let me know if you would like me to expand on that.

Cheers!

[jsalmans]

Thanks @OtakarKlier for the info.

That is actually how I was originally planning on doing it but I ended up liking the suggesting of creating security zones for the other site-to-site configs we add.  They can all use the same public IP (and associated loopback that I use for the floating IP HA part) and then everything else is different.  I feel like this gives me some extra control and options when designing security policy and with 900 maximum security zones on our platform I don't have to worry about running out any time soon.