Vendor compatibility
Google Cloud VPN post-quantum VPN support
Google Cloud HA VPN and Classic VPN tunnels, and the IKE cipher set the service supports for site-to-site connections.
Last reviewed
2 compatibility records
Direct answer
Google Cloud VPN is a managed service with a published, deliberately narrow set of supported IKE ciphers, and customers select from that set rather than configuring arbitrary proposals. Establish which key exchange methods the current supported cipher list includes, and confirm the peer device at the other end of each tunnel can match one of them.
Practical status
What this means in a real estate
A constrained cipher list is an advantage during assessment: what the service will negotiate is knowable from documentation rather than from device inspection. It is a constraint during migration, because there is no mechanism to advance the service's capability ahead of Google's own timeline. HA VPN's two-interface design also means each tunnel pair must be treated as a unit when planning waves.
What to establish about key exchange
Establish which key exchange methods appear in the current supported IKE cipher list for HA VPN and Classic VPN, and whether the list differs between them. The supported cipher documentation is the authoritative statement of what the service will negotiate.
Why authentication is a separate question
Cloud VPN tunnels authenticate with a shared secret. The key exchange method is independent of that, and a change to key establishment does not give the tunnel post-quantum authentication.
Products and versions
Compatibility records
Each record is scoped to a product and a version range. Key establishment and authentication are stated separately, because they migrate on different timelines through different mechanisms.
| Product | Key establishment |
|---|---|
| Google Cloud HA VPN | Post-quantum key establishment: Unsupported |
| Google Cloud Classic VPN | Post-quantum key establishment: Unsupported |
Google Cloud HA VPN
Managed service, current supported IKE cipher listCloud VPN supports a published and deliberately narrow set of IKE ciphers. The supported cipher documentation is the authoritative statement of what the service will negotiate.
Migration implication: A published cipher list makes the cloud side of the assessment fast and certain; plan the effort against the peer devices instead.
Caveats
- The supported cipher list cannot be extended by the customer
- Tunnel changes cause renegotiation and BGP sessions re-establish behind them
Last reviewed · medium confidence · 1 source
Google Cloud Classic VPN
Managed service, current supported IKE cipher listClassic VPN and HA VPN do not necessarily offer identical options, and Classic VPN tunnels may still be running IKEv1, which has no path to the IKEv2 post-quantum mechanisms at all.
Migration implication: Classic VPN tunnels still on IKEv1 need a two-step plan: move to IKEv2 first, then migrate key establishment. Treat these as separate waves with separate rollback plans.
Caveats
- An IKEv1 tunnel must move to IKEv2 before post-quantum key establishment is even in scope
- Classic VPN carries a different availability model from HA VPN
Last reviewed · medium confidence · 1 source
Prerequisites
Establish these before assessing migratability.
- Whether each tunnel is HA VPN or Classic VPN
- Current IKE version and negotiated cipher per tunnel
- Peer device model and release for every tunnel
- Cloud Router and BGP configuration where dynamic routing is in use
Peer compatibility
A tunnel is governed by the weaker of its two peers.
- The peer must support a method present in Google's supported cipher list
- HA VPN tunnel pairs must be migrated together to preserve the availability model
- Partner interconnect and third-party peers require separate confirmation
Operational limitations
Constraints that shape the plan rather than block it.
- The supported cipher list is set by the service and cannot be extended by the customer
- Classic VPN and HA VPN may not offer identical options
- Tunnel changes cause renegotiation, and BGP sessions re-establish behind them
Migration paths
The routes available when the current state is not the target.
- Update tunnel configuration to a supported method through infrastructure as code
- Migrate the peer device where it cannot match a supported method
- Move Classic VPN tunnels to HA VPN where the availability or capability difference matters
- Defer and track where the service does not list a suitable method
Verification requirements
What must be evidenced before a change is recorded as complete.
- Confirm the negotiated cipher from the peer device, where detail is available
- Confirm BGP re-establishment after the change where dynamic routing is used
- Verify both tunnels in an HA VPN pair
Sources
- 1. Supported IKE ciphers(opens in a new tab)
Google Cloud · verified by PQVPN
Individual compatibility records carry their own sources, listed against each record in the compatibility matrix.
Need this mapped to your actual Google Cloud VPN estate?
A readiness assessment establishes the exact release, licence and peer position for every gateway you run — and tells you which tunnels can move first.