- Products
- Learn
- Local User Groups
- Partners
- More
The Great Exposure Reset
24 February 2026 @ 5pm CET / 11am EST
CheckMates Fest 2026
Watch Now!AI Security Masters
Hacking with AI: The Dark Side of Innovation
CheckMates Go:
CheckMates Fest
Good evening,
I have set up a route-based VPN between our on-prem cluster to Azure Network Gateway. We experience a disruption to the VPN tunnel when failing over between the cluster members. As soon as the tunnel is reset by the remote peer, the tunnel is immediately re-established. The VTI is configured identically on both gateways, as is the routing. I can see in the gateway object under Network Management that the VTI is configured with a VIP, with the correct addresses for both cluster members. When running vpn tu tlist on both members, I can see the SAs are synched.
Is there any additional configuration required for full redundancy on VTIs/route based VPNs?
R80.40 T161
Thanks,
Aaron.
I cant recall exact setting now in web UI, but make sure in VTI settings that peer name (I believe is option when configuring VTI) is EXACTLY the same as what you gave it for interoperable object for both members, because if not, it will never work properly when there is a failover.
Also, static route to Azure side would use default gateway that is IP on Azure side net thats not in use. So say if your master has vti ip 169.254.10.55 and other one is 169.254.10.56, then vip can be say .57 and default gateway to reach azure can be say .60, as long as its not used anywhere on Azure side.
Message me offline if you need help, I can check this for customer we did it between on prem and cloud for few tunnels and works fine with failover and also its all route based with VTIs. Also, MAKE SURE that default gateway I was referring to is the SAME ip address as what you have when you edit topology for VTI and then under remote address field under vpn tunnel tab (2nd from the top on the left).
Andy
I cant recall exact setting now in web UI, but make sure in VTI settings that peer name (I believe is option when configuring VTI) is EXACTLY the same as what you gave it for interoperable object for both members, because if not, it will never work properly when there is a failover.
Also, static route to Azure side would use default gateway that is IP on Azure side net thats not in use. So say if your master has vti ip 169.254.10.55 and other one is 169.254.10.56, then vip can be say .57 and default gateway to reach azure can be say .60, as long as its not used anywhere on Azure side.
Message me offline if you need help, I can check this for customer we did it between on prem and cloud for few tunnels and works fine with failover and also its all route based with VTIs. Also, MAKE SURE that default gateway I was referring to is the SAME ip address as what you have when you edit topology for VTI and then under remote address field under vpn tunnel tab (2nd from the top on the left).
Andy
Hey @the_rock, I'll send you a PM.
Thanks, responded : - )
If using dynamic routing (BGP) is graceful restart configured?
Hey @Chris_Atkinson. We're not using any dynamic routing, just two static routes.
@AaronCP and myself did remote session and we are pretty sure that reason why this fails is due to routing. We went through the settings on VTI in web UI and saw that remote peer seemed to be wrong, which is what was used for static router as well as default gateway. Once thats fixed, please let us know if that works 🙂
Cheers,
Andy
Hey @the_rock,
Changing the remote peer as you suggested has resolved the issue! When we failover to the standby member, the VPN tunnel stays up!
Thank you for your help with this! 😊
Next time, I have a fee, 100 euros, I take British pounds as well ; - ). Just kidding, it was my pleasure to help you!!
Cheers mate.
Andy
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 56 | |
| 44 | |
| 16 | |
| 14 | |
| 14 | |
| 11 | |
| 10 | |
| 10 | |
| 9 | |
| 8 |
Thu 12 Feb 2026 @ 05:00 PM (CET)
AI Security Masters Session 3: AI-Generated Malware - From Experimentation to Operational RealityFri 13 Feb 2026 @ 10:00 AM (CET)
CheckMates Live Netherlands - Sessie 43: Terugblik op de Check Point Sales Kick Off 2026Thu 19 Feb 2026 @ 03:00 PM (EST)
Americas Deep Dive: Check Point Management API Best PracticesThu 12 Feb 2026 @ 05:00 PM (CET)
AI Security Masters Session 3: AI-Generated Malware - From Experimentation to Operational RealityFri 13 Feb 2026 @ 10:00 AM (CET)
CheckMates Live Netherlands - Sessie 43: Terugblik op de Check Point Sales Kick Off 2026Thu 19 Feb 2026 @ 03:00 PM (EST)
Americas Deep Dive: Check Point Management API Best PracticesAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY