Extending your on-prem Private Cloud to Public Cloud is going to be highly anticipated on Year 2015. During such time I came across requirement of interconnecting two Azure subscriptions private networks. I assume by now most of you’ll are aware by leveraging Windows Azure platform you can extend your on-prem network to Azure by using Site to Site (S2S) VPN. If not you can get more information about that from here and if a picture makes it much more clear then it is as follows
Now in my new challenge customer already having two Azure subscriptions. One subscription he is having database virtual machines and another Azure subscription he is having applications VMs. Now how is the earth he face such scenario by not having all the VM’s in same subscription? Well that is along story which will not bring any good for this article
His requirement is to interconnect two Azure subscription via VPN connectivity. Again the picture story is as follows,
Few months back this is not possible but again Microsoft keep on improving their services frequently. Once of that surprise is allowing Azure vNet to vNet VPN connection.
What can I do with VNet to VNet connectivity?
Cross region geo-redundancy and geo-presence
- You can set up your own geo-replication or synchronization with secure connectivity without going over internet-facing endpoints.
- With Azure Load Balancer and Microsoft or third party clustering technology, you can setup highly available workload with geo-redundancy across multiple Azure regions. One important example is to setup SQL Always On with Availability Groups spreading across multiple Azure regions.
Regional multi-tier applications with strong isolation boundary
- Within the same region, you can setup multi-tier applications with multiple virtual networks connected together with strong isolation and secure inter-tier communication.
Cross subscription, inter-organization communication in Azure
- If you have multiple Azure subscriptions, you can now connect workloads from different subscriptions together securely between virtual networks.
- For enterprises or service providers, it is now possible to enable cross organization communication with secure VPN technology within Azure.
So now it’s time to get our hands dirty and find out how to test this right In my step-by-step guide below I’m demonstrating this by using my two Azure subscriptions.
Before that some considerations you need to be aware of,
Requirements and considerations
- VNet to VNet supports connecting Azure Virtual Networks. It does not support connecting virtual machines or cloud services NOT in a virtual network.
- VNet to VNet requires Azure VPN gateways with dynamic routing VPNs – Azure static routing VPNs are not supported. Connecting multiple Azure virtual networks together does NOT require any on premises VPN gateways, unless cross premises connectivity is required.
- Virtual network connectivity can be used simultaneously with multi-site VPNs, with a maximum of 10 VPN tunnels for a virtual network VPN gateway connecting to ether other virtual networks or on premises sites.
- The address spaces of the virtual networks and on premises local network sites MUST NOT overlap. Overlapping address spaces will cause the creation of virtual networks or uploading netcfg configuration files to fail.
- The virtual networks can be in the same or different subscriptions.
- The virtual networks can be in the same or different Azure regions (locations).
- Redundant tunnels between a pair of virtual networks are not supported.
- A cloud service or a load balancing endpoint CANNOT span across virtual networks even though they are connected together.
- All VPN tunnels of the virtual network, including P2S VPNs, share the available bandwidth on the Azure VPN gateway and the same VPN gateway uptime SLA in Azure.
Before starting the steps I like to share with you all the steps high level,
- Plan your IP address ranges
- Create your virtual networks
- Add local networks
- Create the dynamic routing gateways for each VNet.
- Connect the VPN gateways
1. Plan your IP address ranges – Planning is the key on this part. If you ever plan to extend this setup to your on-prem private cloud then plan well ahead about your IP address ranges. Don’t allow them to be duplicate. Same goes among the Azure subscriptions as well. So in our scenario we’ll create two Virtual network between two Azure subscriptions as VNET1 & VNET2.
rom the perspective of VNet1, VNet2 is just another VPN connection that’s defined in the Azure platform. And from VNet2, VNet1 is just another VPN connection. They’ll both be identifying each other as a local network site. Keep in mind that you must make sure that none of your VNet ranges or local network ranges overlap in any way.
Below I’ve shown an example of how to define your VNets. Use the ranges below as a guideline only. Write down the ranges that you’ll be using for your virtual networks. You’ll need this information for later steps.
2. Create your virtual networks – Following the above table we’ll go ahead and create VNET1 = 10.1.0.0/16 and region as SoutEast Asia,
Log into the Azure Management portal and in the lower left-hand corner of the screen click “New” click “Network Services” and then “Virtual Network”. Click “Custom Create” to begin the wizard,
You don’t have to select DNS server or do any configuration on this page. But if you’re planning to have name resolution between your virtual networks then you’ll need to configure your own DNS servers.
As pre planned I’ve change the IP address range for 10.1.0.0/16. Go ahead and complete the wizard. Now carry out the same task on your other subscription. Only changes are VNET1 will be VNET2 and IP address range is 10.2.0.0/16.
3. Add local networks – Now go back to the VNET1 in Azure portal. Click “Local Networks” You’ll find there is not local network exists. Go ahead and create one with the range of 10.2.0.0/16. Carry out same on the other Azure subscription (VNET2) with the value of 10.1.0.0/16
The VPN device IP address you provide in the above is not matter right now. Once we obtain the correct VPN IP address we’ll be entering that.
Note: Keep on eye about the naming convention and the IP address range I provided. Follow the same steps on the other Azure subscription as well. (Vales will be different)
Now on the first Azure subscription click VNET1. Click “Configure” Click “Connect to the local network” under Site-to-Site-connectivity section.
Click “Save” on the bottom of the screen.
4. Create the dynamic routing gateways for each VNet – Now we have configured the VNET now it’s time to configure the VNET Gateways,
go back to the dashboard of the VNET1. Bottom of the screen click “ Create Gateway” and select “Dynamic Routing”
Confirm the action. This will take around 10 –15 minutes time to complete. Carry out the same action on the other Azure subscription as well.
When the gateway status changes to Connecting, the IP address for each Gateway will be visible in the Dashboard. Write down the IP address that corresponds to each VNet, taking care not to mix them up. These are the IP addresses that will be used when you edit your placeholder IP addresses for the VPN Device in Local Networks.
5. Connect the VPN gateways – When Gateway creation completed we can go ahead and setup IPsec/IKE pre-shared key (same key) in both side. This action has to be carried out in the PowerShell.
On the VNET1 side type the following PS command,
PS C:\> Set-AzureVNetGatewayKey -VNetName VNet1 -LocalNetworkSiteName VNet2 -SharedKey A1b2C3D4E6
on VNET2 side type the following PS command,
PS C:\> Set-AzureVNetGatewayKey -VNetName VNet2 -LocalNetworkSiteName VNet1 -SharedKey A1b2C3D4E6
Now give little bit of time and refresh the Azure portal page. You’ll find the VPN connection established.
Once that completed you can create two VM’s on each Azure subscription and try pining to each other. If your get the response you’ll know the connection has been established