Jaa

Configure a VNet-to-VNet connection (classic)

  • Artikkeli

This article helps you create a VPN gateway connection between virtual networks. The virtual networks can be in the same or different regions, and from the same or different subscriptions.

The steps in this article apply to the classic (legacy) deployment model and don't apply to the current deployment model, Resource Manager. You can no longer create a gateway using the classic deployment model. See the Resource Manager version of this article instead.

Important

You can no longer create new virtual network gateways for classic deployment model (service management) virtual networks. New virtual network gateways can be created only for Resource Manager virtual networks.

Diagram showing classic VNet-to-VNet architecture.

Note

This article is written for the classic (legacy) deployment model. We recommend that you use the latest Azure deployment model instead. The Resource Manager deployment model is the latest deployment model and offers more options and feature compatibility than the classic deployment model. To understand the difference between these two deployment models, see Understanding deployment models and the state of your resources.

If you want to use a different version of this article, use the table of contents in the left pane.

About VNet-to-VNet connections

Connecting a virtual network to another virtual network (VNet-to-VNet) in the classic deployment model using a VPN gateway is similar to connecting a virtual network to an on-premises site location. Both connectivity types use a VPN gateway to provide a secure tunnel using IPsec/IKE.

The VNets you connect can be in different subscriptions and different regions. You can combine VNet to VNet communication with multi-site configurations. This lets you establish network topologies that combine cross-premises connectivity with inter-virtual network connectivity.

Diagram showing VNet-VNet connections.

Why connect virtual networks?

You might want to connect virtual networks for the following reasons:

  • 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 set up highly available workload with geo-redundancy across multiple Azure regions. One important example is to set up 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 set up multi-tier applications with multiple VNets 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 connect workloads from different subscriptions together securely between virtual networks.
    • For enterprises or service providers, you can enable cross-organization communication with secure VPN technology within Azure.

For more information about VNet-to-VNet connections, see VNet-to-VNet considerations at the end of this article.

Prerequisites

We use the portal for most of the steps, but you must use PowerShell to create the connections between the VNets. You can't create the connections using the Azure portal because there's no way to specify the shared key in the portal. When working with the classic deployment model, you can't use Azure Cloud Shell. Instead, you must install the latest version of the Azure Service Management (SM) PowerShell cmdlets locally on your computer. These cmdlets are different from the AzureRM or Az cmdlets. To install the SM cmdlets, see Install Service Management cmdlets. For more information about Azure PowerShell in general, see the Azure PowerShell documentation.

Planning

It’s important to decide the ranges that you’ll use to configure your virtual networks. For this configuration, you must make sure that none of your VNet ranges overlap with each other, or with any of the local networks that they connect to.

VNets

For this exercise, we use the following example values:

Values for TestVNet1

Name: TestVNet1
Address space: 10.11.0.0/16, 10.12.0.0/16 (optional)
Subnet name: default
Subnet address range: 10.11.0.0/24
Resource group: ClassicRG
Location: East US
GatewaySubnet: 10.11.1.0/27

Values for TestVNet4

Name: TestVNet4
Address space: 10.41.0.0/16, 10.42.0.0/16 (optional)
Subnet name: default
Subnet address range: 10.41.0.0/24
Resource group: ClassicRG
Location: West US
GatewaySubnet: 10.41.1.0/27

Connections

The following table shows an example of how you connect your VNets. Use the ranges as a guideline only. Write down the ranges for your virtual networks. You need this information for later steps.

In this example, TestVNet1 connects to a local network site that you create named 'VNet4Local'. The settings for VNet4Local contain the address prefixes for TestVNet4. The local site for each VNet is the other VNet. The following example values are used for our configuration:

Example

Virtual Network Address Space Location Connects to local network site
TestVNet1 TestVNet1
(10.11.0.0/16)
(10.12.0.0/16)		 East US SiteVNet4
(10.41.0.0/16)
(10.42.0.0/16)
TestVNet4 TestVNet4
(10.41.0.0/16)
(10.42.0.0/16)		 West US SiteVNet1
(10.11.0.0/16)
(10.12.0.0/16)

Create virtual networks

In this step, you create two classic virtual networks, TestVNet1 and TestVNet4. If you're using this article as an exercise, use the example values.

When creating your VNets, keep in mind the following settings:

  • Virtual Network Address Spaces – On the Virtual Network Address Spaces page, specify the address range that you want to use for your virtual network. These are the dynamic IP addresses that will be assigned to the VMs and other role instances that you deploy to this virtual network.
    The address spaces you select can't overlap with the address spaces for any of the other VNets or on-premises locations that this VNet will connect to.

  • Location – When you create a virtual network, you associate it with an Azure location (region). For example, if you want your VMs that are deployed to your virtual network to be physically located in West US, select that location. You can’t change the location associated with your virtual network after you create it.

After creating your VNets, you can add the following settings:

  • Address space – Additional address space isn't required for this configuration, but you can add additional address space after creating the VNet.

  • Subnets – Additional subnets aren't required for this configuration, but you might want to have your VMs in a subnet that is separate from your other role instances.

  • DNS servers – Enter the DNS server name and IP address. This setting doesn't create a DNS server. It allows you to specify the DNS servers that you want to use for name resolution for this virtual network.

To create a classic virtual network

  1. From a browser, navigate to the Azure portal and, if necessary, sign in with your Azure account.
  2. Select +Create a resource. In the Search the marketplace field, type 'Virtual Network'. Locate Virtual Network from the returned list and select it to open the Virtual Network page.
  3. On the Virtual Network page, under the Create button, you see "Deploy with Resource Manager (change to Classic)". Resource Manager is the default for creating a VNet. You don't want to create a Resource Manager VNet. Select (change to Classic) to create a Classic VNet. Then, select the Overview tab and select Create.
  4. On the Create virtual network(classic) page, on the Basics tab, configure the VNet settings with the example values.
  5. Select Review + create to validate your VNet.
  6. Validation runs. After the VNet is validated, select Create.

DNS settings are not a required part of this configuration, but DNS is necessary if you want name resolution between your VMs. Specifying a value does not create a new DNS server. The DNS server IP address that you specify should be a DNS server that can resolve the names for the resources you are connecting to.

After you create your virtual network, you can add the IP address of a DNS server to handle name resolution. Open the settings for your virtual network, select DNS servers, and add the IP address of the DNS server that you want to use for name resolution.

  1. Locate the virtual network in the portal.
  2. On the page for your virtual network, under the Settings section, select DNS servers.
  3. Add a DNS server.
  4. To save your settings, select Save at the top of the page.

Configure sites and gateways

Azure uses the settings specified in each local network site to determine how to route traffic between the VNets. Each VNet must point to the respective local network that you want to route traffic to. You determine the name you want to use to refer to each local network site. It's best to use something descriptive.

For example, TestVNet1 connects to a local network site that you create named 'VNet4Local'. The settings for VNet4Local contain the address prefixes for TestVNet4.

Keep in mind, the local site for each VNet is the other VNet.

Virtual Network Address Space Location Connects to local network site
TestVNet1 TestVNet1
(10.11.0.0/16)
(10.12.0.0/16)		 East US SiteVNet4
(10.41.0.0/16)
(10.42.0.0/16)
TestVNet4 TestVNet4
(10.41.0.0/16)
(10.42.0.0/16)		 West US SiteVNet1
(10.11.0.0/16)
(10.12.0.0/16)

To configure a site

The local site typically refers to your on-premises location. It contains the IP address of the VPN device to which you'll create a connection, and the IP address ranges that are routed through the VPN gateway to the VPN device.

  1. On the page for your VNet, under Settings, select Site-to-site connections.

  2. On the Site-to-site connections page, select + Add.

  3. On the Configure a VPN connection and gateway page, for Connection type, leave Site-to-site selected.

    • VPN gateway IP address: This is the public IP address of the VPN device for your on-premises network. For this exercise, you can put in a dummy address because you don't yet have the IP address for the VPN gateway for the other site. For example, 5.4.3.2. Later, once you have configured the gateway for the other VNet, you can adjust this value.

    • Client Address space: List the IP address ranges that you want routed to the other VNet through this gateway. You can add multiple address space ranges. Make sure that the ranges you specify here don't overlap with ranges of other networks your virtual network connects to, or with the address ranges of the virtual network itself.

  4. At the bottom of the page, DO NOT select Review + create. Instead, select Next: Gateway>.

To configure a virtual network gateway

  1. On the Gateway page, select the following values:

    • Size: This is the gateway SKU that you use to create your virtual network gateway. Classic VPN gateways use the old (legacy) gateway SKUs. For more information about the legacy gateway SKUs, see Working with virtual network gateway SKUs (old SKUs). You can select Standard for this exercise.

    • Gateway subnet: The size of the gateway subnet that you specify depends on the VPN gateway configuration that you want to create. While it's possible to create a gateway subnet as small as /29, we recommend that you use /27 or /28. This creates a larger subnet that includes more addresses. Using a larger gateway subnet allows for enough IP addresses to accommodate possible future configurations.

  2. Select Review + create at the bottom of the page to validate your settings. Select Create to deploy. It can take up to 45 minutes to create a virtual network gateway, depending on the gateway SKU that you selected.

  3. You can start proceed to the next step while this gateway is creating.

Configure TestVNet4 settings

Repeat the steps for Create a site and gateway to configure TestVNet4, substituting the values when necessary. If you're doing this as an exercise, use the example values.

Update local sites

After your virtual network gateways have been created for both VNets, you must adjust the local site properties for VPN gateway IP address.

VNet name Connected site Gateway IP address
TestVNet1 VNet4Local VPN gateway IP address for TestVNet4
TestVNet4 VNet1Local VPN gateway IP address for TestVNet1

Part 1 - Get the virtual network gateway public IP address

  1. Navigate to your VNet by going to the Resource group and selecting the virtual network.
  2. On the page for your virtual network, in the Essentials pane on the right, locate the Gateway IP address and copy to clipboard.

Part 2 - Modify the local site properties

  1. Under Site-to-site connections, select the connection. For example, SiteVNet4.
  2. On the Properties page for the Site-to-site connection, select Edit local site.
  3. In the VPN gateway IP address field, paste the VPN gateway IP address you copied in the previous section.
  4. Select OK.
  5. The field is updated in the system. You can also use this method to add additional IP address that you want to route to this site.

Part 3 - Repeat steps for the other VNet

Repeat the steps for TestVNet4.

Retrieve configuration values

When you create classic VNets in the Azure portal, the name that you view is not the full name that you use for PowerShell. For example, a VNet that appears to be named TestVNet1 in the portal, may have a much longer name in the network configuration file. For a VNet in the resource group "ClassicRG" name might look something like: Group ClassicRG TestVNet1. When you create your connections, it's important to use the values that you see in the network configuration file.

In the following steps, you will connect to your Azure account and download and view the network configuration file to obtain the values that are required for your connections.

  1. Download and install the latest version of the Azure Service Management (SM) PowerShell cmdlets. Most people have the Resource Manager modules installed locally, but do not have Service Management modules. Service Management modules are legacy and must be installed separately. For more information, see Install Service Management cmdlets.

  2. Open your PowerShell console with elevated rights and connect to your account. Use the following examples to help you connect. You must run these commands locally using the PowerShell Service Management module. Connect to your account. Use the following example to help you connect:

    Add-AzureAccount

  3. Check the subscriptions for the account.

    Get-AzureSubscription

  4. If you have more than one subscription, select the subscription that you want to use.

    Select-AzureSubscription -SubscriptionId "Replace_with_your_subscription_ID"

  5. Create a directory on your computer. For example, C:\AzureVNet

  6. Export the network configuration file to the directory. In this example, the network configuration file is exported to C:\AzureNet.

    Get-AzureVNetConfig -ExportToFile C:\AzureNet\NetworkConfig.xml

  7. Open the file with a text editor and view the names for your VNets and sites. These names will be the names you use when you create your connections.
    VNet names are listed as VirtualNetworkSite name =
    Site names are listed as LocalNetworkSiteRef name =

Create connections

When all the previous steps have been completed, you can set the IPsec/IKE preshared keys and create the connection. This set of steps uses PowerShell. VNet-to-VNet connections for the classic deployment model can't be configured in the Azure portal because the shared key can't be specified in the portal.

In the examples, notice that the shared key is exactly the same. The shared key must always match. Be sure to replace the values in these examples with the exact names for your VNets and Local Network Sites.

  1. Create the TestVNet1 to TestVNet4 connection. Make sure to change the values.

    Set-AzureVNetGatewayKey -VNetName 'Group ClassicRG TestVNet1' `
-LocalNetworkSiteName 'value for _VNet4Local' -SharedKey A1b2C3D4

  2. Create the TestVNet4 to TestVNet1 connection.

    Set-AzureVNetGatewayKey -VNetName 'Group ClassicRG TestVNet4' `
-LocalNetworkSiteName 'value for _VNet1Local' -SharedKey A1b2C3D4

  3. Wait for the connections to initialize. Once the gateway has initialized, the Status is 'Successful'.

    Error          :
HttpStatusCode : OK
Id             :
Status         : Successful
RequestId      :
StatusCode     : OK

FAQ and considerations

These considerations apply to classic virtual networks and classic virtual network gateways.

  • The virtual networks can be in the same or different subscriptions.
  • The virtual networks can be in the same or different Azure regions (locations).
  • A cloud service or a load-balancing endpoint can't span across virtual networks, even if they're connected together.
  • Connecting multiple virtual networks together doesn't require any VPN devices.
  • VNet-to-VNet supports connecting Azure Virtual Networks. It doesn't support connecting virtual machines or cloud services that aren't deployed to a virtual network.
  • VNet-to-VNet requires dynamic routing gateways. Azure static routing gateways aren't supported.
  • Virtual network connectivity can be used simultaneously with multi-site VPNs. There is a maximum of 10 VPN tunnels for a virtual network VPN gateway connecting to either 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 cause the creation of virtual networks or uploading netcfg configuration files to fail.
  • Redundant tunnels between a pair of virtual networks aren't supported.
  • All VPN tunnels for the VNet, including P2S VPNs, share the available bandwidth for the VPN gateway, and the same VPN gateway uptime SLA in Azure.
  • VNet-to-VNet traffic travels across the Azure backbone.

Next steps

Verify your connections. See Verify a VPN Gateway connection.