01-29-2023 02:05 PM
Hi @Sujanya ,
My personal opinion - Just update the IKE gateway object for that tunnel with the new IP address for the remote peer. Note - if do that via GUI there is a chance that you will need to re-enter the PSK, so it is good idea to find it before the maintenance, or even better - generate and exchange new psk.
If I understand your idea correctly, you want to:
- Create new IKE gateway object
- Probably re-use IKE and IPsec crypto profiles
- Create new IPsec Tunnel using the new IKE-Gateway and previous IPsec Crypto, but without assigning any tunnel interface
- Push this config to FW and leave it there until migration
- On migration just remove the tunnel interface from old tunnel and assign it to the new tunnel
Did I get this correct? My only problem with that approach is that, I am almost certain (I cannot test at the moment), that you cannot create IPsec tunnel, without associating it with tunnel interface. Commit will fail and you will need to assign "dummy" interface to the new tunnel.
Instead of dummy interface, which will be switched during the migration, why not just
- Create new IPsec tunnel (with new IKE gateway, re-used crypto profiles and new tunnel interface)
- In the day of migration confirm the new tunnel is established successfully (you can use the "test vpn ipsec-sa..." command to force negotiation without real traffic)
- If both phases are up, you update your static route for the remote network to point to the new tunnel interface
You could do that in order to minimize the downtime for the traffic over the tunnel, but only if remote network can have the two tunnel up at the same time and re-route the traffic after new tunnel status confirmation.
Again for me this is overcomplicating a simple change, which on your side is just updating the IKE gateway object.
