One of the challenges to working with Azure is extending on-premise networks to our Azure networks in such a way that access to resources becomes transparent. While this is generally not a problem with corporate networks with established VPNs, it can become more challenging with small businesses or individuals that want to extend their networks to Azure utilizing hardware not on the Validated VPN device list.
Here I will show you how to extend a home network using Smoothwall Express to Azure to allow seamless usage of Azure resources.
It’s a good practice to document expected settings before starting the process to ensure variables are correct each time they are used. Setup for this example:
- Local Firewall / VPN Device: Smoothwall Express 3.1 update 8 (OpenSwan VPN)
- Local DNS Server:0.0.1 (Smoothwall static DNS)
- Local Address Space:
- Local Subnets:
- Azure VNet Name:VPNVNet
- Azure Address Space:
- Azure Subnets:
- Net1: 10.0.40.0/24
- GatewaySubnet: 10.0.41.0/24 — GatewaySubnet is a required name for correct functionality with the NetworkGateway
- Azure Resource Group:tl-vpnrg
- Azure Location:West US 2
- Azure Virtual Network Gateway Name:AzNetworkGateway
- Azure Public IP:AzNetworkGatewayIP
- Azure Local Network Gateway Name:LocalGateway
- Azure Connection Name:HomeConnection
- VPN Type:Policy-based
- Connection Type:Site-to-site (IPsec)
- Gateway Type:VPN
The standard Azure steps for creating a VPN apply up to where the VPN device is setup (step 6 as of this writing).
Once we get to setting up the VPN device we have to move off the beaten path.
Configuring the Smoothwall VPN (using OpenSwan) is straight forward using the GUI. OpenSwan uses Left and Right to denote the Remote and Local endpoints for the VPN connection, an easy mnemonic device.
Left corresponds to your external IP address, Right to the Azure AzNetworkGatewayIP.
The Left subnet is the local vnet address space (10.0.0.0/20) to which you wish to connect, the Right subnet is the VNet address space (10.0.40.0/22) which includes the GatewaySubnet and the Subnet to which you wish to connect.
The PSK (pre shared key) from Azure is entered into the Secret textbox.
The IPSec/IKE settings for Azure can be found here: https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpn-devices#a-nameipsecaipsecike-parameters
After this is completed the IPSec/IKE security settings must be manually set by editing the OpenSwan configuration file using information found at: https://linux.die.net/man/5/ipsec.conf under the IKE and IKEv2 sections. On Smoothwall, this is located at /var/smoothwall/vpn/ipsec.conf. Other software will probably have the file in a different location, check your distribution documentation. On Smoothwall systems this file is overwritten by the system every time the “connections” tab is accessed. To work around this behavior, the script writing the file can be updated at /usr/bin/smoothwall/writeipsec.pl to incorporate the security settings.
Once all the setting are correct Restart the IPSec service (OpenSwan) with this button on the control tab:
There are two indicators for success. First, the GUI icon on Smoothwall will change from Closed to Open. Second, on the Azure portal, the LocalGateway connection (in this case HomeConnection) will show status of Connected. Data In and Data Out will update as soon as information is transferred and may not change until activity takes place.
If you don’t get the connection in a minute or two, check the /var/logs/secure file for errors relating to IPSec or IKE. I found that watching the error log in real time (tail -f /var/logs/secure) while resetting the connection was very useful. I was able to follow the phases of the IKE security negotiation process and see when it failed and for what reason.
To test it out I created a VM on Azure named pingme2 using the Ubuntu 16.04 image and a local VM on my OpenStack cloud named pingmelocal using the very simple CirrOS image. I chose these two images because I am familiar with their default networking characteristic.
$ uname -n
$ ping 10.0.40.4
PING 10.0.40.4 (10.0.40.4): 56 data bytes
64 bytes from 10.0.40.4: seq=0 ttl=61 time=19.313 ms
64 bytes from 10.0.40.4: seq=1 ttl=61 time=18.988 ms
64 bytes from 10.0.40.4: seq=2 ttl=61 time=17.268 ms
--- 10.0.40.4 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 17.268/18.523/19.313 ms
Ping from the Azure VNet to a local machine:
troyadmin@pingme2:~$ uname -n
troyadmin@pingme2:~$ ping 10.0.4.19
PING 10.0.4.19 (10.0.4.19) 56(84) bytes of data.
64 bytes from 10.0.4.19: icmp_seq=1 ttl=61 time=18.1 ms
64 bytes from 10.0.4.19: icmp_seq=2 ttl=61 time=22.3 ms
64 bytes from 10.0.4.19: icmp_seq=3 ttl=61 time=17.9 ms
--- 10.0.4.19 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 17.966/19.473/22.319/2.019 ms
Test that the local DNS is referenced from the Azure VNET:
troyadmin@pingme2:~$ uname -n
troyadmin@pingme2:~$ ping storage
PING storage (10.0.1.65) 56(84) bytes of data.
64 bytes from storage (10.0.1.65): icmp_seq=1 ttl=62 time=18.4 ms
64 bytes from storage (10.0.1.65): icmp_seq=2 ttl=62 time=20.6 ms
--- storage ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 18.474/19.547/20.621/1.082 ms
Connecting a local network to Azure is very easy if the devices to connect are on the validated list, as most of them have prewritten instructions. If your device isn’t on the list it can still connect if it can use the ipsec protocol and be configured to meet the Azure security requirements. Once this is up and functional it’s like having all of Azure connected to your home network. While most mid-sized and larger businesses have the resources for validated devices, the VPN connection for single-users and small businesses will allow them to leverage Azure.