GSP062

Overview
This hands-on lab will show you how to create secure, high-throughput VPN and test the speed.
Secure communication between Google Cloud and other clouds or on-premises systems is a common, critical need. Fortunately, Google Cloud makes it easy for you to create a secure Internet Protocol security (IPsec) virtual private networks (VPNs) to achieve this goal. If a single tunnel does not provide necessary throughput, Google Cloud can smoothly distribute traffic across multiple tunnels to provide additional bandwidth.
Objectives
Create VPN
- Create a Virtual Private Cloud (VPC) named
cloud
to simulate your Google Cloud network, and a VPC named on-prem
(on-premises) to simulate an external network.
- Create VPN gateways, forwarding rules, and addresses for the
cloud
VPC.
- Form a tunnel for the new VPN, and route traffic through it.
- Repeat the VPN creation process for the
on-prem
VPC, creating a second VPN.
Test VPNs
- Create a virtual machine (VM) using Compute Engine for throughput load testing.
- Test throughput speed of a single VPN using
iperf
.
Prerequisites
Task 1. Creating the cloud VPC
In this section, you will:
- Create a VPC to simulate your cloud production network.
- Allow common types of traffic to flow through the VPC.
- Create a subnet for deploying hosts.
- After you start up Cloud Shell, create a custom VPC named
cloud
associated with your Google Cloud project by running the following:
gcloud compute networks create cloud --subnet-mode custom
This VPC allows you to use non-default IP addressing, but does not include any default firewall rules.
- Run the following to enable
SSH
and icmp
, because you'll need a secure shell to communicate with VMs during load testing:
gcloud compute firewall-rules create cloud-fw --network cloud --allow tcp:22,tcp:5001,udp:5001,icmp
- Create a subnet within this VPC and specify a region and IP range by running:
gcloud compute networks subnets create cloud-east --network cloud \
--range 10.0.1.0/24 --region {{{project_0.default_region_2 | REGION2}}}
In this solution, you'll be using 10.0.1.0/24
and the region.
Task 2. Creating the on-prem VPC
In this section create a simulation of your on-prem
VPC, or any network you want to connect to cloud
. In practice you'll already have resources here, but for the purpose of creating tunnels and validating configurations, follow these steps.
- In Cloud Shell create a new custom subnet VPC associated with your project named
on-prem
by running:
gcloud compute networks create on-prem --subnet-mode custom
- Run the following to enable
SSH
and icmp
for hosts in the on-prem
VPC, because you'll need a secure shell to communicate with VMs during load testing:
gcloud compute firewall-rules create on-prem-fw --network on-prem --allow tcp:22,tcp:5001,udp:5001,icmp
- Specify the subnet prefix for the region using the following command:
gcloud compute networks subnets create on-prem-central \
--network on-prem --range 192.168.1.0/24 --region {{{project_0.default_region |REGION}}}
Note: In this example, you assign `192.168.1.0/24` to the region.
Create two custom VPCs with subnetworks and firewall rules.
Task 3. Creating VPN gateways
Each environment requires VPN gateways for secure external communication. Follow these steps to create the initial gateways for your cloud and on-prem
VPCs:
- In Cloud Shell create a VPN gateway named
on-prem-gw1
in the on-prem
VPC and region:
gcloud compute target-vpn-gateways create on-prem-gw1 --network on-prem --region {{{project_0.default_region |REGION}}}
- Now create a VPN gateway named
cloud-gw1
in the cloud
VPC and region:
gcloud compute target-vpn-gateways create cloud-gw1 --network cloud --region {{{project_0.default_region_2 | REGION2}}}
Task 4. Creating a route-based VPN tunnel between local and Google Cloud networks
The VPN gateways each need a static, external IP address so that systems outside the VPC can communicate with them. Now you'll create IP addresses and routes on the cloud and on-prem
VPCs.
- In Cloud Shell allocate the IP for the
cloud-gw1
VPN gateway:
gcloud compute addresses create cloud-gw1 --region {{{project_0.default_region_2 | REGION2}}}
- Then allocate the IP for the
on-prem-gw1
VPN gateway:
gcloud compute addresses create on-prem-gw1 --region {{{project_0.default_region |REGION}}}
- Now store the gateway addresses so you won't have to look them up in later commands.
First, for the cloud-gw1
gateway:
cloud_gw1_ip=$(gcloud compute addresses describe cloud-gw1 \
--region {{{project_0.default_region_2 | REGION2}}} --format='value(address)')
Second, for the on-prem-gw1
gateway:
on_prem_gw_ip=$(gcloud compute addresses describe on-prem-gw1 \
--region {{{project_0.default_region |REGION}}} --format='value(address)')
- Now you'll create forwarding rules for IPsec on the
cloud
VPC. You'll need to create forwarding rules in both directions.
Forward the Encapsulating Security Payload (ESP) protocol from cloud-gw1
:
gcloud compute forwarding-rules create cloud-1-fr-esp --ip-protocol ESP \
--address $cloud_gw1_ip --target-vpn-gateway cloud-gw1 --region {{{project_0.default_region_2 | REGION2}}}
Forward UDP:500
traffic from cloud-gw1:
gcloud compute forwarding-rules create cloud-1-fr-udp500 --ip-protocol UDP \
--ports 500 --address $cloud_gw1_ip --target-vpn-gateway cloud-gw1 --region {{{project_0.default_region_2 | REGION2}}}
Forward UDP:4500
traffic from cloud-gw1:
gcloud compute forwarding-rules create cloud-fr-1-udp4500 --ip-protocol UDP \
--ports 4500 --address $cloud_gw1_ip --target-vpn-gateway cloud-gw1 --region {{{project_0.default_region_2 | REGION2}}}
- Use the same method to create firewall forwarding rules for the IPsec tunnel on the
on-prem
VPC. This step allows the IPsec tunnel to exit your firewalls:
Forward the ESP protocol from on-prem-gw1
:
gcloud compute forwarding-rules create on-prem-fr-esp --ip-protocol ESP \
--address $on_prem_gw_ip --target-vpn-gateway on-prem-gw1 --region {{{project_0.default_region |REGION}}}
Forward UDP:500
traffic, used in establishing the IPsec tunnel from on-prem-gw1:
gcloud compute forwarding-rules create on-prem-fr-udp500 --ip-protocol UDP --ports 500 \
--address $on_prem_gw_ip --target-vpn-gateway on-prem-gw1 --region {{{project_0.default_region |REGION}}}
Forward UDP:4500
traffic, which carries the encrypted traffic from on-prem-gw1
:
gcloud compute forwarding-rules create on-prem-fr-udp4500 --ip-protocol UDP --ports 4500 \
--address $on_prem_gw_ip --target-vpn-gateway on-prem-gw1 --region {{{project_0.default_region |REGION}}}
Create two VPN gateways and necessary forwarding rules.
Ordinarily you would need to go generate a secret for the next step, where you create and validate the tunnels on-prem-tunnel1
and cloud-tunnel1
. For details about how to create and securely store secrets, view the Secret Manager conceptual overview guide. For now just use the string "sharedsecret".
Create a tunnel for the local network on-prem-tunnel1
, and for the cloud-based network cloud-tunnel1
. Each network must have a VPN gateway, and the secrets must match. In the following two commands, where you would, in a production scenario, replace [MY_SECRET]
with the secret you generated, replace it with "sharedsecret"
- Create the VPN tunnel from
on-prem
to cloud
:
gcloud compute vpn-tunnels create on-prem-tunnel1 --peer-address $cloud_gw1_ip \
--target-vpn-gateway on-prem-gw1 --ike-version 2 --local-traffic-selector 0.0.0.0/0 \
--remote-traffic-selector 0.0.0.0/0 --shared-secret=[MY_SECRET] --region {{{project_0.default_region |REGION}}}
- Create the VPN tunnel from cloud to on-prem:
gcloud compute vpn-tunnels create cloud-tunnel1 --peer-address $on_prem_gw_ip \
--target-vpn-gateway cloud-gw1 --ike-version 2 --local-traffic-selector 0.0.0.0/0 \
--remote-traffic-selector 0.0.0.0/0 --shared-secret=[MY_SECRET] --region {{{project_0.default_region_2 | REGION2}}}
Now that you've created the gateways and built the tunnels, you need to add routes from the subnets through the two tunnels.
- Route traffic from the
on-prem
VPC to the cloud 10.0.1.0/24
range into the tunnel:
gcloud compute routes create on-prem-route1 --destination-range 10.0.1.0/24 \
--network on-prem --next-hop-vpn-tunnel on-prem-tunnel1 \
--next-hop-vpn-tunnel-region {{{project_0.default_region |REGION}}}
- Route traffic from the
cloud
VPC to the on-prem 192.168.1.0/24
range into the tunnel:
gcloud compute routes create cloud-route1 --destination-range 192.168.1.0/24 \
--network cloud --next-hop-vpn-tunnel cloud-tunnel1 --next-hop-vpn-tunnel-region {{{project_0.default_region_2 | REGION2}}}
Create two VPN tunnels.
Task 5. Testing throughput over VPN
At this point, you've established a secure path between the on-prem and cloud VPCs. To test throughput use iperf, an open-source tool for network load testing. To test, you'll need a VM in each environment, one to send traffic and the other to receive it, and you'll create them next.
Single VPN load testing
Now you'll create a virtual machine for the cloud VPC named is cloud-loadtest
. This example uses a Debian Linux image for the OS.
Note: If you have an existing project, feel free to omit this step and use existing resources. Bandwidth for a VM is 2 Gbps * vCPUs, so you'll want a 4 vCPU minimum.
- Run the following:
gcloud compute instances create "cloud-loadtest" --zone {{{project_0.default_zone_2 |ZONE2}}} \
--machine-type "e2-standard-4" --subnet "cloud-east" \
--image-family "debian-11" --image-project "debian-cloud" --boot-disk-size "10" \
--boot-disk-type "pd-standard" --boot-disk-device-name "cloud-loadtest"
- Create a virtual machine for the
on-prem
VPC named on-prem-loadtest
. This example uses the same Debian image as in the cloud VPC. Omit this step if you have existing resources.
Run the following:
gcloud compute instances create "on-prem-loadtest" --zone {{{project_0.default_zone |ZONE}}} \
--machine-type "e2-standard-4" --subnet "on-prem-central" \
--image-family "debian-11" --image-project "debian-cloud" --boot-disk-size "10" \
--boot-disk-type "pd-standard" --boot-disk-device-name "on-prem-loadtest"
-
SSH into each VM, using the Console or command line, and install a copy of iperf with the following command line:
sudo apt-get install iperf
- On the
on-prem-loadtest
VM, run this command:
iperf -s -i 5
You have created an iperf server on the VM that reports its status every 5 seconds.
- On the
cloud-loadtest
VM, run this command:
iperf -c 192.168.1.2 -P 20 -x C
This creates an iperf client with twenty streams, which will report values after 10 seconds of testing.
Create two VMs and install iperf via ssh.
Trouble shooting for the issues you may face
Note: This is not part of lab instructions.
- While creating tunnels for the local network, if you forgot to replace [MY_SECRET] with "sharedsecret".
You can delete the created VPN tunnels by following command:
gcloud compute vpn-tunnels delete [tunnel-name] --region [region]
- replace [tunnel-name] with name of the tunnel
- replace [region] with the region which you specified while creating tunnel.
- If you are having trouble with the section single VPN load testing:
- If you are trying to see the forwarding rules that you created in the Console:
- In the Navigation menu go to the Networking section.
- Click on Network Connectivity > VPN.
- Click on the Cloud VPN Gateway to view the Cloud VPN Gateway details page.
Congratulations!
Take your next lab
Continue with Cloud CDN, or check out these suggestions:
What's next
Google Cloud training and certification
...helps you make the most of Google Cloud technologies. Our classes include technical skills and best practices to help you get up to speed quickly and continue your learning journey. We offer fundamental to advanced level training, with on-demand, live, and virtual options to suit your busy schedule. Certifications help you validate and prove your skill and expertise in Google Cloud technologies.
Manual Last Updated February 25, 2025
Lab Last Tested February 25, 2025
Copyright 2025 Google LLC All rights reserved. Google and the Google logo are trademarks of Google LLC. All other company and product names may be trademarks of the respective companies with which they are associated.