0

We have a GCP VPN to a partner and we are having some issues with the connection. Periodically the VPN goes down, and the only workaround that we've found so far is to force a renegotiation of both IPSec phases.

At the moment we have to ask our partner to do this for us because we can't find a good way to trigger a renegotiation on our side, is there a way for us to do it?

I've tried destroying and recreating the VPN. We store our configuration in terraform and recreating the VPN with the same name via terraform seems to not actually cause the VPN to be destroyed. Recreating it with a different name is a pain because it requires changes to our terraform configuration which then have to be committed to git.

Ilia Borovoi
  • 48
  • 5
dshepherd
  • 148
  • 3

1 Answers1

2

To answer your main question, you can’t restart a Cloud VPN. The information about what can be done when the Cloud VPN is up and running in this link

There is no way to force a renegotiation since this is done automatically by GCP end and it will continue to retry until it's successful.

However, the first thing we need understand is why the VPN is not renegotiating smoothly. For that, you can review the Stackdriver logsto see the crash log report. Using the report, you will have a better understanding of what needs to be fixed.

One of the most important part when implementing a VPN is to make sure that the VPN is correct configured and follows our interoperability guide.

There are two methods to implement a VPN failover if needed, the first one is called redundant Classic VPN configuration and second one is HA VPN. However, the recommended one is HA VPN tunnel. This is design to create a failover using the tunnel pair. The documentation for BGP configuration can be found here.

Nur
  • 386
  • 1
  • 7
Ilia Borovoi
  • 48
  • 5
  • Thanks for the answer. Unfortunately the gcp VPN doesn't seem to realise that a renegotiation is needed. In regards to solving the underlying issue: frustratingly I only have control over one side of the VPN and I've given the interop guide to our partners, but they haven't had any luck fixing the issue. I we'll have to try some sort of redundant VPN setup. – dshepherd Nov 12 '19 at 22:22
  • 1
    The Cloud VPN is probably still trying, but it's possible that there is something blocking it from finalizing the renegotiation. You might want to try looking at the [IKE ciphers timer](https://cloud.google.com/vpn/docs/concepts/supported-ike-ciphers), and make sure it's matching with your partners. – Ilia Borovoi Nov 14 '19 at 04:13
  • The issue is that our partner suddenly starts sending IKE headers that fail validation (it seems like they might be using different encryption keys to us because often the error is that the IKE version is some random obviously invalid number like 0.1, or 7.10 and changes constantly). We aren't sure why this happens but forcing a renegotiation seems to sort things out. We did check the timers, but if you think that would cause this issue maybe it's worth us checking again? – dshepherd Nov 14 '19 at 17:27
  • 1
    Reviewing the timer will be definitely be a good idea. Make sure it's set to Phase 1 lifetime (36,000 seconds (10 hours)) and Phase 2 lifetime (10,800 seconds (3 hours)). However, based on what you said, it looks like your partners are not following the GCP guideline for the IKE ciphers. When it will be correctly configured, you won't need to manually re-create the VPN since it will auto-negotiate the connection. – Ilia Borovoi Nov 14 '19 at 23:38