What You’ll Learn
- How to create a VPN gateway within a Google Cloud Platform (GCP) Virtual Private Cloud (VPC)
- Define the supernet and network and VPN subnets
- Configure a Cisco IOS XE router to establish an IPsec VPN to the GCP VPN gateway
What You’ll Need
- A GCP account with a valid billing method on file
- Access to an IOS XE router, either physical or virtual
Note: There is a cost for the VPN constructs and associated VPN gateway within GCP. For testing and validation, the cost will be minimal, but ensure that you tear down the VPN after your testing is complete. Additionally, in this tutorial, a virtual Cisco Catalyst 8000 Series Router will be used. Configurations may need to be adjusted, based on the router operating system and version.
The high-level architecture and terms to create this VPN connection are given below. While there are some overlapping names with those used in Amazon Web Services (AWS), not all do. If you are familiar with the other two tutorials that have been written for the ENCC exam, the high-level architecture should look very familiar.
When you first create your GCP account, there is the possibility of none of the services being enabled. If this is the case, you will need to enable the Compute Engine application programming interface (API). To do this, navigate to the API & Services page within the GCP console. From there, click the Enable APIs and Services button. Search for Compute Engine, and click the Compute Engine API. Click the Enable button to enable the API. If this is not done, warnings will appear that some services cannot be used or will just error out.
Once the Compute Engine API is enabled, a default VPC is created. While it is possible to create a separate VPC for the VPN resources required for this tutorial, we will just use the default VPC (called default) for the remainder of this tutorial.
To start the VPN creation process, use the Search feature in the top part of the GCP console and enter vpn. Click the VPN icon that will appear at the top of the search results.
From the VPN page, you’ll be prompted with a button to create a new VPN connection. The GCP VPN creation wizard will then begin to walk you through all required steps to create the VPN connection.
GCP has two different “modes” of VPN operation. For this exercise (and all VPNs that you create moving forward), we’ll be using the High-availability (HA) VPN option. It is possible to create a “Classic” VPN; however, the functionality is limited and is not recommended for current use.
Note: Classic VPN is limited to a single tunnel, route-based VPN. It is not possible to run a routing protocol over the top of the VPN.
Note: HA VPN can be configured with a variety of tunnel options. For the purposes of this tutorial, we’ll be configuring a single tunnel to a single cloud router. GCP will indicate that this configuration is not guaranteed to meet the 99.99 percent service level agreement (SLA). This warning can be ignored.
Once the HA VPN option is selected, you’ll be presented with a screen with several steps, the first of which is to create the Cloud HA VPN gateway. You’ll need to provide a name, the VPC that this gateway will reside in, and the region in which this VPN gateway should exist. By default, IPv4-only addressing is selected, but if you wish to run a dual-stack tunnel, IPv4 and IPv6 can be selected.
Once the gateway is created, you’ll need to create the peer gateway, which is the virtual construct that defines the “remote” side of the VPN within the cloud (that is, your router on premises). Ensure that On-prem is selected, and then create a new peer VPN gateway.
The peer gateway will need a name, the IP address of the peer gateway (which will be the public IP address of your router), and the autonomous system number (ASN) of the peer router. The ASN can be any valid ASN; however, it is recommended to use a private ASN (64512-65534). If you are unsure of which ASN to use, you can use the ASN of your ISP or a private ASN.
Once the peer gateway is created, you’ll be returned to the main wizard window. You’ll now be able to define the number of tunnels created for the VPN. In our case, we’ll just be creating a single tunnel. After this has been selected, you’ll be able to select a cloud router or create a new one. When the wizard appears to create a new cloud router, you’ll need to provide a name, ASN, Border Gateway Protocol (BGP) interval (if desired to change from the default 20), and which routes that you wish to advertise over the tunnel via BGP.
Once the cloud router is created and you are returned to the VPN creation wizard, your window should look similar to the following:
The next step is to define the Internet Key Exchange version 2 (IKEv2) pre-shared key for the tunnel that we are creating. This key will be used to authenticate the tunnel between the cloud router and the on-premises router. The key can be any string of characters, but it is recommended that you use a strong password.
Now that the tunnel is created, you’ll be prompted to define the BGP session for the tunnel. It is possible to defer the BGP session creation, but if you create it in the wizard, you’ll be prompted with a screen similar to the following:
You’ll need to provide a name for the session and the peer ASN (which will be the ASN of your on-premises router). You can optionally define the BGP session authentication key. This key can be any string of characters, but it is recommended that you use a strong password.
Optionally, if you skip this portion, you can configure the BGP policy under the Cloud VPN Tunnels section of the VPN control panel by clicking Configure BGP Session for the tunnel.
Once this final step is complete, you can click through and download the configuration for your router. However, if you miss this step, you can always download the configuration from the VPN control panel, under the Peer VPN Gateways section.
The configuration is provided in the window for a copy and paste as well as available for download once the manufacturer, model, and version are selected.
We’ve now completed the VPN scaffolding, and we can ensure that our firewall is configured correctly and build our router configuration.
Now that the VPN has been configured, we need to ensure that the cloud firewall rules allow traffic into the VPC. Start by searching for **firewall" in the GCP console and clicking the Firewall icon that appears at the top of the search results.
You should be placed into the Firewall policies pane. From there, click the three vertical dots at the top of the window, and select Create Firewall Rule.
You’ll need to provide a firewall rule name, the network (VPC) that you want the rule to affect (in our case, the default network), which direction you wish the rule to be applied, and the source networks to be affected by the firewall rule. In the following example, I have entered my home network address space (192.168.128.0/24).
Scrolling down, you’ll want to ensure that UDP, TCP, and ICMP are allowed. Alternatively, you could permit all protocols and ports as long as you are aware of the security implications.
Click Create to apply the new firewall rule to your VPC’s policy.
Now that the VPN has been created and the firewall rules have been applied, we can build the router configuration. For this tutorial, we’ll be using a virtual Cisco Catalyst 8000V router. The configuration will be similar for other Cisco routers, but the syntax may be slightly different.
Before building the configuration, we’ll need to gather the IP addresses of the virtual tunnel interface (VTI), which will be built over the IPsec tunnel. Return to the VPN configuration pane and ensure that you’re on the Cloud VPN Tunnels page. The tunnel should have values under the Cloud Router BGP IP address and Peer BGP IP address, as shown in this figure:
We’ll need to use these IP addresses in the configuration of the router. While we can use the previously downloaded configuration, a slightly more condensed configuration is provided with this tutorial. The configuration is available for download here.
This configuration template requires the following variables to be populated:
<GCP-PUBLIC-IP>: Public IP address of the GCP VPN gateway<PSK>: Pre-shared key<LOCAL-PUBLIC-IP>: Your public IP address<LOCAL-VTI-IP>: IP address of your local endpoint over the GCP tunnel (address given above for the “Peer BGP IP address”)<REMOTE-VTI-IP>: IP address of the GCP endpoint for the tunnel (address given above for the “Cloud Router BGP IP address”)<UPSTREAM-INTERFACE>: Interface of your router facing the internet<LOCAL-AS>: BGP ASN of your local router<REMOTE-AS>: BGP ASN of the GCP cloud router<LOCAL-NETWORK>: Subnet of the local network behind the on-premises router that you wish to advertise via BGP<LOCAL-NETWORK-MASK>: Mask of the local network behind the on-premises router that you wish to advertise via BGP
Some assumptions are made for the fragmentation and maximum segment size (MSS) and maximum transmission unit (MTU). But in this instance, even if large packets are sent, there is no traffic, so the CPU load on the device—regardless of physical or virtual—should not be significant.
Once the configuration has been edited and applied to your edge device, the tunnels should connect to GCP. We can verify this using show crypto ikev2 sa [detail], a sample output of which is shown here:
IPv4 Crypto IKEv2 SA
Tunnel-id Local Remote fvrf/ivrf Status
3 192.168.128.92/4500 34.157.245.14/4500 none/none READY
Encr: AES-CBC, keysize: 128, PRF: SHA256, Hash: SHA256, DH Grp:16, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 28800/15728 sec
CE id: 0, Session-id: 1
Local spi: A9D4F5D1ECBE00A5 Remote spi: 16D801035147E9B7
Status Description: Negotiation done
Local id: <LOCAL-PUBLIC-IP>
Remote id: 34.157.245.14
Local req msg id: 271 Remote req msg id: 369
Local next msg id: 271 Remote next msg id: 369
Local req queued: 271 Remote req queued: 369
Local window: 5 Remote window: 1
DPD configured for 60 seconds, retry 5
Fragmentation not configured.
Dynamic Route Update: disabled
Extended Authentication not configured.
NAT-T is detected inside
Cisco Trust Security SGT is disabled
Initiator of SA : Yes
PEER TYPE: Other
Once we can confirm that the IKEv2 security associations have been established, we can verify whether the IPsec security associations have formed as well. The command to view the output is show crypto ipsec sa [detail], and the output should look similar to the following:
interface: Tunnel1
Crypto map tag: Tunnel1-head-0, local addr 192.168.128.92
protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer 34.157.245.14 port 4500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 8203, #pkts encrypt: 8203, #pkts digest: 8203
#pkts decaps: 7875, #pkts decrypt: 7875, #pkts verify: 7875
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#pkts no sa (send) 0, #pkts invalid sa (rcv) 0
#pkts encaps failed (send) 0, #pkts decaps failed (rcv) 0
#pkts invalid prot (recv) 0, #pkts verify failed: 0
#pkts invalid identity (recv) 0, #pkts invalid len (rcv) 0
#pkts replay rollover (send): 0, #pkts replay rollover (rcv) 0
##pkts replay failed (rcv): 0
#pkts tagged (send): 0, #pkts untagged (rcv): 0
#pkts not tagged (send): 0, #pkts not untagged (rcv): 0
#pkts internal err (send): 0, #pkts internal err (recv) 0
local crypto endpt.: 192.168.128.92, remote crypto endpt.: 34.157.245.14
plaintext mtu 1422, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet1
current outbound spi: 0x8C49BBAB(2353642411)
PFS (Y/N): Y, DH group: group16
inbound esp sas:
spi: 0x20C196D(34347373)
transform: esp-256-aes esp-sha-hmac ,
in use settings ={Tunnel UDP-Encaps, }
conn id: 2050, flow_id: CSR:50, sibling_flags FFFFFFFF80004048, crypto map: Tunnel1-head-0, initiator : True
sa timing: remaining key lifetime (k/sec): (4607981/1592)
IV size: 16 bytes
replay detection support: Y replay window size: 1024
Status: ACTIVE(ACTIVE)
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x8C49BBAB(2353642411)
transform: esp-256-aes esp-sha-hmac ,
in use settings ={Tunnel UDP-Encaps, }
conn id: 2049, flow_id: CSR:49, sibling_flags FFFFFFFF80004048, crypto map: Tunnel1-head-0, initiator : True
sa timing: remaining key lifetime (k/sec): (4607988/1592)
IV size: 16 bytes
replay detection support: Y replay window size: 1024
Status: ACTIVE(ACTIVE)
outbound ah sas:
outbound pcp sas:
We also should validate the status of our BGP peering with GCP. This can be found by using the sh ip bgp summ command:
BGP router identifier 192.168.128.92, local AS number 65001
BGP table version is 3, main routing table version 3
2 network entries using 496 bytes of memory
2 path entries using 272 bytes of memory
2/2 BGP path/bestpath attribute entries using 592 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 1384 total bytes of memory
BGP activity 2/0 prefixes, 2/0 paths, scan interval 60 secs
2 networks peaked at 20:55:55 Oct 24 2023 UTC (20:24:56.107 ago)
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
169.254.208.17 4 65010 2867 3099 3 0 0 15:54:39 1
We have an active relationship with the GCP peer and are receiving the prefix from our supernet, as seen from sh ip route bgp:
10.0.0.0/20 is subnetted, 1 subnets
B 10.138.0.0 [20/100] via 169.254.208.17, 20:30:59
We can also validate the status of the tunnel from the GCP VPN dashboard. Ensure that you’re in the Cloud VPN Tunnels section and scroll over the dialog box to view the status of the tunnel and the BGP session. They should say “Established” and “BGP established,” respectively, with a green check mark next to each.
The VPN has now been configured!
Congratulations, you have successfully configured an IPsec VPN from an on-premises device to a GCP VPN gateway!