{"id":4770,"date":"2016-05-20T13:31:59","date_gmt":"2016-05-20T13:31:59","guid":{"rendered":"http:\/\/blog.cloudthat.com\/?p=4770"},"modified":"2024-06-25T11:12:37","modified_gmt":"2024-06-25T11:12:37","slug":"multi-site-azure","status":"publish","type":"blog","link":"https:\/\/www.cloudthat.com\/resources\/blog\/establishing-multi-site-connectivity-with-azure-virtual-networks","title":{"rendered":"Establishing multi-site connectivity with Azure Virtual Networks"},"content":{"rendered":"

\"Multi-Site<\/a>Recently, I designed an architecture for client application where we used Azure\u2019s VNet-to-VNet connectivity for geo-redundancy. The requirement was such that they wanted to continue with their on-premises infrastructure, so we thought of it as DR (disaster recovery) solution. In the design we proposed Multi-Site connectivity as well, with VNet-to-VNet connectivity in Azure, you can connect two different VNets with each other. You can use this connectivity to connect two VNets across different regions or across different subscriptions.<\/p>\n

The question that comes to mind is \u201cWhy connect VNets?\u201d<\/strong><\/span><\/p>\n

So, connecting VNet is especially useful when you want to setup multi-tier applications with multiple virtual networks connected together with a strong isolation boundary and secure inter-tier communication within same region. This can also help you set up geo-replication or synchronization over a secure connection without going out over the internet. Connecting one Virtual Network with another is almost similar to connecting an on-premises network to Azure\u2019s Virtual Network as both the connection uses a VPN gateway to provide a secure IPSec tunnel for data transfer.<\/p>\n

Are you new to VNet-to-VNet connectivity?<\/span><\/strong>
\nIf yes, click here<\/a> to get more insight on VNet-to-VNet connectivity in Azure.<\/p>\n

Now, where can we include VNet connectivity?<\/span><\/strong>
\nLet\u2019s assume you want to deploy two Cloud Services in different regions across different Azure Data centres. As the service is geographically dispersed, I would suggest to use Traffic Manager with \u201cPerformance\u201d load-balancing method to make sure that clients connect to specific Cloud Service that performs best for their locations. Also, best practices includes database to be present in the same region as the cloud services to avoid latency and performance issues.<\/p>\n

One day, my \u201cnon-technical\u201d friend called up with a very strange scenario, totally different from the above one. So, the situation goes like this: He was having two frontend servers in two different regions both talking to a single database server (SQL Server on VM) hosted in the third region. He was stuck in establishing multi-site connectivity (multi-site VPN) between those three regions.
\nNow, let\u2019s work around with some basic pieces of information that are required to understand the scenario:
\nLet\u2019s assume the three regions are: Southeast Asia, East Asia and Central US<\/span><\/em>. Mapping regions with my friend\u2019s scenario; two frontend servers in Southeast Asia and East Asia and database server in Central US (which practically will give you latency and database performance issues).
\nNomenclature and address spaces of VNets and Local Networks chosen by me are as follows:<\/p>\n\n\n\n\n\n\n
VNet Name Address<\/strong><\/td>\nAddress Space<\/strong><\/td>\nLocal Network Name<\/strong><\/td>\nAddress Space<\/strong><\/td>\n<\/tr>\n
Default_SEAsia_VNet<\/td>\n10.1.0.0\/16<\/td>\nSEAsia_Local<\/td>\n10.1.0.0\/16<\/td>\n<\/tr>\n
Default_EAsia_VNet<\/td>\n10.2.0.0\/16<\/td>\nEAsia_Local<\/td>\n10.2.0.0\/16<\/td>\n<\/tr>\n
Default_CentralUS_VNet<\/td>\n10.3.0.0\/16<\/td>\nCentralUS_Local<\/td>\n10.3.0.0\/16<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

 <\/p>\n

The database server has to be connected with both the frontend servers in Southeast Asia and East Asia. Avoid creating unnecessary number of gateways as it will create a hole in your pocket.
\nLet\u2019s start using Multi-site VPN:<\/p>\n

    \n
  1. Establish site-to-site connectivity between Southeast Asia and Central US i.e. connect CentralUS_Local<\/strong> from Default_SEAsia_VNet<\/strong>. The link to create site-to-site connectivity is mentioned above.<\/li>\n
  2. Establish site-to-site connectivity between East Asia and Central US i.e. connect CentralUS_Local<\/strong> from Default_EAsia_VNet<\/strong>.<\/li>\n
  3. Make sure to create Dynamic Routing gateways.<\/li>\n
  4. Now connect to SEAsia_Local<\/strong> from Default_CentralUS_VNet<\/strong>. We have to connect EAsia_Local also from Default_CentralUS_VNet. This is where the actual catch is. We cannot directly do this from management portal. So just export your Network Configuration file and make necessary changes.<\/li>\n<\/ol>\n

    Open your \u201cNetwork Configuration.xml<\/em>\u201d file and search for <ConnectionsToLocalNetwork><\/em> inside <VirtualNetworkSites><\/em>.
    \nFor Default_CentralUS_VNet by default you will only see a connection with SEAsia_Local inside.<\/p>\n

    \"configuration<\/p>\n

    As we need connection to EAsia_Local, we will add that part inside. After adding, it should look like this:<\/p>\n

    \"two<\/a><\/p>\n

    Save the file and import the configuration file from management portal.
    \nAfter import is successful, we are required to run the series of PowerShell cmdlets to set up shared key for VPN tunnel. Now, import your subscription into PowerShell by either using \u201cAdd-AzureAccount<\/em>\u201d or \u201cImport-PublishSetiingsFile<\/em>\u201d cmdlet.
    \nExecute the following cmdlets:<\/p>\n