01-26-2023 10:38 PM
Hi All,
Our vendors are migrating their IPSEC tunnel firewall, which is resulting to change the tunnel gateway IP from our palo-alto firewall end as well.
So, we are thinking just to create one more ipsec tunnel without tagging the tunnel interface and during maintainace window just to bind the tunnel interface to our new Ipsec tunnel and unbind the same from old ipsec tunnel.
Will the above thinking will work ?
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.
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.
02-20-2023 11:16 PM
I have done the change as per your suggestion. It worked fine. Thank you so much for your help.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!
