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):
- 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)
- 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!
- A Windows Azure subscription (can be a trial)
- A WatchGuard XTM 510 Firewall (will probably work with all XTM series, not sure about the hypervisor based products)
- Know what your internal IP address range(s) is that you want to connect to Azure
- 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)
- Know what IP subnet you want in Azure
- Some time and patience(don’t rush it or you’ll have start all over again)
Log in to Azure (https://manage.windowsazure.com)
Go to the bottom left hand corner and select New. Navigate to Networks, Virtual Network, Custom Create
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.
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
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:
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).
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)
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.
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.
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.
Open Policy Manager for your WatchGuard firewall and go to VPN -> Branch Office Gateways. You’ll be presented with the New Gateway screen
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.
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.
Click OK to close the Branch Office Gateway, click Close on the Gateway list. Go to VPN -> Branch Office Tunnels. Click Add.
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 192.168.5.0/24 and the Remote range is 10.254.254.0/24. Leave everything else alone (you can amend later if you want – one thing at a time)
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.
Make sure the Multicast settings are off.
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
Click OK, Click Close and save you policy to your Firebox.
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:
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!
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!