Using WatchGuard XTM To Create A Hybrid Cloud With Windows Azure

My job is weird. I basically get told to learn something and spend time promoting it, teaching it, assisting with it to a Microsoft partner audience in Ireland. Lately we’ve taken on some hardware products and I’ve also been given a target to promote Windows Azure. So I’ve been spending time in the lab at work and in Windows Azure.

The latest “mini project” that I set for myself was to create a hybrid cloud, merging my on-premise Hyper-V farm (with SMB 3.0 storage on DataOn Storage JBOD) with VMs running in Windows Azure. Traffic between the two “sites” would be via a secure site-site VPN tunnel. This is Microsoft’s strategy: hybrid cloud.

The On-Premise VPN Concentrator

The first step in that was to get a new firewall appliance operational. Although you can use an on-premise Windows Server to create a site-site VPN connection, I don’t like that option. I’d rather use an edge appliance so my routing can be simplified.

Note: I’m documenting my experience instead of the specific instructions. You’ll read why later.

My employers recently started distributing the XTM range of universal threat management (UTM) firewall appliances from WatchGuard to the Irish reseller market. I have an old 2 series appliance in my lab, equipping me with firewall, AV, URL management, wireless and VPN connectivity. While the hardware might be old, it’s running the latest software and management interface and gives me all the same functionality as the latest and largest 8 series appliances from WatchGuard (just with smaller scalability).

WatchGuard 2 series XTM

I placed the WatchGuard behind the Netgear ADSL router, and have enabled ports passthrough from the router to the firewall:

• L2TP port: UDP 1701
• IPsec port: UDP 500
• IKEv2 port: UDP 4500

My internal network is physical, operating on 172.16.1.0/24, with the XTM being the default gateway on 172.16.1.1.

Enabling Site-Site VPN in Windows Azure Virtual Networking

The next thing I did was sign into Windows Azure and create a virtual network. It’s not quite obvious, but what you are doing in the Azure portal is creating software-defined networks using Hyper-V Network Virtualization. I created a virtual network called 10.0.0.0/16 and then created 3 virtual subnets:

• 10.0.0.0/24
• 10.0.1.0/24
• 10.0.2.0/24

Any virtual machines I created would reside in those subnets and be assigned IPs from those pools (they appear like DHCP addresses in the guest OS). Note that Azure uses a few of the IPs in each virtual subnet and that the subnets will route automatically to each other within the virtual network.

An additional gateway subnet was created on 10.0.255.0/24.

My virtual network and subnets in Windows Azure

Here’s the fun bit; you can assign IP address(es) for your desired DNS server(s) in the virtual network settings. I assigned 172.16.1.40, my on-premise DC/DNS VM, as the DNS server for this in-Azure virtual network. My plan: I would only run DCs on premise, and everything in Azure will authenticated against my on-premise DCs via the VPN. Honestly, in the real world I think I would run some VMs as DCs in the same domain/forest within Azure for network fault tolerance. Old fashioned AD replication would be used, treating Azure’s virtual network as another AD site.

During the virtual network wizard, I also enabled site-site connectivity and afterwards I created a gateway. That creates the listener in Azure, on a public IP address, that allows a site-site VPN connection. A really long secret key is created.  I documented all the required information and then returned to the lab.

Starting & Testing The Site-Site VPN

I logged into the console for the WatchGuard XTM and created a site-site VPN connection. The connection was initiated, and then there was suspense. In the Azure portal I could see an “attempting connection” status. That sat there for what felt like an eternity. And then … bingo! It connected.

The connected site-site VPN, details obscured

I fired up a VM in Windows Azure on my 10.0.0.0/24 network. It was assigned the first address, 10.0.0.4 with the DNS setting pointing to my DC which is on-premise as 172.16.1.40. With the Windows Firewall configured for ICMPv4 echo requests, I was able to ping in both directions.

The end result? The virtual network in Windows Azure is effectively a remote data center in my “corporate network”. My on-premise 172.16.1.0/24 can route to the 10.0.0.0/16 network/subnets in Windows Azure and back again. I can deploy VMs to the most suitable networks: on-premise or in the public cloud. If I fire up System Center VMM and App Controller, I can delegate users and give them a single portal for deploying VMs on either part of the hybrid cloud.

Some Useful Info

I had two sources of information to implement this solution.

The first was the excellent blog post by Ryan Boud called Creating a VPN between a WatchGuard XTM 510 and Windows Azure Virtual Networks. The terminology for setting up the site-site VPN is confusing: What’s a local subnet? What’s a remote subnet? It’s all relative! Ryan has excellent clear screenshots that inform you what to type where in the Windows Azure portal to create your virtual network and get the gateway operational. He also goes step-by-step through the WatchGuard XTM configuration.

The second is a set of instructions by WatchGuard. Their documentation only covers the XTM side of things but it does give you a nice method for recording the required information from the Azure portal.

Microsoft has also  shared links to instructions for creating site-site VPN connections using devices from lots of manufacturers, such as Cisco, Juniper, F5, Citrix, Fortinet and Openswan.

FYI, my lab is operating on an ADSL line. It has a single IP address. I am still able to do remote device VPN into my lab. In fact, I am able to VPN into the lab from home and communicate with the Windows Azure VMs by routing through the site-site VPN connection. The Windows Azure network is really acting like a remote data center for my lab.

Summary

I thought setting the site-site VPN up between my “private cloud” and Microsoft’s public cloud was going to be a nightmare. Instead, it was easy. In fact, following Ryan’s and WatchGuard’s instructions enabled me to get it working on my first attempt. The results: magic.