More on the Azure VNET gateway

On Thursday of last week (June 23, 2015) I wrote some feedback on a confusing topic: Azure VNET gateways. The information on the support pages was confusing and I wanted to share some of my experiences.

What I ended up doing recently when I ran through a whole lot of scenarios using both static and dynamic gateways was to eventually give up on the design I had put forward for a project because although in theory it would work, it just didn’t.

Here’s what I wanted to do:

Why it doesn’t work

Microsoft’s distinction between the two gateways is not that one is static vs dynamic, rather a static gateway is a policy based gateway and a dynamic gateway is a route based gateway.

The official line is that Cisco ASA 8.3 firmware and above is a supported endpoint for a site to site VPN. However, this device connecting to Azure can only connect to a static routing or policy based gateway.

What this means is, and I quote (from Microsoft),

“the IPsec policy will need to specify the combinations of prefixes on both customer side and Azure VNet; there’s typically no “routing” or “forwarding” involved in deciding whether a packet should go into an IPsec tunnel or the other (or not). Route-based on the other hand has a single policy of wildcard, or any-to-any. But rely on the routing table in the VPN gateway to direct packets to one of the tunnels or to internal/private network.”

Updates and new firmware

Cisco have since, the Microsoft tested firmware 8.3, introduced numerous updates with the current firmware at 9.3. One of the updates includes IKEv2, which is a requirement for route based VPN’s, as well as introducing route based VPN configurations.

Route based VPNs are able to be configured from Cisco ASA’s to other ASA’s or network devices. The problem though is still that Azure edge network devices or VPN endpoints don’t quick like some of the Cisco configuration.

Real world results

Through testing and configuration of a Cisco ASA, the problem with a dynamic routing VPN appears to be with IKEv2. The IKEv1 handshake completes successfully and moves onto the IKEv2 handshake. The problem from there is that the crypto map that Azure uses ESP-AES256 encryption with CBC. The ASA doesn’t have Cipher Block Chaining or CBC which Azure wants to use in the IKEv2 handshake.

Final words

Unfortunately after a frustrating couple of days, a few weeks ago, or testing and numerous trial and error attempts to get a dynamic gateway VPN connected to a Cisco ASA 5510, all roads lead to “it’s not supported and it just won’t work”.

Its best to keep a hard line on what Microsoft advise is a supported device and configuration. In the end, while in some instances there may be joy, mostly its going to leave me with a more relaxed work day if I simply had stuck to the official Microsoft supported device and configurations.


Questions?

Have a question about this post? Ask away on Twitter or in my AMA repo.