One of my favorite things about working with clients is helping them achieve their technical goals in the cloud space. Since my career started years ago, I have always enjoyed building solutions that help teams succeed, and save time. Foghorn empowers me to do this, which is a dream come true.
Recently I had the opportunity to develop a solution for one of our clients to leverage their existing Azure Active Directory. When I was first onboarded, the client’s engineering team was working with OpenVPN on Google Cloud to connect to their project. Coupled with their placement of OpenVPN, and the use of VPC Peering, they linked their VPC with an internal project. This worked for a while but eventually caused issues, as they wanted to leverage GCP Cloud Run to utilize the serverless architecture to host and update their web applications.
When Foghorn began engaging with this client’s engineering team, we sat down to discuss road-maps, goals, and what was currently giving their engineering team issues. They outlined a need for the VPN to work better, leverage their already existing Azure AD, and the implementation of an easy to manage Point-To-Site and Site-To-Site VPN solution. Additionally, they’d like a site-to-site connection to their 2 offices. But alas there was a complication. GCP as of today, doesn’t provide a service for Point-To-Site VPNs. Before the criticism starts, I’m going to cite Dan Blanchard’s “Raving Fans”:
“The first secret is “Decide what you want.” Creating raving fans begins by first deciding what your vision of your company’s relationship with your customers should be. Aspects of your vision are open to change, but you first need to determine your ideal vision for the typical customer you hope to serve. This gives you a framework within which to target customers, a picture to fit customer comments and requests as you get them, and limits on your business as you talk with customers.”
Point-To-Site services in GCP’s environment don’t align with the vision for customer success. I admire that GCP focuses on the Dev portion of DevOps, with Ops taking a back seat. Additionally, we get a unique opportunity to develop a solution that I personally enjoy, which is leveraging a company’s multicloud presence to create a tailored solution.
Many people I speak to seem to have a favorite cloud provider. The reality is that most organizations utilize cloud with multiple providers. Citing Michael Warrilow, a VP Analyst from Gartner: “Most organizations adopt a multi cloud strategy out of a desire to avoid vendor lock-in or to take advantage of best-of-breed solutions.” Sure, your main core infrastructure is utilizing AWS, but maybe your DR environment exists in Azure, or GCP. There’s nothing wrong with this strategy, and I encourage dropping that brand loyalty to essentially unlock the ability to create solutions that your stakeholders actually need, instead of what you can give them with a sole provider. With that in mind, let’s proceed to the solution.
Here’s a diagram showing the proposed plan.
- A subscription!
- A resource Group
- A Virtual WAN
- A VPN Gateway
- A Virtual HUB with private Address space(I used a /24 CIDR, make sure it is not over lapping!)
- A User VPN
- A Site to Site VPN with BGP HA
- Gateway Scale Unit: 1 scale unit – 500mbps X 2
- A Network Security Group to allow the necessary ports.
And for GCP:
- A VPC that hosts your infrastructure (No-Overlapping)
- A Cloud Router
- 2 VPN tunnels for HA to Azure
- 1 VPN Tunnel for Each Office
- Firewall rules.
By Employing Azure’s Virtual WAN, HUB, VPN Gateway, and User VPN (point to site) we were able to construct the VPN Solution with relative ease. By leveraging the already existing Azure AD tenant we could have users connecting to the Azure Network quickly with credentials that they already had. By creating the Virtual WAN, Hub and VPN Gateway we were able to configure the Azure environment to set up connections from GCP.
After the Azure deployment, we added the GCP resources needed, and advertised the BGP peers, using the Public IP Addresses on each respective side, with the accompanied ASN value. Firewall rules were quick and easy to implement as well.
Once the Peering was successfully completed we were able to advertise the BGP routes needed to traverse the tunnel to GCP, and access the resources that were deployed in the project. From there, adding the 2 sites via BGP and Site-to-Site from Google was a breeze.
So there it is, in less than a full workday we had a VPN solution for our client that delivered the needed prerequisites. Candidly, it was a fun project to work on, and I hope to have the opportunity to deploy something similar in the future.
Have any comments or questions, or need help with your multi-cloud networking challenges? Drop us a line: firstname.lastname@example.org.