Azure vNet-to-vNet VPN and Why
- Date: May 03, 2016
- Author: Robert Klein
- Comments: no comments
- Tags: Azure, Azure Resource Manager, Azure Service Manager, Cloud, Cloud Services, Cloud Solutions, Cloud Support, Cloud Support Services, ConQuest, ConQuest Technology Services, Microsoft, Microsoft Azure, Robert Klein, Virtual Machines, Virtual Networks, vNet-vNet, VPN
- Categories: Azure, Cloud Solutions
Azure now has two Management “Portals”: Azure Resource Manager (ARM) and Azure Service Manager (ASM) also known as Classic. The Azure Classic (ASM) management way of life has been depreciated over the last year and many of the day to day ASM features are available in the Azure Resource Manager (ARM) “Blades”. Virtual Machines and Virtual Networks that reside in ASM can now be accessed in ARM. One of the biggest moving targets to this multi management environment is the separation of Virtual Networks (vNets). An ARM vNet cannot route traffic to an ASM vNet out of the box even if your ARM and ASM vNets belong to the same Subscription. There are options to route traffic between the two vNets (ARM and ASM) such as a vNet-to-vNet IPsec VPN tunnel. The diagram below illustrates the flow of traffic between vNets once your IPSec VPN tunnel is in place.
We are frequently asked, why would I want my environment to be spread between ARM and ASM? Simply answered; not all the features in Azure are available in both Management Portals. ARM has a large Market Place for supported Virtual Appliances. Along with the ability to deploy Virtual Machines with Premium storage. To date, Azure Site Recovery is not supported in ARM however it is on the Microsoft roadmap for release June 2016. Once supported, your Disaster Recovery scenario will have to be built in ASM. A vNet-to-vNet VPN will be your bridge between the two management portals in order to alleviate possible issues as your Azure Environment grows.
There are additional reasons for a vNet-vNet VPN tunnel besides being able to route traffic between ASM and ARM vNets such as:
- Cross region Geo-Redundancy and Geo Presence
- You can replicate traffic from a Virtual Machine/PaaS service such as SQL between East US and West US vNets without leaving Azure. This provides added security plus better performance.
- With Azure Load Balancer and Microsoft or third-party clustering technology, you can setup a highly available workload with geo-redundancy across multiple Azure regions. An important example is to setup SQL Always On with Availability Groups spreading across multiple Azure regions.
- Cross subscription, inter-organization communication in Azure
- If you have multiple Azure subscriptions, you can securely connect workloads from different subscriptions together between virtual networks.
- For enterprises or service providers, you can enable cross organization communication with secure VPN technology within Azure.
Below are some additional points to be aware of when designing and deploying a vNet-to-vNet VPN
- vNets cannot overlap with local networks that you associate with the VPN Gateway
- Traffic will not leave the Azure backbone
- Secondary/redundant tunnels cannot be created between vNets
- You can deploy up to 10 VPN Tunnels to other vNets or on-premise environments per VPN Gateway
- Load Balancing endpoints or cloud services can span across vNets
- vNets can be part of different Subscriptions or regions which allows a vNet-to-vNet as a simple solution to share workloads and communicate between regions and subscriptions
For additional information about Azure, contact us today. 305-374-8788