A common concern brought up by clients interested in shifting to the cloud is the requirement of maintaining an on-premise presence. They haven’t finished on-boarding to the cloud and still need to retain a direct connection to their site. There is a way for a company to retain a presence after migrating to the cloud with Azure’s Virtual Network Gateway. The downside to this is it tends to get complicated quite quickly. Azure’s Virtual Networks Gateway provides users with two main options; Policy-based VPN and Route-based VPN.
Policy-based VPN is geared towards the house’s legacy side. If you have a single site, then it is pretty straightforward since a single site can support both solutions seamlessly. However, if you have multiple locations that all require access to the Azure virtual network, then it becomes complicated when using a policy-based VPN solution. A way to overcome this used to be through the use of Microsoft’s traffic selectors, but this is no longer an available option. With that solution no longer available, what else is there? At Agile IT, we’ve come up with a few solutions and scenarios that are highlighted below and in the video.
Policy-Based Virtual Networks
1. Single Connect
This is the traditional scenario where you have multiple corporate office locations, but only one has a data center. Therefore, corporate offices should only one have a direct connection to Azure. The main issue with a single connect scenario is if the single connection goes down, then you are locked out completely and are not able to access anything from the virtual network. Another issue is that it is impossible to share resources amongst the various site locations since they are not connected.
2. Single Connect/ Multi-Site
You might want to keep the single connect VPN but additionally connect the multiple corporate locations with each other. This can be done by connecting the multiple sites to the central location while maintaining a connection to Azure. Though this will solve the issue of resource sharing among site locations, it still has a similar issue to previous policy-based solution. Indeed, any problem with the central location’s connection to Azure will still lead to an outage that will be felt throughout the entire organization. Though this is not the best solution, it sometimes is the only one. Another major issue with this type of policy-based VPN connection is replication. This is because the virtual network cannot detect the site locations that are not connected to it; therefore, if replication is not configured correctly, it will become a problem.
3. Multi-Net/Multi-Site Pairing VPN
This scenario makes it possible for you to set up a site to site policy-based tunnel between multiple virtual networks in Azure. Then, you can further pair virtual networks with each other. This leads to a situation where you have independent connectivity among respective site locations and a corresponding virtual network in Azure, along with connectivity among the different virtual networks within Azure. While this solution is acceptable, it is quite complex. It allows you to work with multiple regions and still maintain the pairing. However, you will need to pair all locations in one availability set first then proceed to set up ‘sister’ networks. You should also note that the traffic being transmitted within the paired virtual networks in Azure is metered. A lot of companies that implement this are those that can support multiple policy-based VPN endpoints and are migrating their data centers to the cloud. Once they have their servers backed up on the cloud, they can then disengage one of the links, move the machines located within one of the virtual networks to another one to reduce complexity. Unfortunately, once a connection has been disengaged, there is rarely much effort to consolidate the virtual networks which we recommend not only to reduce complexity but overall cost as well. This is just one of the things that need to happen during migration. If you are migrating a VN, you need to size it correctly.
Route Based VPN
Programmer brainstorming while working on computer codes in the office.
This is the preferred solution for the modern networking options coming out today. It allows for the latest technology. Further, a single gateway can support up to ten locations with minimal charges with the machines being located within one data center so the traffic is not metered. The main advantage of this solution is in the event one site malfunctions; not affected are the connected sites. Their connection to the virtual network still grants them access. All this done without introducing the complex nature of the policy based multi-net/multi-site pairing VPN.
You can deploy a custom VPN device in Azure to support policy-based VPN for multiple locations. Though it is typically a lot more complex to manage. Indeed, a VN running will increase your VN run costs, storage, CPU cycles, RAM, and include additional licensing. If you have multiple locations, we recommend implementing a route based VPN, unless the only option you have is policy-based VPN, then you can opt for the multi-site/multi-net pairing VPN.
Peering Networks for Windows Virtual Desktop
This is an offering we have in our incubation but is still available in public preview. The features are not available, but that is going to change when Microsoft officially releases it. However, that date has not been announced yet.
There is a detailed blog entry about it already, and once it is released, we will be doing a Tech Talk on it as well.
More on Tech Talks About Multiple Virtual Networks in Azure
Each week we feature a topic presented by an expert on the subject matter followed by a Q&A session where clients can engage with the expert directly. Click on the link to watch and learn more. Contact Agile IT to know more about network security.
Published on: .
Sales@AgileIT.com