In this post, I will show you how to set up a VPN between a local/company infrastructure and the Azure cloud. A solution like this is called Hybrid Cloud:
What is VPN?
VPN (Virtual Private Network) is a service that allows you to connect to the Internet from any place in the world via a virtual encrypted tunnel, so that the nodes of the network are transparent to packages sent in this way. In other words, it’s like if we had a part of the Internet just for us. With it, we can be sure that no unauthorized person will be able to intercept and read our data being sent through the Internet, no matter where we are.
What do we need a Hybrid Cloud for?
Let’s imagine a following scenario: there are four teams in our company that use 90% of resources for test and production environments, company’s wiki and git repository etc. Then, a new project appears for which we have to provide development/test/staging environments, and set up Jenkins. Unfortunately, the company does not have sufficient internal resources, and that’s where a Hybrid Cloud can help. What we’d like to do is to create test/staging (etc.) environments in the cloud, which means some virtual machines (vm’s), kubernetes or docker registry. Additionally, we’d like the new resources to be available only through our internal network and inaccessible from the outside.
To achieve this, we have to set up a VPN between our company network and a cloud service provider, e.g. Azure.
VPN with Azure
To start with, let’s picture what we’d like to achieve (the below IPs are examples):
- Our network can be seen from the outside at IP (184.108.40.206)
- In our local network, we have the below address spaces:
- 192.168.0.0/16 (company’s production apps)
- 220.127.116.11/24 (address space of team A)
- 18.104.22.168/24 (address space B)
- 22.214.171.124/24 (address space available to client X)
- Address space of Azure – 10.1.0.0/16
- Public address of Azure – dynamic – 126.96.36.199
To begin with, let’s create a Local Network Gateway component, which we’ll use to map our local network.
Next, we create a virtual network with Azure.
The next step is creating a Virtual Network Gateway that will allow us to configure a VPN connection between the Azure Virtual Network and our local network. In the example below, we’ll assign a dynamic IP address to our gateway. In this case, the dynamic IP address means that a random address will be chosen and it will stay the same disregard of resetting or settings change. A change like that is possible only by destroying and recreating the component.
The last component that we have to create is called Connection. It can be used to connect our local network to the previously created VPN gateway. In order to connect the local network to the Azure network, we have to choose the connection of type Site-to-Site.
We choose the previously created VPN Gateway and a component mapping our local network. Then, we define a password required to establish a connection to our local gateway. The defined password will be needed later in order to configure the local gateway.
As a result, we should have the following components in a group called “fingo-resource”.
At this point, we are almost finished. What’s left is a local VPN gateway configuration. In order to do this, we can download a script that configures the connection (Connection -> Overview -> Download configuration), or use a guide if we do not find configuration for our device:
If we configured our local gateway properly, then in the Virtual Network Gateway component, in Connection, the status should be set to “connected”.
This way, we’ve created a VPN with an Azure Cloud. In order to test the VPN, we’ll create a virtual machine. In the Networking section under “Public IP”, choose “None” (we don’t want our vm’s to be accessible from the outside), and for Virtual network choose the network that we’ve configured before and connected to the VPN.
Let’s check the network configured in this way by pinging our machine (ping 10.1.0.4).
In this post, it was shown how to create a VPN with Azure and, as a result, create a Hybrid Cloud. We’ve achieved our goal: a new internal subnetwork in the company, available for Azure services, and unreachable (secured) for unauthorized access from the outside.
It took us some work, but in the end you do this once and, if need be, update address spaces of our local networks.
Regarding the costs, the utilized set of components is about 25 euro/month (without starting a vm).
You can find more on pricing in the official Azure price list: