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.
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.
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.
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:
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.
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.
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 filesudo 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:
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.
- sudo ipsec secrets
- sudo service ipsec restart
- sudo service ipsec status
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.