Home / server / Questions / 928379
In Process
jacktrades
Asked: 2018-08-29 10:45:47 +0800 CST

Google VPN not supporting claimed ciphers

  • 772

Trying to make an IPSec IKEv2 connection with Google Cloud VPN services.

According to them, they support AES-CBC ciphers for Encyprtion at phase 1, but at the moment of negotiation with the on-premises VPN gateway only AES-GCM ciphers are offered.

So I get the famous "no proposal chosen" IKE SA error.

Do I need to tweak something on Google Cloud?

google-cloud-platform

3 Answers

  1. It sounds like an issue at the GCP side.

    Whenever you find that some GCP services work not as expected or against the behaviour described in the documentation you could file an issue report at the Google Public Issue Tracker or reach Google Cloud Support.

    In addition, you can always check status of GCP services at Google Cloud Status Dashboard

    • 0

  2. This troubleshooting sounds vague, without more information about Peer VPN gateway device and its configuration. So, the best approach here would be to grab the configuration and device to understand its compatibility configuration.

    Maybe the support for IKE fragmentation was not enabled. Some third-party vendor devices, such as firewalls configured for stateful packet inspection, do not permit the passthrough of User Datagram Protocol (UDP) fragments in case they are part of a fragmentation attack 1. If all fragments are not passed through, Internet Key Exchange (IKE) negotiation fails because the intended responder for the virtual private network (VPN) tunnel cannot reconstruct the IKE packet and proceed with establishment of the tunnel.

    An example of this behaviour can be seen in the Cisco 2821 router:

    show crypto isakmp sa detail
[TIMESTAMP]: ISAKMP:(0):Support for IKE Fragmentation not enabled

    A solution to this would be to enable IKE fragmentation.

    • 0

  3. I believe that the most probable cause of this error is a cipher mismatch. Is possible that you may have a proposal mismatch in IKE SA (phase 1) and 2.

    You can also try troubleshooting this following this guide.

    Specifically the following statement:

    If the VPN logs show a no-proposal-chosen error, this indicates that Cloud VPN and your on-premises VPN gateway were unable to agree on a set of ciphers. For IKEv1, the set of ciphers must match exactly. For IKEv2, there must be at least one common cipher proposed by each gateway. Make sure your on-premises VPN gateway is configured using supported ciphers.

    And also check the following as per the troubleshooting guide.

    1. Verify that the on-premises IP configured on the Cloud VPN gateway is correct.
    2. Check if the IKE versions configured on the VPN gateways match.
    3. Verify that traffic is flowing between the two VPN gateways in both directions. In the VPN logs, check for reported incoming messages from the other VPN gateway.
    4. Check that the IKE versions configured are the same on both sides of the tunnel.
    5. Check that the shared secret is the same on both sides of the tunnel.
    6. If your on-premises VPN gateway is behind one-to-one NAT, ensure that the NAT device has been properly configured to forward UDP traffic to your on-premises VPN gateway on ports 500 and 4500. Your on-premises gateway must be configured to identify itself using the public IP address of the NAT device. Refer to on-premises gateways behind NAT for details.

    Also check that the lifetime in Phase 1 (IKE) is set to Google recommended value of 36,600 seconds (10 hours, 10 minutes), and the lifetime in Phase 2 set to 10,800 seconds (3 hours).

    If the tunnel is not established after that, consider filing a public issue against the Cloud Platform/Networking using the Google issue-tracking tool. Include as many details as possible, including steps to reproduce for so that this issue can get a better visibility as well as more sampling.

    • -1