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.
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 Install-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.
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 172.16.254.0/28 $subnet1 = New-AzureRmVirtualNetworkSubnetConfig -Name '<E.G. DMZ>' -AddressPrefix '172.16.1.0/24' $subnet2 = New-AzureRmVirtualNetworkSubnetConfig -Name '<E.G. Corpnet>' -AddressPrefix '172.16.2.0/24' New-AzureRmVirtualNetwork -Name <NAME OF VIRTUAL NETWORK> -ResourceGroupName <NAME OF RESOURCEGROUP> -Location 'West Europe' -AddressPrefix 172.16.0.0/16 -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 '184.108.40.206' -AddressPrefix @('192.168.1.0/24','10.0.0.0/24')
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>
$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
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.
Source: VPN Gateway Documentation
If you have any questions or feedback, leave a comment or drop me an email.