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, with the XTM being the default gateway on

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 and then created 3 virtual subnets:


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


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, 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 network. It was assigned the first address, with the DNS setting pointing to my DC which is on-premise as 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 can route to the 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.


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.

12 thoughts on “Using WatchGuard XTM To Create A Hybrid Cloud With Windows Azure”

  1. Good article. I had already completed setting up my tunnel from our Watchguard XTM525 to Azure. The only thing I am dissapointed about is the fact that I believe the Watchguards are only capable of Static routing. This means that only one site (tunnel) can connect to the Azure tunnel when configured in static mode. I have multiple sites I want to connect to my Azure VNet all with Watchguards however with static i believe this is impossoble, with dynamic it is possible to connect multiple sites to the Azure gateway. If anyone knows a way around this I would be eternally grateful :o)

  2. Having same issue. we use different unit of XTM product in different locations. Unable to get multi site VPN with WG.

  3. Hi Aidan,

    Do you happen to have any information in regards to bandwidth limitations between Azure and Watchguard devices? I am sitting on a 1gbps pipe but I can’t get my site-to-site VPN with Azure to move any faster than about 200mbps. Upon contacting Microsoft they are telling me that no Watchguard device is compatible above the 200mbps limit. Apparently “it is an issue with the Azure gateways not fully supporting Watchguard at this time.” …I have yet to find any concrete evidence behind this, but I am also not finding any Watchguard users who have tried testing these kinds of speeds. I would love to know if you, or anyone else, has run into this? Am I really stuck in the slow lane? Any feedback would be great. Thank you!

    1. My only knowledge of WG limitations with Azure VPN is that they don’t support dynamic gateways. After that, I’d be checking out the max performance metrics in the specs and talking directly to WG.

  4. I have the same setup and Azure VM SMB file shares are not accessible from my onsite network. I can access onsite file shares from a VM in Azure though.

  5. he Aidan,

    I see they have a beta program for version 11.12 which includes dynamic routing. Do you have any information when this will become GA? Not a good practice to start using the beta software in production I think 😉

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.