How to change Gateways Main IP while 30+ customer S2S VPNs are connected?

[GreyWorm]

Hi CheckMates,

I have the following problem and would really appreciate any ideas on how to solve it.

I think this scenario should be quite common, so it’s strange I haven’t found any good solutions. Maybe it’s just me 🙂

I have a centrally managed main Checkpoint gateway connected via Mesh VPN with our 40 gateways, all managed by the same management system.

Additionally, there are 30+ third-party customer VPNs connected.

Now, we need to change the Main gateway IP because of a new ISP.

I see no issue with the 40 gateways managed by us; we can just change the main IP and push the policy to all.

However, there is a problem with the customer VPNs. We can’t do a “big bang” IP change; it needs to be done one by one in parallel over some time.

As far as I know, at the same time, there can only be one public IP for all running VPN tunnels (VPN Link selection: Main address or Selected from topology table).

Ideally, I would like to set the new public IP as an alias IP on the existing external interface or create a new parallel external interface and gradually move all VPNs one by one.

The last resort, which I would like to avoid, is setting up a new parallel gateway and moving the customer VPNs to that one, and then moving them back to the old gateway after the change.

Thanks in advance for your help!

Best regards. Andrew

[PhoneBoy]

The VPN peer IP is ultimately determined by the Link Selection setting (default is Main IP).
Sounds like it would be useful to set this by peer/VPN Community…something that should be possible in R82.

How to handle this now? If you can route out a different interface and set Link Selection to be influenced by routing (and configure the routing appropriately), it should work.

[emmap]

The 'IP Selection by Remote Peer' Link Selection configuration is only used for other gateways managed in the same SMS. So as you say, when you update the main IP and install policies to all your locally managed gateways, they will use the new IP. Third party externally managed gateways have the external IP of your side manually configured on their end. So as long as your old IP is still being routed to your new IP, they should still connect. You may have to take note of any hideNATing in the communities though as if you're doing any 'hide behind gateway' stuff, that will change when you change the gateway IP.

Now, your outbound traffic to the VPN peers may be an issue here, as you will be changing your gateway's source IP. You may be able to solve this with manual NATs, but you may also have to change your outbound NAT configuration as by default a gateway won't NAT its own outbound connections. See: https://support.checkpoint.com/results/sk/sk63805

To get around this, if it's possible to set your old IP on a new interface and then set static routes out this interface to each of the VPN peers, that would be the way to go. No manky NAT problems there. The default outbound link selection uses the OS routing table, so it will use the IP of the interface the VPN packets egressed from. Hence your old IP will be used for anything routed out that old IP interface. 

[the_rock]

I agree with all Phoneboy said. Now, having said that, personally, I think it would be little risky to make change like this, unless you are in long maintenance window and here is why I say this. Most people may assume, and quite frankly, logically so, that IF you change external IP, say VPN tunnels dont work, you flip it back, all works again.

Weeeeell, NOT exactly...sometimes, even reverting back to original state may not work right away. You may need to reset the tunnel(s) few times to get things going. Now, if they are route based ones, usually single reset works fine.

Again, link selection is probably your answer here. As long as thats configured right and routing is in place, you SHOULD be fine. 

Here is an example I will give you for route based tunnel and I also included post I made recently about it. Say you have VTI (virtual tunnel interface) and its unnumbered one. Usually, for unnumbered vti, people may use it if you are "pimping" BGP through the tunnel. Idea of such interface is that it will have SAME ip as say external interface, as it "hangs" off it and you use it to route traffic to the other side. However, if its unnumbered, for example, say member 1, if its cluster, can have vti10 as 169.254.0.50, other member as.51.then vip as .52 and you can use .53 as DG for subnet on the other side of the tunnel. So say Azure side is 10.10.10.0/24, on CP end you can use route to 10.10.10.0/24 with DG as .53 IP address.

Anyway, sorry for the long rambling, but thats the idea and all I wanted to point out.

Below is the post I was referring to.

Best,

Andy

https://community.checkpoint.com/t5/Security-Gateways/Route-based-VPN-tunnel-to-Azure/m-p/206179/emc...