Azure VPN Gateway New Capabilities

Q: What Microsoft Azure site-to-site gateway changes did Microsoft announce at TechEd 2014?

A: The initial site-to-site (S2S) gateway functionality that was available for virtual networks in Azure enables a single S2S VPN between a virtual network and an on-premises VPN endpoint. This enabled a single on-premises location to be connected to the Azure virtual network, thus enabling IP routing between on-premises and the virtual network. The data sent over the network is encrypted with IPsec and the maximum data throughput is between 80 and 100Mbps. The ability to have only a single S2S VPN connection was a problem for many organizations that had multiple on-premises data centers and that wanted connectivity from each data center for connectivity and fault-tolerance reasons.

At TechEd 2014 Microsoft announced changes to the VPN gateway capability, which now allows the single VPN gateway endpoint in the Azure virtual network to support up to 10 S2S VPN connections—which enables a virtual network to now be connected to multiple on-premises locations simultaneously. Note that on the Azure virtual network it's still a single VPN gateway interface, which means the combined connections share the 80 to 100Mbps throughput limit—so adding multiple connections wouldn't increase the available bandwidth.

The ability to have multiple connections from the Azure VPN gateway also enables a second capability. If an organization had multiple virtual networks, the only way to connect them was by routing traffic between the virtual networks through an on-premises location. The virtual networks couldn't be directly connected using the Azure network backbone. This is now possible by essentially creating a VPN connection between the VPN gateway on each Azure virtual network in addition to still being able to connect to on-premises VPN endpoints. Again, this is still using the VPN gateway endpoint which means it's still a shared 80 to 100Mbps throughput, but now the connectivity between the virtual networks is using the Microsoft network and not the public Internet or via your own data center. You need to ensure there's no IP address overlap between virtual networks being connected. It's also possible to connect virtual networks that are part of different Azure subscriptions and across different Azure regions (although egress bandwidth charges would then apply when traffic crosses Azure regions, whereas virtual network to virtual network in the same data center would be free of charge).

This following figure shows the connectivity that's now possible. Each green dotted line is a separate VPN connection, so in this case there's a full mesh of connections for maximum resiliency—but this isn't required.

All the configuration must be done by manipulating the virtual network configuration files. Once a multi-VPN connection configuration is enabled, configuration via the Azure portal is no longer possible.

The following Microsoft documentation explains how to actually perform these configurations: