Connecting to a Windows Azure Virtual Network via a Linux-based Software VPN device

cloud computing final

Summary

This post will show you how to connect a local office or site to a Windows Azure Virtual Network through the use of a software VPN device. A software VPN device is particularly useful when operating in a prototype mode or building a “dev/test” workflow where you want to burst to the cloud fast. Indeed even in the Windows Azure Virtual Networks team, we use these techniques in an automated way to test our own code in Production (TiP) as the Azure platform is constantly shifting every day beneath us. This post will show how to configure OpenSwan VPN on Linux to connect to a virtual network hosted in Windows Azure.

Linux

For Linux, we will use a virtual machine created inside Windows Azure to connect to a Virtual Network hosting another Linux Virtual Machine to show how this can be done.

Create Virtual Machine UI

The first step is to go ahead and create a new Virtual Machine that will host the OpenSwan VPN. In this case I used the Ubuntu 14.04 platform image with an extra small core but any of the Linux images can be used and you can of course bring your own VHD too.

Azure Virtual Machine IP Addresses

Once the VM is created, ensure also, that ports 500 and 4500 (both UDP) are opened too as IPSec depends on these. From the portal UI, there are two interesting artifacts to note, those of the public virtual IP (VIP) and the internal IP. We can use these properties to create a local site for a virtual network which we will then connect to a new Virtual Network. Once you have noted these properties, go ahead and create a new local site under the Networks section of the portal.

Click on Networks tab in the portal then the Local Networks section to begin the add local network process:

 

Virtual Networks Local Networks tab Add Local Network UI Wizard

Add the public IP as the VPN device IP and go ahead and use the internal IP as the local site. You can use a single /32 for the local site or if you wish to make the scenario a little more realistic, feel free to use a bigger subnet, though these IPs in the wider subnet will not be routable unless they are in the same tenant as the Virtual Machine. You can also add some extra network interfaces to your virtual machine to show the use of the wider subnet. Click the new button in the left corner and add a new local network.

 

Add Azure Local Network dialog Azure virtual network local site dialog

In this case we have specified a /24 subnet which the portal indicates that we can have 255 IPs in this subnet, however only the internal IP address of the VM hosting the “local site” will be addressable as Azure’s security model will not allow packets to reach other VMs in this subnet. You can however add multiple network interfaces to the VM with their own IPs within this subnet to simulate more IPs. Once this is done go ahead and create the Virtual Network ensuring that you configure the Virtual Network to communicate the Local Site that was just created by checking the box and saving the update.

 

Azure virtual network create virtual network dialog Enable Azure Virtual network connection to the local network

Once these steps have been completed go ahead and create a Static Routing (IKEv1) Gateway via the portal. While the Gateway creation is taking place (a few minutes), we can begin the process of configuring the OpenSwan VPN server with the right settings to get connected to the Windows Azure Virtual Network.

Create a static routing (IKEv1) Gateway

 

Configuring the Linux VPN

The first step is to use a secure shell client like PuTTy and connect to your Linux Virtual Machine. Once connected you will want to actually install the OpenSwan software and configure it. This can be done via the apt-get command (distro specific – so choose whatever is appropriate) below:

sudo apt-get install openswan

Select No if asked about using X509 certs as the authentication method as we will use shared key secrets to secure the IPSec tunnel. If the install is successful a quick check of the local path will show a program called ipsec is installed:

which ipsec

/usr/sbin/ipsec

You can install OpenSwan from sources too should you wish, but you need to install all the necessary build tools (not on Azure platform image by default).

To configure the VPN itself, we need to edit the following file

sudo vi /etc/ipsec.conf

You will see the following:

config setup
        protostack=netkey
        virtual_private=%v4:100.88.124.0/24
        oe=off
        # Do not set debug options to debug configuration issues!
        # plutodebug / klipsdebug = "all", "none" or a combation from below:
        # "raw crypt parsing emitting control klips pfkey natt x509 dpd private"
        # eg:
        # plutodebug="control parsing"
        # Again: only enable plutodebug or klipsdebug when asked by a developer
        #
        # enable to get logs per-peer
        # plutoopts="--perpeerlog"
        #
        # Enable core dumps (might require system changes, like ulimit -C)
        # This is required for abrtd to work properly
        # Note: incorrect SElinux policies might prevent pluto writing the core
        dumpdir=/var/run/pluto/
        #
        # NAT-TRAVERSAL support, see README.NAT-Traversal
        nat_traversal=yes
        # exclude networks used on server side by adding %v4:!a.b.c.0/24
        # It seems that T-Mobile in the US and Rogers/Fido in Canada are
        plutostderrlog=~/swan.log
        include /etc/ipsec.d/*.conf

Change the config to resemble above, only the subnet created for the local site should change to match what was created for the local site step, in this case 100.88.124.0/24.

If you wish to see the local IPSec logs, uncomment the plutodebug option.

Below this you need to make changes for connection specific settings:

conn vpn
        authby=secret
        auto=start
        type=tunnel
        left=100.88.124.18
        leftsubnet=100.88.124.0/24
        leftnexthop=%defaultroute
        right=137.117.136.XXX
        rightsubnet=192.168.0.0/20
        ike=3des-sha1-modp1024,aes128-sha1-modp1024
        esp=3des-sha1,aes128-sha1
        pfs=no

The highlighted represent two properties that are available from the Virtual Networks UI in the portal (see screen shots above). The first entry, “right”, is the VIP of the Gateway created whilst the other, “rightsubnet” represents the IP space used in the Virtual Network on creation. You must also configure the crypto settings here too and turn off Perfect Forwarding Secrecy (PFS) option. Note also that the config syntax varies depending on the OpenSwan version used, for the exact reference run the command:

man ipsec.conf

 

The gateway VIP to configure the connection toThe on-premises network range
The Virtual Network pre-shared key

The final step is to gather the Pre-shared Key (PSK) from the Azure portal and configure this on the Linux VM. Copy the PSK and then edit the following file:

sudo vi /etc/ipsec.secrets

The exact syntax is as follows: LocalIP GatewayVIP : PSK ‘’Shared Key‘’

#include /etc/ipsec.d/*.secrets
100.88.124.18 137.117.136.230 : PSK "XXXXXXXXXXXXXXXXXXXX"

 

Once done, run the following commands to load the PSK into the running IPSec service, then restart the service before checking that the tunnel is up.

  1. sudo ipsec secrets
  2. sudo service ipsec restart
  3. sudo service ipsec status

IPsec running – pluto pid: 63791

pluto pid 63791

1 tunnels up

some eroutes exist

Once you have a tunnel up to your Gateway you will see the Azure Portal UI update to reflect this fact (the green link in the UI), and you can deploy a virtual machine into the virtual network and begin to do some testing over the network.

This example below deploys a Linux VM into the Virtual Network and shows network connectivity from my local network subnet (100.88.124/24) from the machine hosting OpenSwan to the Virtual Machine (192.168.0.4) inside the Virtual Network in Azure (192.168.0.0/20).

You can see also the data transfers in and out of the Virtual Network as you use it in the Azure Portal UI.

The Azure Portal UI for a connected VPN connection Ping from local network to Azure virtual network Ping from Azure virtual network to local network