Stay organized with collections Save and categorize content based on your preferences.
Caution: Dynamic routing or Border Gateway Protocol (BGP) with Classic VPN tunnels will be deprecated on August 1, 2025. After this date, existing tunnels with these configurations will no longer be supported. Tunnels that are in use will continue to function but without an availability SLA. If you use BGP with Classic VPN for production workloads, we recommend that you migrate to HA VPN. For more information, see Feature deprecation: Classic VPN.With Classic VPN, your on-premises hosts communicate through one or more IPsec VPN tunnels to Compute Engine virtual machine (VM) instances in your project's Virtual Private Cloud (VPC) networks.
Classic VPN supports site-to-site VPN as the sample topology shown on this page or with redundancy options.
Note: For information about HA VPN topologies, including Google Cloud-to-Google Cloud VPNs, see the HA VPN topologies page. For information about configuring third-party devices or services with Cloud VPN, see Use third-party VPNs. Sample Classic VPN topologyThe following diagram shows a sample VPN connection between a Classic VPN gateway and your peer VPN gateway.
Sample VPN topology with a connection between a Classic VPN gateway and your peer VPN gateway (click to enlarge). Redundancy and failover options Note: With Classic VPN, it is not possible to create two VPN tunnels within the same Cloud VPN gateway to the same destination VPN gateway.You can provide redundancy and failover for Classic VPN gateways by either moving to HA VPN or by using a second Classic VPN gateway.
Option 1: Move to HA VPNIf your peer VPN gateway supports BGP, the recommended option is to move to a highly available (HA) Cloud VPN gateway.
Option 2: Use a second peer VPN gatewayFor Classic VPN, if your on-premises side is hardware based, having a second peer VPN gateway provides redundancy and failover on that side of the connection. A second physical gateway lets you take one of the gateways offline for software upgrades or other scheduled maintenance. It also protects you in case of an outright failure in one of the devices.
To configure a tunnel from your Cloud VPN gateway to a second on-premises-side VPN gateway, do the following:
For details about configuring redundancy with dynamic routing, see the Cloud Router redundancy page.
Redundant on-premises VPN gateways diagram (click to enlarge) Increased throughput and load balancing options Note: the solutions in this section for increasing throughput can be also used to load balance between two gateways as described for each option.For information about VPN bandwidth, see the VPN Overview and Calculating network throughput.
There are three options for scaling a Cloud VPN configuration:
Set up a second on-premises VPN gateway device with a different external IP address. Create a second tunnel on your existing Cloud VPN gateway that forwards the same IP range, but pointing at the second on-premises gateway IP. Your Cloud VPN gateway automatically load balances between the configured tunnels. You can set up the VPN gateways to have multiple tunnels load balanced this way to increase the aggregate VPN connectivity throughput.
Redundant on-premises VPN gateways diagram (click to enlarge) Option 2: Scale the Cloud VPN gateway Note: This configuration requires an on-premises VPN gateway that supports using equal-cost multi-path routing (ECMP) between two tunnels having the same on-premises IP ranges. Many software VPNs are not capable of this.Add a second Cloud VPN gateway in the same region as the existing VPN gateway. The second Cloud VPN gateway can have a tunnel that points to the same IP address of the on-premises VPN gateway as the tunnel on the first gateway. Once configured, traffic to the on-premises VPN gateway is automatically load balanced between the two Cloud VPN gateways and tunnels.
Redundant Cloud VPN gateways diagram (click to enlarge) Option 3: Scale both the on-premises VPN gateway and the Cloud VPN gateway Note: This configuration requires an on-premises VPN gateway that supports using equal-cost multi-path routing (ECMP) between two tunnels having the same on-premises IP ranges. Many software VPNs are not capable of this.Combine options 1 and 2 mentioned above to scale throughput. If you have two on-premises VPN gateways and two Cloud VPN gateways, each Cloud VPN gateway can have a tunnel pointing at each on-premises VPN gateway external IP, giving you four load balanced tunnels between the VPN gateway, thereby potentially providing four times the bandwidth.
Redundant Cloud VPN and on-premises VPN gateways diagram (click to enlarge)For more information, see the tutorial Building high-throughput VPNs. You can increase the number of tunnels up to your project's quota. ECMP is used to balance traffic between tunnels.
What's nextExcept as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2025-07-02 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-07-02 UTC."],[],[]]
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4