Creating a VPN between a WatchGuard XTM 510 and Windows Azure Virtual Networks

So there are only two supported hardware vendors for Windows Azure Virtual Networks (VPNs):

  • Cisco:
    • ASA – OS version 8.3
    • ASR – IOS 15.1 (Static routing), IOS 15.2 (dynamic routing)
    • ISR – IOS 15.0 (Static routing), IOS 15.1 (dynamic routing)
  • Juniper
    • SRX – JunOS 10.2 (static), JunOS 11.4 (dynamic)
    • J-Series – JunOS 10.4r9 (static), JunOS 11.4 (dynamic)
    • ISG – ScreenOS 6.3 (static and dynamic)
    • SSG – ScreenOS 6.2 (static and dynamic)

Windows Server 2012 Routing and Remote Access Service is also supported.

Helpfully Microsoft has created some templates for all of the above to help you create the VPN connections.

But if you’ve got something that isn’t supported?

Well you’re on your own! No support from Microsoft at all.

We use WatchGuard XTM 510 firewalls. Whilst not the most user friendly or feature packed, they are quite reliable.

Not being one to be deterred by this I forged on and got it working!

This worked for me; I hope it works for you!


  1. A Windows Azure subscription (can be a trial)
  2. A WatchGuard XTM 510 Firewall (will probably work with all XTM series, not sure about the hypervisor based products)
  3. Know what your internal IP address range(s) is that you want to connect to Azure
  4. Know what your external IP address is that you’ll be creating your VPN tunnel from is (remember to check your outbound NAT settings if necessary)
  5. Know what IP subnet you want in Azure
  6. Some time and patience(don’t rush it or you’ll have start all over again)

Step 1

Log in to Azure (

Go to the bottom left hand corner and select New. Navigate to Networks, Virtual Network, Custom Create

Azure Portal - Create New virtual network

Create new Virtual network

Step 2

In the Virtual Network Details put in your details (remember to pick the appropriate region). Create a new affinity group if necessary or select a pre-existing one.


Step 3

If you want your Azure VMs to use your internal DNS servers you must add it here. Select Site-To-Site-VPN and Specify a New Local Network (this is your internal office/data centre network not Azure’s). It should end up like this


Step 4

This step and the next are very important and is all about your local network, not the network you’ll be creating in Azure (that comes later). Make sure you enter WatchGuard’s External IP address here as shown below:


Step 5

Name the network something meaningful to you. Could be OfficeNetwork as shown, could be CoreServers just make sure it makes sense to you. Add the address space(s) of your local network not the network you’ll be creating in Azure (that comes later).


Step 6

This is where you create your IP ranges for your Azure VMs to use. I’d suggest something completely different to what you’re using in house. So if you’re using 192.168.x.x ranges, go for the 10.x.x.x or 172.16.x.x – that way if you see that IP address anywhere in logs, firewall rules/notifications, etc. you’ll know it’s not local to you instantly.

The first 3 or 4 (can’t remember exactly) IP addresses of your range(s) are taken by Azure for “internal purposes” so don’t worry if you’re first VM doesn’t have a 10.x.x.1 IP address. I’d suggest creating a Gateway subnet too, this way you can have multiple subnets in Azure and they can communicate (I think)! If you make it the lower end of the range as I’ve done then you know where you stand (you could of course make it the top end, middle, anywhere you like but I like to keep mine tidy). If you do the same as below you may end up your first VM having a .12 IP address! Don’t worry it’s just an IP address (see Important Notes at the bottom of this post)


Step 7

So Azure will then go off and create the Virtual Networks, this will take several minutes so don’t be impatient. Once the network is created you’ll need to create the gateway (this seems odd as you’ve just created the network but MS won’t just give you an IP address straight away you need to ask for one). So click on “Create Gateway” and “Static Routing” at the bottom of the Dashboard view. This will again take some time.


Step 8

Now Azure should’ve given you your external IP address, in the example below I’ve redacted mine but that’s where it’ll be. Write this down. Be aware that if you ever delete and recreate your Virtual Network Gateway it’ll be different.


Step 9

To create the VPN you’ll need the preshared key, without this there’s no VPN for you! So once everything is ready as above click on the “Manage Key” button at the bottom, I’d advise copying and pasting this to notepad as you’ll need it later on.


Step 10

Open Policy Manager for your WatchGuard firewall and go to VPN -> Branch Office Gateways. You’ll be presented with the New Gateway screen


Step 11

Enter the preshared key you pasted into notepad earlier (you can paste into this field using the keyboard CTRL+V). Click Add in the Gateway Endpoints section and enter the information as shown below. It may seem wrong to enter the Azure external IP address twice but it worked for me. Other instructions I read said to enter the internal IP address of the Azure Gateway in the “Specify the gateway ID for tunnel authentication” but that didn’t work for me.


Step 12

Once you’ve entered the information click on the Phase 1 Settings tab at the top and set the mode to Main, NAT Traversal to on, IKE Keep-alive on and everything else as shown below. The next step covers the Transform Settings.


Click on Edit to change what is there. Needs to be set SHA1, AES (128-bit), SA Life 8 Hours and key group Diffie-Hellman Group 2.


Step 13

Click OK to close the Branch Office Gateway, click Close on the Gateway list. Go to VPN -> Branch Office Tunnels. Click Add.


Step 14

Give your Tunnel a meaningful name (ToAzure for example). Make sure you select the correct Gateway under name. Click Add. In the Local subnet box enter the IP range you told Azure about in step 5. In my case its and the Remote range is Leave everything else alone (you can amend later if you want – one thing at a time)


Step 15

Click on Phase 2 Settings (make sure PFS is OFF). Click Remove to get rid of the default IPsec proposal, click Add. Give the proposal a meaningful name. Make sure the type is ESP, Authentication is SHA1, Encryption is AES (128-bit). On the Force Key Expiration options set to 1 hour and 102400000 kilobytes (seems a lot but that’s what MS want). Click OK.


Step 16

Make sure the Multicast settings are off.


Step 17

To check for any errors you can increase the Diagnostic logging level on the Firewall. In Policy Manager go to Setup -> Logging. Click Diagnostic Log Level… Change VPN IKE logging level to Information


Step 18

Click OK, Click Close and save you policy to your Firebox.

Step 19

Once your policy is applied go to Firebox System Manager and go to the Traffic Monitor tab; in the filter box type “ike” (no quotes) to watch the tunnel diagnostic output. On the Front Panel tab you should see a new entry under Branch Office VPN Tunnels like this:

PROOFWhat’s Next?

Now that you’ve created your tunnel and you can control what traverses it just like any other tunnel or policy. To further secure your Firebox I’d suggest creating a new alias for the scope in Azure with the subnet.

If you found this helpful please leave me a comment – it’s always good to know I’ve helped at least one person!

Important Notes

Azure VMs are leased IP addresses by the Azure DHCP platform and not any internal DHCP server you may create (don’t create one – there is no point). Azure DHCP leases are for 150 years (that’s not a typo)! If you change your IP address from dynamically assigned to statically assigned (even if you keep the same IP address I believe) your VM will become inaccessible! No RDP, No HTTP, NOTHING. Microsoft’s Configuration Management Database keeps track of every IP address it leases. If your machine isn’t using DHCP it’ll know and kill access to it.

How this will work with technologies like Network Access Protection I don’t know. I’d imagine IPsec enforcement would work as that doesn’t rely on changing DHCP leases like NAP DHCP enforcement does. Maybe I’ll do a post on that on day!


Posted on 10 May, 2013, in Azure, Microsoft, VPN, WatchGuard and tagged , , , . Bookmark the permalink. 23 Comments.

  1. Excellent article. Worked flawlessly for me.

  2. You are my hero! Thank you so much. Worked on my XTM 505.

  3. i’m not sure why i created the BOVPN but nothing happen in the firewall. Is there anything like in Cisco where we need to specify it to the external interface? I’m doing it between XTM515 & XTXM520 which should be straightforward …. headache …

  4. About Step 12: You must not avtivate “IKE Keepalive” and “DPD” at the same time, as this will create conflicts. IKE Keepalive is proprietary only to WatchGuard boxes at both endpoints. DPD should only be used, if the other endpoint is correctly configured to use DPD as well!

  5. 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)

  6. didn’t work for me…. for about 10 hours of trying …. until…. I clicked on Rekey BOVPN tunnel in the front panel display – then voilà !

    Excellent walk through.

    using an XTM535

  7. HI hmmconfused. Do you know of any way to connect multiple Watchguards to the Azure VPN? Apparently Watchguard are working on IKEv2 but not available until next summer!

  8. Hello Hmmconfused, thanks for your article! I was wondering if you ever did any throughput testing on your Watchguard-Azure VPN when you had it in place? We have built our tunnel but we are not able to surpass 200mbps in speed. After contacting Microsoft they are telling us that the faster Azure gateways do not support Watchguard, and that for better throughput we need something like Barracuda, Juniper, etc. We have a 1gig WAN connection and would love to take advantage of it S2S with Azure… but I’m not replacing all my WatchGuard gear to do it. Any suggestions?

    • I would suggest to look at an RRAS Server. Not ideal but would give you access to the higher speed gateways.

      Alternatively have a look at getting an ExpressRoute connection, that will give you everything you need and you won’t need to replace your WatchGuards or change their config.

      How are your WatchGuards currently configured?

      • Thanks for the input. I will take a glance at RRAS, but you’re right, it is not ideal.

        I took a look at the ExpressRoute but not in depth. My initial understanding was that ExpressRoute was just a higher tier for S2S VPN, or so it was explained by MS when we started down this road, but have since learned it is something entirely different. I would need to work with my ISP to get that setup – is that right?

        My WGs are currently configured to connect with Azure as a simple IKE BOVPN. We have successfully configured it a couple of different ways but none of them really impact our bandwidth.

      • So there are two types of ExpressRoute, first is connected to your MPLS network and gives you good throughput, it essentially makes Azure another network location in your WAN. Works well, there are some potential DLP issues but your watch guards will help, especially with IDS and IDP enabled. Your ISP manages the network routes for you via BGP.

        Second option connects via an enabled datacenter, these are typically Equinix DCs. You are in charge of BGP configuration in this instance, these are typically for service providers or large enterprises.

      • I gotcha, thanks again. I will take a harder look at the MPLS ExpressRoute. We definitely don’t need to go the DC route.

  9. Thanks, I realize this is an old article but still helped me to setup a tunnel to MS… one thing has changed however, they now default to AES 256 instead of AES 128…

  10. Thanks for this article! It’s been a great help in establishing our VPN tunnel. I realize this is over a year old but I am having an issue that I am pulling my hair out over. I am able to establish the VPN tunnel between our Watchguard and Azure but the tunnel disconnects after an hour and will not reconnect. I have figured out tweaking a setting (ie change from AES 128 to 256) then writing to the box will reestablish the connection but like clockwork it will drop in an hour. Have you seen this? A quick search finds its a common issue across multiple devices but I cannot find any Watchguard specific help.

    • Unfortunately I don’t have access to a WatchGuard device. Have you tried having continual traffic running, like a constant ping between servers?

      They are supported devices now so you should be able to get support from Microsoft/WatchGuard.

      • MS load balancers are blocking our ping’s from in our network to our Azure VM’s. We can ping form Azure to us, and I did try that, but its still failed. Thanks for the response!

  1. Pingback: Using WatchGuard XTM To Create A Hybrid Cloud With Windows Azure

  2. Pingback: Een VPN verbinding opzetten tussen Watchguard XTM firewall en Azure | Lsf Services

Anything to add? Let me know

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: