- CheckMates
- :
- Products
- :
- CloudMates Products
- :
- Cloud Network Security
- :
- Discussion
- :
- Cloudguard cluster VPN termination fails after pat...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Cloudguard cluster VPN termination fails after patching
This is a follow on from a previous question about Linux agent versions
We have several cloudguard clusters in Azure. We have VPN tunnels to each of them from various on-prem gateways, and also between them.
When we patch the gateways, they obviously reboot.
Several times now we have found that after patching, the VPN tunnels fail from one set of gateways (always a different set) to one of the gateways in the cluster. failing over the cluster restores service.
The solution so far has been to redeploy the failing gateway onto a different Azure host.
Has anyone else seen similar behaviour?
We are using our IP space advertised by Microsoft fro each gateway. Could that we relevant?
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Just to clarify, you mention "failing over the cluster restores service" but then you also mention that you need to redeploy the failing gateway onto a different Azure host.
Are you saying that if you fail back to the other cluster member in Azure it still does not re-establish the VPN tunnel until completely redeployed?
BR!
Jeff
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes. It seems that after patching one of the gateways in the cluster ends up on a 'bad' host. If we fail over the cluster to the other gateway service is restored. If we fail back to the original gateway on the original host we lose service again. Redploying the bad gateway to a new host restores service again.
We have seen this behaviour 3 times now, with 2 different clusters in 2 different subscriptions