In today’s increasingly connected world, businesses of all sizes rely on cloud computing to store, process, and analyze their data. As a result, ensuring seamless connectivity between different regions and subscriptions within the cloud infrastructure is critical. One of the most effective ways to achieve this is by configuring Virtual Network Gateway (VNG) connections. However, setting up VNG connections across different regions and subscriptions can be a complex and daunting task for even the most experienced IT professionals. In the blog post “Configuring Virtual Network Gateway Connections Across Regions and Subscriptions“, we’ll learn to configure VNG connections in Azure to enhance network performance and strengthen security.

Table of Content:

1. Use Cases of Connecting VNet Gateways Across Different Regions/Subscriptions
2. Benefits of using VNet Gateway
3. Ways to Connect Virtual Networks
   • Types 1: VNet-to-VNet Connection
   • Types 2: Site-to-Site Connection
   • Type 3: VNet Peering
4. Differences between VNet-to-VNet vs Site-to-site vs VNet peering
5. Benefits of Using VNet-to-VNet Connections for Cross-Region Networking in Azure
   • Regional multi-tier applications with isolation or administrative boundaries
   • Cross-region geo-redundancy and geo-presence
6. Best Practice 1: Choose the right connection type for your scenario and workload.
7. Best Practice 2: Use Remote Peering Gateway
8. Best Practice 3: Use Hub and Spoke Network Topology
9. Best Practice 4: Deploy Zone-Redundant Gateway in Availability Zones
10. Best Practice 5: Monitor VPN Gateway Performance and Health
11. Best Practice 6: Secure your Virtual Networks and Subnets
12. Best Practice 7: Plan your IP address
13. Conclusion

Use Cases of Connecting VNet Gateways Across Different Regions/Subscriptions

Virtual Network Gateway provides a secure way to connect different virtual networks together over the Internet. Please note that when you establish connections between Virtual Networks (VNets) that belong to different subscriptions, it’s not mandatory for the subscriptions to be linked to the same Active Directory (AD) tenant.

Connecting Virtual Network Gateways (VNG) across different Azure regions/subscriptions offers numerous use cases, especially for businesses that require seamless connectivity across their cloud infrastructure. Here are some of the primary use cases for connecting VNG across different regions/subscriptions:

1. Disaster Recovery: By setting up VNG connections across different regions, businesses can ensure that their critical workloads are protected in case of a disaster. In the event of a site failure, VNG connections can redirect traffic to a secondary region, allowing for uninterrupted access to resources.
2. Improved Network Performance: Connecting VNG across different regions/subscriptions can significantly improve network performance by reducing latency and increasing bandwidth. This can lead to faster application response times and better user experiences.
3. Global Load Balancing: VNG connections can be used to distribute traffic across multiple regions, allowing businesses to optimize their network resources and reduce downtime. This can be particularly beneficial for businesses with a global presence that require fast and reliable access to their applications and data.
4. Compliance and Security: VNG connections provide a secure way to connect virtual networks, ensuring that data remains private and protected. By connecting VNG across different regions/subscriptions, businesses can maintain compliance with regulatory requirements and strengthen their overall security posture.

Benefits of using VNet Gateway

Virtual Network Gateway (VNG) offers a range of benefits for businesses that require secure and reliable connectivity across their cloud infrastructure. Here are some of the key benefits of VNG:

1. Secure Connectivity: VNG provides a secure way to connect virtual networks together over the Internet, ensuring that data remains private and protected.
2. Flexible Connectivity Options: VNG supports a range of connectivity options, including Point-to-Site (P2S), Site-to-Site (S2S), and ExpressRoute connections, enabling businesses to choose the connectivity option that best suits their needs.
3. High Availability: VNG is designed to provide high availability, ensuring that critical workloads remain accessible even in the event of a site failure.
4. Improved Network Performance: By connecting virtual networks through VNG, businesses can significantly improve network performance by reducing latency and increasing bandwidth.
5. Cost-Effective: VNG is a cost-effective way to connect virtual networks together, as businesses can choose the connectivity option that best fits their budget without spending on hardware costs.
6. Global Reach: VNG supports connections across different regions/subscriptions, enabling businesses to connect their virtual networks globally and improve their global reach.

Ways to Connect Virtual Networks

A virtual network gateway supports various types of connections, depending on the type of gateway being used. There are two types of gateways: VPN gateway and ExpressRoute gateway. Each connection type can be used with a VPN gateway or ExpressRoute gateway, depending on your specific needs.

Here are the different ways that you can connect to a Virtual Network:

1. VNet-to-VNet Connection
2. Site-to-Site Connection
3. VNet Peering

Types 1: VNet-to-VNet Connection

VNet-to-VNet connection is a type of virtual network (VNet) connection in Microsoft Azure that allows you to connect two VNets in the same region or different regions using a secure and encrypted connection over the internet. This connection enables you to create a single virtual network that spans multiple Azure regions or subscriptions.

VNet-to-VNet connections can be used to build:

• Global network infrastructure, connect resources in different Azure regions
• Connect multiple Azure virtual networks to create a hub-and-spoke topology, where a central hub virtual network is connected to multiple spoke virtual networks, and enables secure communication between all connected virtual networks
• Disaster recovery scenario
• Global load balancing, and multi-site connectivity.
• This type of connection also provides a high-availability and disaster recovery solution by replicating data between VNets.

To create a VNet-to-VNet connection in Azure, you must create a virtual network gateway in each VNet, configure the connection settings, and then establish the connection. The connection can be established using a Site-to-Site VPN or Azure ExpressRoute circuit. The VNet-to-VNet connection is similar to a Site-to-Site IPsec connection to an on-premises location, and both connection types utilize a VPN gateway to establish a secure tunnel with IPsec/IKE.

With VNet-to-VNet connections, the local network gateway address space is automatically created and updated, making it faster and simpler to set up than Site-to-Site connections. However, the local network gateway is not visible in this configuration. If you require additional address spaces or plan to add connections later, you should use the Site-to-Site connection. Additionally, the VNet-to-VNet connection does not include Point-to-Site client pool address space, so a Site-to-Site connection is necessary for transitive routing or VNet peering.

VNet-to-VNet connections are a powerful tool for building complex network topologies in Azure. They can be used to connect VNets across different regions, subscriptions, and even different Azure AD tenants. However, it’s important to carefully plan and design your network architecture to ensure optimal performance and security.

Types 2: Site-to-Site Connection

Site-to-Site (S2S) connection is a type of Virtual Network Gateway (VNG) connection that allows you to securely connect your on-premises network to an Azure virtual network. With S2S connections, you can also extend the on-premises network to the cloud and enable secure communication between the two environments this way you can create a hybrid environment where resources are hosted both on-premises and in the cloud. This connection is commonly used for disaster recovery scenarios, where a secondary site is established in Azure to ensure business continuity in the event of a disaster.

To establish S2S connections, you need to create a Virtual Network Gateway in Azure and then configure a compatible VPN device on the on-premises network to establish a secure VPN tunnel between the two networks. The VPN device can be a physical device or a software-based VPN appliance, such as Windows Server or a third-party VPN appliance. The site-to-Site connection provides flexibility to address and control the local network gateway.

Encryption and Authentication protocols, such as IPsec, SSL, and IKEv2 are supported by S2S connections.IPsec uses encryption and authentication to protect the data that travels across a VPN tunnel. Tunnel mode encrypts and encapsulates the entire IP packet, while transport mode only encrypts the payload of the IP packet. S2S also supports a variety of routing options, including static routing and dynamic routing protocols such as BGP (Border Gateway Protocol). 

If you want to explore connectivity options from On-premise to Azure please read my other post. On-Premise to Azure Connectivity Options

Connecting VNets using a Site-to-Site connection is preferred when dealing with complex network configurations. With this connection type, local network gateways are manually created and configured for each VNet. The local network gateway for each VNet treats the other VNet as a local site, allowing you to specify additional address spaces for routing traffic. If there are changes to the address space for a VNet, you must manually update the corresponding local network gateway.

Type 3: VNet Peering

Virtual Network peering allows you to connect two or more virtual networks seamlessly. The virtual networks behave as one network for connectivity, and the traffic between virtual machines in the peered virtual networks utilizes the Microsoft backbone infrastructure. The routing of traffic between virtual machines in the peered networks occurs solely through Microsoft’s private network.

A virtual network can have only one gateway either a local or remote gateway in the peered virtual network as shown in the above diagram.

It is also possible to set up the gateway in the peered virtual network as a transit point for an on-premises network. However, if you choose to do so, the virtual network that is using a remote gateway will not be able to have its own gateway because you can have only one gateway.

Differences between VNet-to-VNet vs Site-to-site vs VNet peering

In the above section, you have learned different ways to connect virtual networks. Now, we can observe the distinction between the connections:

Benefits of Using VNet-to-VNet Connections for Cross-Region Networking

VNet-to-VNet connectivity helps cross-region networking. We will understand it with two use cases:

1. Regional multi-tier applications with isolation or administrative boundaries

This refers to a network architecture in Azure that consists of multiple VNets, each containing a different tier of the application. The VNets are deployed in different Azure regions, providing regional redundancy and reducing the impact of regional outages. The architecture also includes mechanisms to ensure isolation and administrative boundaries between the different tiers.

The below diagram depicts a regional multi-tier application with isolation or administrative boundaries in Azure:

This architecture divides the application into three tiers, each deployed in a separate VNet in different Azure regions. The different tiers communicate with each other using VNet-to-VNet connections.

The architecture includes mechanisms to ensure isolation and administrative boundaries between the different tiers. For example:

• Each tier is deployed in a separate VNet, which provides a natural isolation boundary.
• Access control lists (ACLs) can restrict access to the VNets.
• Network security groups (NSGs) can be used to control traffic between the VNets.
• Role-based access control (RBAC) can be used to ensure that only authorized personnel have access to the VNets.

Here is another example of this implementation:

In this diagram, we have:

1. VNet1 (West US Region) in Subscription 1 connected to VNet 1 (East US Region) in Subscription 1 via VNet-2-VNet connection.
2. VNet 2(Japan East Region) in Subscription 2 is connected to VNet 1 (East US Region) in Subscription 1 via a VNet-2-VNet connection.
3. VNet 1 (East US Region) in Subscription 1 connected to Site 2 and Site 2 On-Premise Data Centers via S2s Connectivity.

Because of isolation or administrative requirements, these three virtual networks are connected together using a VNet-to-VNet connection. This enables secure communication between these virtual networks and furthermore, for compliance requirements, they are connected to On-premise Data centers.

Regional multi-tier applications with isolation or administrative boundaries provide a scalable and highly available architecture that is well-suited to applications that require regional redundancy and isolation between tiers.

2. Cross-region geo-redundancy and geo-presence

When you create a VNet-to-VNet connection, you establish a secure connection between two virtual networks in Azure, even if they are in different regions. This allows you to create a network topology that supports cross-region geo-redundancy and geo-presence, which provides several benefits.

Firstly, you can set up your own geo-replication or synchronization with secure connectivity without going over internet-facing endpoints. This is particularly useful if you need to transfer sensitive or confidential data between virtual networks in different regions.

Secondly, with Azure Traffic Manager and Azure Load Balancer, you can set up highly available workloads with geo-redundancy across multiple Azure regions. For example, you can set up SQL Server Always On availability groups across multiple Azure regions, which can provide higher availability and lower latency for your applications.

Overall, a VNet-to-VNet connection enables you to create a scalable and highly available network architecture that spans multiple regions, while maintaining the security and reliability of your network connections. This is particularly useful for applications that require cross-region redundancy and presence, or for organizations that need to transfer sensitive data between regions.

In this example, there are two virtual networks in different Azure regions (VNet 1 in Azure Region 1 and VNet 2 in Azure Region 2) that are connected using a VNet-to-VNet connection. Each virtual network has its own VPN gateway (VPN Gateway 1 in Azure Region 1 and VPN Gateway 2 in Azure Region 2), which establishes a secure tunnel between the two virtual networks.

With this setup, you can replicate data between the two virtual networks, providing cross-region geo-redundancy and geo-presence. Additionally, you can use Azure Traffic Manager and Azure Load Balancer to set up highly available workloads with geo-redundancy across multiple Azure regions

Best Practices for Creating Virtual Network Gateway Connection

When creating a Virtual Network Gateway connection in Azure, small issues can cause problems while connecting virtual networks between different regions such as Mismatched Address Spaces, Incorrect Permissions, Unsupported Resources, Missing Routes, Network Security Rules, etc. To overcome these issues you need to follow some tips and best practices that can help you to ensure its reliability and security.

Hence, below are some of the key best practices to keep in mind when creating Virtual Network Gateway connections between virtual networks especially when they are in different regions and subscriptions.

Best Practice 1: Choose the right connection type for your scenario and workload.

You can use a VNet-to-VNet connection or a Site-to-Site connection to connect virtual networks across Azure by using a VPN gateway. Depending on your scenario and workload, you may prefer one connection type over another. For example, if you need a simple and secure connection between two VNets, you may choose the VNet-to-VNet connection type.

If you need a more complex and flexible connection between multiple VNets, you may choose the Site-to-Site connection type. If you need a high-performance and low-cost connection between two VNets, you may choose the VNet peering connection type. You can use the comparison table described above to take the correct decision.

Best Practice 2: Use Remote Peering Gateway

Remote Peering Gateway (RPG) is a feature in Azure that allows you to peer with a virtual network in another Azure region through the Azure backbone network, without having to set up a VNet-to-VNet VPN connection. This can provide a number of benefits, such as improved performance and reduced latency for cross-region traffic, increased resilience, and simpler network architecture.

Here are some ways in which using a Remote Peering Gateway is a best practice in Azure:

1. Improved Performance: By using an RPG, you can avoid routing traffic between virtual networks over the public internet. This can result in lower latency, higher bandwidth, and more consistent network performance, which can be particularly important for applications that require real-time communication or high throughput.
2. Increased Resilience: An RPG can provide an additional layer of redundancy for your network architecture. By establishing peering connections with multiple virtual networks in different regions, you can ensure that your traffic can be rerouted in case of a failure in one region, providing improved availability for your applications.
3. Simplified Network Architecture: Setting up VPN connections between multiple virtual networks can be complex and time-consuming, especially if you have multiple regions or large-scale deployments. By using an RPG, you can simplify your network architecture, reduce the number of VPN connections required, and make it easier to manage and scale your network as your requirements change.
4. Reduced Costs: By using an RPG, you can avoid the need to set up and maintain multiple VPN connections, which can be expensive in terms of both time and resources. Additionally, you can use the Azure backbone network to route traffic between virtual networks, which can be more cost-effective than routing traffic over the public internet.

So, using a Remote Peering Gateway can be a best practice in Azure, providing a number of benefits in terms of performance, resilience, simplicity, and cost-effectiveness.

Best Practice 3: Use Hub and Spoke Network Topology

Hub and spoke network topology is a networking model for efficiently managing common communication or security requirements between different regions. It also helps avoid Azure subscription limitations. In this model, a hub is a central network zone that controls and inspects ingress or egress traffic between zones: internet, on-premises, and spokes. A spoke is a network zone that hosts individual workloads separately. The hub and spoke topology gives your IT department an effective way to enforce security policies in a central location. 

It reduces the potential for misconfiguration and exposure. The hub often contains the common service components that the spokes consume, such as DNS servers, firewalls, VPN gateways, etc

Hup and Spoke topology creates simplified network design, improved security, and traffic control, easier management and troubleshooting, better scalability, and reduced costs (since fewer high-end devices are needed at the edge). Hub and spoke topology can also enable more efficient use of WAN links and provide a natural separation of network zones or business units.

Best Practice 4: Deploy Zone-Redundant Gateway in Availability Zones

Azure Availability zones are physically separate locations within each supporting Azure region that are tolerant to local failures. They help your data stay synchronized and accessible when things go wrong. Each zone is composed of one or more data centers equipped with independent power, cooling, and networking infrastructure. Availability zones are designed so that if one zone is affected, regional services, capacity, and high availability are supported by the remaining two zones.

Benefits:

1. Increasing application resiliency and availability supported by 99.99% uptime SLA for virtual machines.
2. Enabling advanced scalability for applications that support multisite active-active scaling.
3. Meeting compliance and regulatory needs for critical applications.
4. Improving recovery time objectives (RTOs) and recovery point objectives (RPOs)

By using zone-redundant virtual network gateways in Azure availability zones, you can ensure that your virtual network gateways are automatically deployed across multiple availability zones. This provides increased resiliency and availability for your mission-critical and scalable services on Azure. When you deploy gateways in availability zones, they are separated both physically and logically within a region, which helps to protect your network connectivity to Azure from any zone-level failures. using zone-redundant virtual network gateways brings greater resiliency, scalability, and availability to your virtual network infrastructure.

Best Practice 5: Monitor VPN Gateway Performance and Health

Monitoring your VPN gateway is important to ensure its performance and reliability. Azure offers a few tools to help with this: Azure Monitor and Network Watcher.

Azure Monitor allows you to monitor various metrics related to your VPN gateway’s performance, such as availability and bandwidth. You can also set up alerts to notify you of any issues that may arise, such as dropped connections or low bandwidth.

In addition to Azure Monitor, you can also use Network Watcher to troubleshoot any connectivity issues between your virtual network gateway and your local network gateway. This can be particularly helpful when you’re trying to diagnose issues with your VPN connection or when you’re experiencing connectivity problems.

Best Practice 6: Secure your Virtual Networks and Subnets

Securing your virtual networks and subnets is important for creating virtual network gateway connections between different regions because it can help you prevent unauthorized access, data breaches, and network attacks. Some of the security measures you can take are:

• Ensure that your virtual network address space does not overlap with your organization’s other network ranges. 
• Use Network Security Groups (NSGs) to control the traffic flow to and from subnets and to and from VMs. NSGs can help you filter traffic based on source and destination IP addresses, ports, and protocols.
• Secure protocols such as IPsec or SSL/TLS encrypt the traffic between your virtual network gateways and other networks or subnets. 
• Use public IP addresses with Standard SKU for your gateways, which provide built-in security features such as DDoS protection and availability zone support.
• Use authentication and authorization mechanisms such as certificates, tokens, or passwords to verify the identity of the users or devices that access your virtual network gateways. 
• Use role-based access control (RBAC) to grant or deny permissions to users or groups based on their roles and responsibilities.

Secure your virtual networks and subnets by using network security groups (NSGs), application security groups (ASGs), Azure Firewall, Web Application Firewall, and other security features.

Best Practice 7: Plan your IP address

Planning your IP address is important because it helps you to avoid overlapping or conflicting with your on-premises or other virtual networks. Careful planning of your IP address range is an important step in setting up a secure and reliable virtual network in Azure.

Conclusion

Connecting virtual networks across different regions and subscriptions is crucial for organizations looking to extend their on-premises infrastructure to the cloud, build multi-tier applications with isolation, or achieve cross-region geo-redundancy and geo-presence. Azure provides several types of virtual network connections, including VNet-to-VNet, site-to-site, and VNet peering, which offer varying degrees of complexity, scalability, and customization. While each type has its own advantages, VNet-to-VNet connections are best suited for cross-region networking in Azure, given their ability to support regional multi-tier applications with isolation or administrative boundaries, and cross-region geo-redundancy and geo-presence. However, to ensure the best performance, scalability, and security of virtual network connections, organizations must follow certain best practices, such as choosing the right connection type, using a remote peering gateway, deploying hub and spoke network topology, deploying the zone-redundant gateway in availability zones, monitoring VPN gateway performance and health, and planning IP addresses. By following these best practices, organizations can achieve seamless and secure connectivity between virtual networks, while minimizing downtime, latency, and cost.