With the holidays finishing up yet another great year for me personally, I decided a couple of weeks ago to completely wipe my MSDN Azure subscription clean of all active services to start the new year with all kinds of new shiny things on the so called V2 platform, Azure Resource Manager.

So without giving this matter any more thought, I started this journey which soon would imply a lot of practical limitations. Microsoft is working hard to bring all functionality of the Service Manager API to Azure Resource Manager based customers of their platform but for now there are a few limitations. A few I stumbled upon:

  • Azure Active Directory can’t be managed from the new portal at this time,
  • Azure Backup can’t backup v2 (Azure Resource Manager) VM’s at this time,
  • Azure Backup isn’t managed in the new portal,
  • Azure Site Recovery can’t replicate on-premises virtual machines towards Azure Resource Manager.

But since I’m a firm believer in the platform, I decided to take these “small”  drawbacks into account and just continue with my innovative (no pun intended ;-)) way of deployment and disconnected my old Site-to-site VPN tunnel, deleted websites, cloud services, backup and recovery vaults and Virtual Machines.

How to start?

People who visit my sessions and workshops know my slogan: “When you start with Azure, have a plan…” so I decided to first create the dependencies for Virtual Machines and other services, starting with a (V2) Storage Account and a (V2) network. Then, to my surprise, I found out that the ease with how you can create a site-to-site VPN in the “old” portal, is no longer present in the new one. At the time of creating my site-to-site vpn connection, there were no clear steps to take in the GUI, nor were there any pre-provisioned config scripts for my Cisco ASA VPN device.

Site to site staat

It had to come down to my basic PowerShell skills to get this job done. For anyone who knows me, you know these skills are really basic, but hey… I managed! And if I can do it, anyone can! So start typing already!

Switch your account!

Because we are not just talking to a Service Manager API, but are talking (in the new portal) to Azure Resource Manager, we’re required to sign in to another API of the platform. So in stead of your accustomed way of doing “Add-AzureAccount” we’ll have to approach this in a Resource Manager way….

First of all, you’ll need the Azure Resource Manager module. You can do this in an Administrative PowerShell session, by running:

Install-Module AzureRM


When this is complete, login to the Azure Resource Manager with…


Notice the small added “RM” letters in the middle of the cmdlet, indicating you’re no longer in Kansas anymore, but you’re talking to the futureproof Azure Resource Manager. When logged in, check to see which subscriptions you have access to, with

Get-AzureRMSubscription | Select SubScriptionName

Note the name of the subscription you want to use for the creation of your network, because the next step is to select that subscription.

Select-AzureRmSubscription -SubscriptionName "<ENTER YOUR SUBSCRIPTIONNAME HERE>"

You can also just use the “SubscriptionID” value here, since the name doesn’t have to be a unique value.

Overzicht subs

In the next few steps we will be creating a lot of objects in Azure, all requiring their own name. Now would be a good time to take some time to think up a naming convention for:

  • Azure Resource Groups
  • Network Security Groups (optional)
  • Network Subnets, except for the “GatewaySubnet”, that one is mandatory
  • the Virtual Network
  • Local Site (On-premises location)
  • Name for Gateway IP Service
  • Name of Azure Gateway Config
  • Name for the Azure Gateway
  • Name for your Local Site
  • Name for your VPN Connection
  • Shared key between your Azure Gateway and your VPN Endpoint on-premises.

Next to these names, we’ll also need a few other building blocks, like:

  • Public IP address of the VPN Gateway Device at your location (on-premises)
  • Public IP address of your Azure Gateway (to be created later-on)

Ok, now we have all of this information, or know how to get our hands on it. It’s time to create the network, which in turn provides us with the possibility to create cross-premises connectivity.

Coding starts here…

First, we’ll need a Resource Group to accommodate the network.

New-AzureRmResourceGroup -Name <NAME OF RESOURCEGROUP> -Location 'West Europe'

Next, we’ll create a virtual network. Verify that the address spaces you specify in this Azure Vnet don’t overlap any of the address spaces that you have on your on-premises network. This could get ugly when those two would ever meet, and that’s the whole purpose of this little exercise.
You’ll need an address space

  • per subnet, and
  • for the entire Virtual Network

Also, this would be a great time to think up a way how you will secure your network (Network Security Groups??) When you have everything thought out, you can base your script on the example below:

$subnet0 = New-AzureRmVirtualNetworkSubnetConfig -Name 'GatewaySubnet' -AddressPrefix
$subnet1 = New-AzureRmVirtualNetworkSubnetConfig -Name '<E.G. DMZ>' -AddressPrefix ''
$subnet2 = New-AzureRmVirtualNetworkSubnetConfig -Name '<E.G. Corpnet>' -AddressPrefix ''
New-AzureRmVirtualNetwork -Name <NAME OF VIRTUAL NETWORK> -ResourceGroupName <NAME OF RESOURCEGROUP> -Location 'West Europe' -AddressPrefix -Subnet $subnet0, $subnet1, $subnet2

You’ll be anxious to see whether all this magic has worked. You can check this with


Next step is to define your on-premises location, where the S2S (Site-to-site) VPN will terminate. You will need a name for that site, so Azure an refer to it. This is known as the “local site”. You’ll need to know all subnets used there, so the S2S gateway can route the appropriate traffic through the tunnel. You can, however, update these prefixes if your on-premises network changes.

In the example below:

  • The -GatewayIPAddress switch is the IP address of your on-premises VPN device.
  • The -AddressPrefix switch hold your on-premises address spaces between quotes, separated by a comma.
New-AzureRmLocalNetworkGateway -Name <NAME OF SITE> -ResourceGroupName <NAME OF RESOURCEGROUP> -Location 'West Europe' -GatewayIpAddress '' -AddressPrefix @('','')

What do we have so far?

Since the start of this blog, we are logged into our Azure Subscription, using Azure Resource Manager. After that we defined our Virtual Network and in the previous step we defined the local networks which roam on-premises. So far these two networks are not yet connected. Even worse, the network can’t even communicate to the outside world! Let’s change that, fast!

To be able to communicate to the outside world our gateway subnet will need a public IP address to use for all outgoing and incoming communications. You can use the PowerShell example below. The Allocation Method for this address must be Dynamic.

$GWPublicIP= New-AzureRmPublicIpAddress -Name <NAME FOR GATEWAY IP SERVICE> -ResourceGroupName <NAME OF RESOURCEGROUP> -Location 'West Europe' -AllocationMethod Dynamic

Next we’ll create the gateway IP addressing configuration. The gateway configuration brings the subnet and the public IP address together which should be used. I used the following to successfully create mine.

$vnet = Get-AzureRmVirtualNetwork -Name <NAME OF VIRTUAL NETWORK> -ResourceGroupName <NAME OF RESOURCEGROUP>
$subnet = Get-AzureRmVirtualNetworkSubnetConfig -Name 'GatewaySubnet' -VirtualNetwork $vnet
$GwIPConfig = New-AzureRmVirtualNetworkGatewayIpConfig -Name <NAME FOR GATEWAY CONFIG> -SubnetId $subnet.Id -PublicIpAddressId $GWPublicIP.Id

Now the gateway subnet is connected to the public IP, next we’ll have to provision a virtual gateway to enable communications to the outside world. This still takes quite some time. In the West Europe region it takes me on average 20 minutes to provision a single gateway. I know that at this time Express Route isn’t supported yet in the V2 network environment. Nevertheless the Gateway type should be “VPN”.

Another thing to choose is whether to use a Route based or a Policy based VPN connection. Route based is something few VPN Gateway providers support until now. It was previously referred to as “Dynamic Routing”. Policy Based VPN is formerly known as “Static Routing”. For more information about VPN gateway types, check this link.

To create a static VPN Gateway, as supported by my Cisco ASA, I used the following command:

New-AzureRmVirtualNetworkGateway -Name <NAME OF GATEWAY> -ResourceGroupName <NAME OF RESOURCEGROUP> -Location 'West Europe' -IpConfigurations $GwIPConfig -GatewayType Vpn -VpnType PolicyBased

At this point, you’ll need the public IP address of the virtual network gateway for configuring your on-premises VPN device. But how can you find that out? The answer, of course, lies in PowerShell.

Get-AzureRmPublicIpAddress -Name <NAME FOR GATEWAY IP SERVICE> -ResourceGroupName <NAME OF RESOURCEGROUP>
Public IP Router
You’ll need this Public IP Address to fill in the config file for your on-premises VPN Gateway. I can show you what I did with the ASA config file below. (click for a bigger picture)
ASA Config
Next, you’ll create the site-to-site VPN connection between your Azure gateway and your VPN device. The shared key must match the value you used inside your VPN device configuration script.
$AzureGateway = Get-AzureRmVirtualNetworkGateway -Name <NAME OF VNETGATEWAY> -ResourceGroupName <NAME OF RESOURCEGROUP>
$LocalGateway = Get-AzureRmLocalNetworkGateway -Name <NAME OF LOCAL SITE> -ResourceGroupName <NAME OF RESOURCEGROUP>
New-AzureRmVirtualNetworkGatewayConnection -Name <NAME OF YOUR CONNECTION E.G. LOCALTOAZURE> -ResourceGroupName <NAME OF RESOURCEGROUP> -Location 'West Europe' -VirtualNetworkGateway1 $AzureGateway -LocalNetworkGateway2 $LocalGateway -ConnectionType IPsec -RoutingWeight 10 -SharedKey '<VALUE OF SHARED KEY>'

After a short while, the connection will be established. You can use the following cmdlet to check if the connection status says “Connected”.

Get-AzureRmVirtualNetworkGatewayConnection -Name <NAME OF YOUR CONNECTION E.G. LOCALTOAZURE> -ResourceGroupName <NAME OF RESOURCEGROUP> | Select ConnectionStatus

VPN Connected

When using…

Get-AzureRmVirtualNetworkGatewayConnection -Name <NAME OF YOUR CONNECTION E.G. LOCALTOAZURE> -ResourceGroupName <NAME OF RESOURCEGROUP> -Debug 

….the connection status shows as Connected and you can see ingress and egress bytes.

Now you can start deploying Virtual Machines connected to only the “local” network in Azure, which can be reached by local resources in your on-premises datacenter through the magic of a VPN Tunnel. Microsoft has come a long way since 2 weeks ago. You can now create a Site-to-site VPN by using the Ibiza (new) portal.

You can also drill down on your Virtual Network and in turn, the VPN connection.

VNET GUIVPN Type and Connection GUIConnected VPN in GUI



Source: VPN Gateway Documentation

If you have any questions or feedback, leave a comment or drop me an email.

Bert Wolters


  • Andy says:

    Hi there
    I was interested in your info that “You can now create a Site-to-site VPN by using the Ibiza (new) portal”

    That is exactly what I am attempting to do to create an Azure VNET-VNET VPN but seem to get stuck after the VPN is successfully created. It has a status of not connected. Hoping you may know the answer

    I did the following in new portal
    Created 2 VNETS each with separate address spaces and
    Created 2 subnets in each VNET within that address space – 1 subnet called “GatewaySubnet” in each as I believe name must be exact for the Gateway
    Created a virtual network gateway in each VNET with a new public IP
    Created a local network gateway in each VNET with the address space and public IP for the other VNET
    Established VNET-VNET VPN successfully

    However VPN shows status of “Not connected” and no data in or data out. Unless it’s a bug I suspect I must have something wrong in config.

    Hoping you can help

  • Andy says:

    I managed to resolve the issue in the end and it was a configuration problem not a bug thankfully. Your image showing the connection in the new portal helped my spot the issue so thanks for that.

    I had established the VPN connection under the VirtualNetworkGateway by mistake when I should have created the connection from the LocalNetworkGateway and repeat to create another connection from the other LocalNetworkGateway.

    After removing the connection from the VirtualNetworkGateway and creating a connection from each LocalNetworkGateway the VMs in each VNET could ping each other and connections on each VNET show as Connected with Data In and Data Out

    Great article so thanks again

  • Bert Wolters says:

    Glad my modest blog could be of some help… Enjoy your connection!

  • Lamont says:

    bookmarked this as I plan on creating a site-site VPN but don’t know anything about Azure yet or cloud solutions.

  • juan says:


    I tried your tutorial and got a connection but no ingress to my VNet and no egress from my OnPrem. I had set up my policies.

    What am I missing?


Leave a Reply