Update Nov 2018: Good news, this limitation has now been removed! It’s now possible to deploy the ExpressRoute gateway after the VPN gateway, both via the Azure Portal and PowerShell.

Customer Scenario

I’ve recently been working with a customer that has a specific scenario for their on-premise to Azure connectivity.

Their strategic connectivity approach is ExpressRoute. However, in the short term we’re implementing a tactical site-to-site IPSec VPN connection. Once the ExpressRoute circuit is provisioned the VPN will be used as the failover path.

This is all fairly standard but we hit an issue which initially prevented us from deploying the required Azure network services.

Site-2-Site VPN Overview

Before I dive into the details it’s worth giving a quick recap of the Azure services that are required to enable VPN connectivity between Azure and on-premise -

• Site-2-Site VPN Gateway — the actual Azure component that sends encrypted traffic between an Azure virtual network and your on-premise VPN router
• Public IP address — Azure public IP address associated with the VPN Gateway
• Local Network Gateway — a logical representation of your on-premise VPN router
• VPN Connection — configures the link between the VPN Gateway and Local Network

In addition, ExpressRoute requires the following resources -

• ExpressRoute Network Gateway
• Public IP address — associated with the ER gateway
• ExpressRoute Circuit

The topology for when a S2S VPN and ExpressRoute are deployed together looks like this -

Issue Description

As the customer had a completely greenfield Azure implementation there were a couple of prerequisites I had to configure first -

• A virtual network
• A Gateway Subnet with a /27 network mask

Referencing Microsoft’s documentation here the setup steps for the S2S VPN are -

1. Create the Site-2-Site VPN gateway
2. Create the Local Network Gateway
3. Configure the local VPN device to connect to the new Azure VPN gateway
4. Create a connection to link the Site-2-Site VPN gateway on Azure to the local gateway

This all went fine and the IPSec connection was successfully established.

However, as a test I attempted to create the ExpressRoute gateway which we’d need at a later date. Importantly, this also needs to be deployed into the same Gateway Subnet.

When attempting to create via the portal it wouldn’t allow me to select the same virtual network -

This should work as I’d met the requirements for deploying a VPN and ExpressRoute gateway into the same gateway subnet i.e. -

• minimum /27 mask
• VPN Gateway configured with the VpnGw1 SKU (Basic is not supported for co-existence)

Solution

It turns out that the documentation is not completely correct — the ExpressRoute gateway needs to be created before the VPN gateway.

Digging into the feedback for the documentation it appears we’re not the first to encounter this issue -

Microsoft are aware of this and are looking to remove the limitation of having to create the ExpressRoute gateway first.

In the meantime our deployment approach is -

1. Create Virtual Network and Gateway Subnet
2. Create ExpressRoute gateway
3. Create Site-2-Site VPN gateway
4. Create the Local Network Gateway
5. Configure the local VPN device to connect to the new Azure VPN gateway
6. Create a connection to link the Site-2-Site VPN gateway on Azure to the local gateway
7. Test!

For now, the ExpressRoute gateway will remain unused. Once we’re ready to enable ExpressRoute we’ll have an existing gateway that we’ll link to a new ExpressRoute circuit.

PowerShell Deployment

Included below is the PowerShell code to deploy the resources in correct order.

The creation of the ER and VPN gateways can take 1 hour or so but you can check how the script is progressing by viewing the contents of the resource group in the Azure Portal.