In a recent consulting engagement, our Professional Services team needed to help build a VPN connection between a series of Cisco Routers and a Google Cloud environment. We were surprised to discover that at the time we completed the project, Google did not provide a configuration guide for this common configuration type and wanted to share our experience building the connection. They have since added documentation for IKEv2 based ASR configurations. Our post highlights some important architectural details as well as the configuration requirements (tunnel mode, phase 2 timers) for the tunnels. It also makes use of an inner VRF, unlike Google’s example.
Before we get into the details of the configuration, it’s important to understand the architectural decisions we made. If you wish to make a connection from a single site to two different GCP VPN endpoints you cannot use a traditional static IPSec connection, you must use a routed VPN configuration. The GCP environment will load balance traffic between availability zones across these different paths based on the destination IP address and ignoring different source IP ranges. This means that for redundant connectivity between GCP and a site you must use a routed VPN configuration.
The following Google documentation states very opaquely “When egressing from on-premises the routing to Cloud VPN and the choice of child SA within Cloud VPN are made based on destination IP only.” What this means is that, if you create a static VPN configuration for the same subnet in two different locations you will see outgoing traffic load balanced between them and portions of it dropped if it doesn’t match the VPN traffic selector. As a result, the only really viable option for redundant connectivity to a remote site is to configure a routed VPN.
Now onto some interesting elements of the VPN configuration.
Here are some base device configuration, a hostname, and a VRF:
hostname: rooooter ip vrf gcp-test rd 65001:1
We create a keyring for the peer and define our PSK:
crypto keyring GCP-test-keyring pre-shared-key address 184.108.40.206 key 8OrVZR6YcVog0XEvXoHfGTz7
Define an ISAKMP policy that matches Google’s requirements, note that the phase 2 uses tunnel and not transport mode. This is critical for the tunnel to be properly established:
crypto isakmp policy 10 encr aes authentication pre-share group 2 crypto ipsec transform-set hs1-transport esp-aes esp-sha-hmac mode tunnel
Create an ISAKMP and IPSec profile for the tunnel:
crypto isakmp profile gcp-test-isa vrf gcp-test keyring gcp-test-keyring match identity address 220.127.116.11 255.255.255.255 crypto ipsec profile gcp-test-profile set security-association lifetime kilobytes disable set security-association lifetime seconds 10800 set transform-set hs1-transport set pfs group2 set isakmp-profile gcp-test-isa
Next, we need to define the tunnel that will face the Google Cloud environment. The tunnel mode ipsec ipv4 command is critical. Otherwise, your VPN will build but no traffic will be carried through it:
interface Tunnel2 ip vrf forwarding gcp-test ip address 169.254.0.21 255.255.255.252 ip mtu 1400 tunnel source GigabitEthernet1 tunnel mode ipsec ipv4 tunnel destination 18.104.22.168 tunnel protection ipsec profile gcp-test-profile Finally, we define our BGP router configuration:
router bgp 65001 bgp log-neighbor-changes
We have created a loopback interface for a test network to announce:
interface Loopback0 ip vrf forwarding gcp-test ip address 192.168.2.1 255.255.255.0 ! address-family ipv4 vrf gcp-test redistribute connected neighbor 169.254.0.22 remote-as 65003 neighbor 169.254.0.22 activate exit-address-family
With this configuration in place, you should build the VPN connection to Google Cloud, see your BGP session established and begin bidirectional announcement of routes.
The Stack8 Professional Services team are experts who can assist you with the issues your organization faces daily. For more information, please visit. If you require a managed solution and not just assistance setting up a new connection, our Managed Services team can help build you a custom solution to address your communications needs.
Other Blogs You Might Enjoy
Ready to take your unified communications from headache to hassle-free?
No throwing darts at proposals or contracts. No battling through the back-end. No nonsense, no run-around.