One question that we are frequently asked is to establish a Point-to-Site (P2S) connection from a client computer based on a Unix-like operating system (like Linux and FreeBSD) and the Virtual Network (VNet) on Azure with the objective to manage their Virtual Machine deployed on cloud. In this article we want illustrate a custom solution for Azure Resource Manager (ARM) deployment model that addresses this request and, for which, we have provided a sample code that automates the setup of the architecture on Azure.

The proposed infrastructure is not based on an Azure Virtual network gateway, but is a mix of Azure IaaS resources and open source community software. It's a solution for whoever wants:

• Complete control of VPN server
• Very low costs with no concern about performance
• P2S automatic setup

It is important to remember that, as for all IaaS approaches, the client will have the responsibility of the infrastructure management and its security.

Target Architecture

Follow a schema of the target architecture that we want to build:

We have following components:

• Target VNet with:
  • One OpenVPN subnet
  • One Network Security Group (NSG) for OpenVPN subnet
  • An undefined number of subnets that contain the Virtual Machines to manage
• OpenVPN Server – CentOS based Virtual Machine
• Client Desktop with Internet connection – It contains a OpenVPN Client

The CentOS based Virtual Machine will contain an OpenVPN server that will be used to create a VPN based on SSLv3/TLSv1 protocol.

We have selected this product for its ability to work through proxy servers. Many client network implementations require that Internet access is routed through proxy servers. For this reason, the OpenVPN server will listen on port 443, which is the HTTPS default port. Normally this port is not filtered by proxy servers. This will allow to establish a management VPN between client and server, even in networks with limited Internet access.

Furthermore, the OpenVPN server is very well known in the open source community and, there are many clients available for different operating systems.

Note: This implementation is based on a single OpenVPN server. It is not recommended to use it for a production environment where high availability is a requirement, or your VPN connection will be used as part of services delivery.

How the architecture works

The OpenVPN server is in an Azure subnet and it will receive all incoming requests from the VPNs connections. The most important task that server will execute is IP Masquerade.

IP Masquerade is a form of network address translation (NAT) through which it is possible to alter the VPN server incoming communications to look like they were originated from it.

Acting in this way, the packages can be routed freely on the VNet and they can reach their destination: the VMs to manage.

As you can see we did not cite the need to add some specific route rule. In effect, by simulating that the packets are originated by OpenVPN, all of them will be routed on various subnets using the system route rule “Local Vnet Roule”.

Note: Even IP Forwarding is not needed, since there are no route rules which send traffic to a NIC that isn't a real destination of network traffic. All incoming traffic is “enveloped” in the VPN tunnel and, in OpenVPN server, will be unwrapped and then sent to its destination without Azure infrastructure actions.

Sample Code

The proposed code for automation has two main components:

1. PowerShell script used to prepare Azure infrastructure
2. Bash script used to execute CentOS server auto-configuration

The first one will execute the steps needed to create the proposed infrastructure and, as last step, it will setup a Virtual Machine Extension that permits the execution of a provided Bash script on the machine at the end of its provisioning.

The Bash script will handle the necessary customizations of CentOS image. Moreover, it will take care of upload, on a new private Azure Blob, the credentials which are necessary to OpenVPN client to establish a connection with the server.

A detailed guide of the code can be found in the GitHub project.

Conclusion

In this article, we have described an architecture, based on a mix of Azure IaaS resources and open source community software to address a particular requirement of some users. We also released a sample code.

This is further proof of how various situations can be addressed easily with the combination of resources and services available on Azure.

NOTE: For those interested in this kind of solution, I'm happy to share that the official implementation to enable OpenVPN support on Azure VPN Gateway is now available. Please refer to, “Configure OpenVPN for Azure point-to-site VPN Gateway (Preview)” on the Microsoft Azure Docs page.