Like many other people I have been getting involved with Amazon Web Services EC2, but more recently with Windows Azure since their recent release which includes the new Virtual Machines and Virtual Network functionality in response to the requests from many for the IaaS like features AWS and Rackspace offer to name a couple.
I am mainly a WatchGuard appliance person, although we all know that once you’ve mastered an enterprise firewall, you can usually turn your hand easily to other devices such as Cisco / Juniper etc. It was over a year ago when I was getting our Virtual Private Cloud (VPC) provisioned on Amazon Web Services mainly for test and development purposes. I got that successfully connected and it still run today, although not directly connected to a WatchGuard appliance. After a lot of trial and error it was confirmed by WatchGuard forums and WatchGuard support themselves that due to AWS requiring the use of BGP over an IPSec tunnel it couldn’t be achieved with a WatchGuard appliance. That is still a known issue with WatchGuard, at the time of writing this the latest 11.6 release notes detail this limitation. To get around that I went out and bought a supported AWS VPN appliance, that was a Cisco 881 Integrated Services Router which I added to an interface of my WatchGuard appliance. The Cisco router has the VPN connection into AWS, there are then some routes and NAT rules set up to allow the traffic to flow across the main WatchGuard appliance seamlessly. Details on that setup are available if anybody is interested.
So back to Windows Azure, WatchGuard is again not on the supported appliance list and I think it is because it has similar issues although it can work and remain stable (to an extent) as I have finally proved. These settings should get you working, although I would say that you can’t rely on this for consistent uptime between your local LAN and the Azure Virtual Network so I would strongly advise against it for use with any production systems. Simply because it can remain stable for many minutes (sometimes hours) but then it can continuously drop and reconnect within minutes. It’s a proof of concept at the moment and it could mean that with the right feedback supplied to WatchGuard Support, it might be that WatchGuard appliances start getting added to the these big IaaS providers compatibility lists in the future.
At the Windows Azure side I have followed the Microsoft documentation using their lab subnets they detail, so my screenshots of my WatchGuard configuration correlate to those. There is a slight difference with the YourCorpHQ subnet which in my case is 192.168.1.0/24.
At present I am using a WatchGuard XTM 510 running version 11.4.2.B322805. Some of the reliability issues may improve with the latest 11.6 version, although I have been reluctant to upgrade to the latest WatchGuard version of software due to the 11.5 issue back in November 2011 which caused me a lot of pain where a configuration change wouldn’t take effect unless the device was rebooted. Whilst I know that has now been corrected, I have learnt that I need to reserve more time out of hours to fully test the latest WatchGuard software versions before going live with them.
Here are my settings which are proving reasonably stable, although it changes without notice and you can get the VPN tunnel consistently dropping and recreating.
Gateway Configuration
A note on the Remote Gateway ID value – I had read that the .5 IP address was traditionally the IP used in the handshake process although this wasn’t set in stone and part of the reason why the WatchGuard appliances are not supported, Cisco and Juniper take care of this automatically. For a time I had a connection (without any routing working) with the .5 IP address, but recently the .4 IP address (found in the IKE debug logs) has proved much more reliable. I am still on the hunt for the exact detail behind this ID and IP address relationship and why those addresses are used often, if anybody get enlighten me then please me know. It is likely it will change again and so my connection will drop and I will need to manually change it to whatever Windows Azure is asking for.
Any other encryption settings in Phase 1 have failed for me, so it has always had to be SHA1-AES (128-bit).
Tunnel Configuration
Phase 2 is where I have seen my issues occurring, even when the VPN remains stable (with the odd 1 or 2 ping timeouts whilst the tunnel rebuilds), I get the PAYLOAD_MALFORMED message which causes the tunnel to rebuild itself. Prior to that as an example I have had a stable connection for over 2.5 hours with 2 rekeys in the process due to the force key expiration of 1 hour.
It’s not a full proof solution but at least proves that it can work to an extent. As I’ve said earlier, I am hoping WatchGuard catch up with these IaaS virtual private networking methods so we can use these devices with what is becoming an everyday resource.
Give me a shout if you want to discuss or trial some different settings. My virtual network is a play area and just a play with the technology, apart from the odd test / development server which may require domain connectivity then I am struggling to find a cast iron use case for having a tethered virtual network to your corporate LAN. I will be experimenting with Active Directory Federation Services (ADFS) up to Windows Azure in the future which would solve the cloud hosted servers being members of the corporate domain. I currently have ADFS running with Office 365 as we currently use Lync with Office365 with our corporate credentials used as the login, there is also a plan to migrate our on premise Exchange 2010 server to Office365 in the future.
Gap Fusion Blog 