Configure a VNet-to-VNet VPN gateway connection by using the Azure portal

This article helps you connect virtual networks (VNets) by using the VNet-to-VNet connection type. Virtual networks can be in different regions and from different subscriptions. When you connect VNets from different subscriptions, the subscriptions don't need to be associated with the same Active Directory tenant.

v2v diagram

The steps in this article apply to the Azure Resource Manager deployment model and use the Azure portal. You can create this configuration with a different deployment tool or model by using options that are described in the following articles:

About connecting VNets

The following sections describe the different ways to connect virtual networks.

VNet-to-VNet

Configuring a VNet-to-VNet connection is a simple way to connect VNets. When you connect a virtual network to another virtual network with a VNet-to-VNet connection type (VNet2VNet), it's similar to creating a Site-to-Site IPsec connection to an on-premises location. Both connection types use a VPN gateway to provide a secure tunnel with IPsec/IKE and function the same way when communicating. However, they differ in the way the local network gateway is configured.

When you create a VNet-to-VNet connection, the local network gateway address space is automatically created and populated. If you update the address space for one VNet, the other VNet automatically routes to the updated address space. It's typically faster and easier to create a VNet-to-VNet connection than a Site-to-Site connection.

Site-to-Site (IPsec)

If you're working with a complicated network configuration, you may prefer to connect your VNets by using a Site-to-Site connection instead. When you follow the Site-to-Site IPsec steps, you create and configure the local network gateways manually. The local network gateway for each VNet treats the other VNet as a local site. These steps allow you to specify additional address spaces for the local network gateway to route traffic. If the address space for a VNet changes, you must manually update the corresponding local network gateway.

VNet peering

You can also connect your VNets by using VNet peering. VNet peering doesn't use a VPN gateway and has different constraints. Additionally, VNet peering pricing is calculated differently than VNet-to-VNet VPN Gateway pricing. For more information, see VNet peering.

Why create a VNet-to-VNet connection?

You may want to connect virtual networks by using a VNet-to-VNet connection 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 Traffic Manager and Azure Load Balancer, you can set up highly available workload with geo-redundancy across multiple Azure regions. For example, you can set up SQL Server Always On availability groups across multiple Azure regions.

Regional multi-tier applications with isolation or administrative boundaries

  • Within the same region, you can set up multi-tier applications with multiple virtual networks that are connected together because of isolation or administrative requirements.

VNet-to-VNet communication can be combined with multi-site configurations. These configurations lets you establish network topologies that combine cross-premises connectivity with inter-virtual network connectivity, as shown in the following diagram:

About connections

This article shows you how to connect VNets by using the VNet-to-VNet connection type. When you follow these steps as an exercise, you can use the following example settings values. In the example, the virtual networks are in the same subscription, but in different resource groups. If your VNets are in different subscriptions, you can't create the connection in the portal. Use PowerShell or CLI instead. For more information about VNet-to-VNet connections, see VNet-to-VNet FAQ.

Example settings

Values for TestVNet1:

  • Virtual network settings

    • Name: Enter TestVNet1.
    • Address space: Enter 10.11.0.0/16.
    • Subscription: Select the subscription you want to use.
    • Resource group: Enter TestRG1.
    • Location: Select East US.
    • Subnet
      • Name: Enter FrontEnd.
      • Address range: Enter 10.11.0.0/24.
    • Gateway subnet:
      • Name: GatewaySubnet is autofilled.
      • Address range: Enter 10.11.255.0/27.
    • DNS server: Select Custom and enter the IP address of your DNS server.
  • Virtual network gateway settings

    • Name: Enter TestVNet1GW.
    • Gateway type: Select VPN.
    • VPN type: Select Route-based.
    • SKU: Select the gateway SKU you want to use.
    • Public IP address name: Enter TestVNet1GWIP
    • Connection
      • Name: Enter TestVNet1toTestVNet4.
      • Shared key: Enter abc123. You can create the shared key yourself. When you create the connection between the VNets, the values must match.

Values for TestVNet4:

  • Virtual network settings

    • Name: Enter TestVNet4.
    • Address space: Enter 10.41.0.0/16.
    • Subscription: Select the subscription you want to use.
    • Resource group: Enter TestRG4.
    • Location: Select West US.
    • Subnet
      • Name: Enter FrontEnd.
      • Address range: Enter 10.41.0.0/24.
    • GatewaySubnet
      • Name: GatewaySubnet is autofilled.
      • Address range: Enter 10.41.255.0/27.
    • DNS server: Select Custom and enter the IP address of your DNS server.
  • Virtual network gateway settings

    • Name: Enter TestVNet4GW.
    • Gateway type: Select VPN.
    • VPN type: Select Route-based.
    • SKU: Select the gateway SKU you want to use.
    • Public IP address name: Enter TestVNet4GWIP.
    • Connection
      • Name: Enter TestVNet4toTestVNet1.
      • Shared key: Enter abc123. You can create the shared key yourself. When you create the connection between the VNets, the values must match.

Create and configure TestVNet1

If you already have a VNet, verify that the settings are compatible with your VPN gateway design. Pay particular attention to any subnets that may overlap with other networks. Your connection won't work properly if you have overlapping subnets. After your VNet is configured with the correct settings, you can begin the steps in the Specify a DNS server section.

To create a virtual network

You can create a VNet with the Resource Manager deployment model and the Azure portal by following these steps. For more information about virtual networks, see Virtual Network overview.

Note

For the VNet to connect to an on-premises location, coordinate with your on-premises network administrator to carve out an IP address range that you can use specifically for this virtual network. If a duplicate address range exists on both sides of the VPN connection, traffic will route in an unexpected way. Additionally, if you want to connect this VNet to another VNet, the address space cannot overlap with other VNet. Plan your network configuration accordingly.

  1. Sign in to the Azure portal and select Create a resource. The New page opens.

  2. In the Search the marketplace field, enter virtual network and select Virtual network from the returned list. The Virtual network page opens.

    Locate Virtual Network resource page

  3. From the Select a deployment model list near the bottom of the page, select Resource Manager, and then select Create. The Create virtual network page opens.

    Create virtual network page

  4. On the Create virtual network page, configure the VNet settings. When you fill in the fields, the red exclamation mark becomes a green check mark when the characters you enter in the field are validated. Some values are autofilled, which you can replace with your own values:

    • Name: Enter the name for your virtual network.

    • Address space: Enter the address space. If you have multiple address spaces to add, enter your first address space here. You can add additional address spaces later, after you create the VNet.

    • Subscription: Verify that the subscription listed is the correct one. You can change subscriptions by using the drop-down.

    • Resource group: Select an existing resource group, or create a new one by entering a name for your new resource group. If you're creating a new group, name the resource group according to your planned configuration values. For more information about resource groups, see Azure Resource Manager overview.

    • Location: Select the location for your VNet. The location determines where the resources that you deploy to this VNet will live.

    • Subnet: Add the subnet Name and subnet Address range. You can add additional subnets later, after you create the VNet.

  5. Select Create.

Add additional address space and create subnets

You can add additional address space and create subnets once your VNet has been created.

To add additional address space

  1. To add additional address ranges to your address space, in the Settings section of your virtual network page, select Address space. The Address space page appears.
  2. Add the additional address range, and then select Save at the top of the page.

    Add address space

To create additional subnets

  1. To create subnets, in the Settings section of your virtual network page, select Subnets. The Subnets page appears.
  2. Select Subnet to open the Add subnet page. Enter the Name of your new subnet and specify the Address range.

    Subnet settings

  3. To save your changes, select OK at the bottom of the page.

Create a gateway subnet

Before creating a virtual network gateway for your virtual network, you first need to create the gateway subnet. The gateway subnet contains the IP addresses that are used by the virtual network gateway. If possible, it's best to create a gateway subnet by using a CIDR block of /28 or /27 to provide enough IP addresses to accommodate future additional configuration requirements.

If you're creating this configuration as an exercise, refer to these Example settings when creating your gateway subnet.

Important

When working with gateway subnets, avoid associating a network security group (NSG) to the gateway subnet. Associating a network security group to this subnet may cause your VPN gateway to stop functioning as expected. For more information about network security groups, see What is a network security group?

To create a gateway subnet

  1. In the Azure portal, select the Resource Manager virtual network for which you want to create a virtual network gateway.

  2. In the Settings section of your virtual network page, select Subnets to expand the Subnets page.

  3. On the Subnets page, select Gateway subnet to open the Add subnet page.

    Add the gateway subnet

  4. The Name for your subnet is automatically autofilled with the value GatewaySubnet. This value is required for Azure to recognize the subnet as the gateway subnet. Adjust the autofilled Address range values to match your configuration requirements, then select OK to create the subnet.

    Adding the subnet

Specify a DNS server (optional)

DNS isn't required for VNet-to-VNet connections. However, if you want to have name resolution for resources that are deployed to your virtual network, specify a DNS server. This setting lets you specify the DNS server that you want to use for name resolution for this virtual network. It doesn't create a DNS server.

  1. In the Settings section of your virtual network page, select DNS servers to open the DNS servers page.

  2. On the DNS servers page, fill in the following values:

    • DNS servers: Select Custom.

    • Add DNS server: Enter the IP address of the DNS server that you want to use for name resolution.

  3. When you're done adding DNS servers, select Save.

    Specify a DNS server

Create a virtual network gateway

In this step, you create the virtual network gateway for your VNet. Creating a gateway can often take 45 minutes or more, depending on the selected gateway SKU. If you're creating this configuration as an exercise, see the Example settings.

To create a virtual network gateway

  1. Sign in to the Azure portal and select Create a resource. The New page opens.

  2. In the Search the marketplace field, enter virtual network gateway, and select Virtual network gateway from the search list.

  3. On the Virtual network gateway page, select Create to open the Create virtual network gateway page.

    Create virtual network gateway page fields

  4. On the Create virtual network gateway page, fill in the values for your virtual network gateway:

    • Name: Enter a name for the gateway object you're creating. This name is different than the gateway subnet name.

    • Gateway type: Select VPN for VPN gateways.

    • VPN type: Select the VPN type that is specified for your configuration. Most configurations require a Route-based VPN type.

    • SKU: Select the gateway SKU from the dropdown. The SKUs listed in the dropdown depend on the VPN type you select. For more information about gateway SKUs, see Gateway SKUs.

      Only select Enable active-active mode if you're creating an active-active gateway configuration. Otherwise, leave this setting unselected.

    • Location: You may need to scroll to see Location. Set Location to the location where your virtual network is located. For example, West US. If you don't set the location to the region where your virtual network is located, it won't appear in the drop-down list when you select a virtual network.

    • Virtual network: Choose the virtual network to which you want to add this gateway. Select Virtual network to open the Choose virtual network page and select the VNet. If you don't see your VNet, make sure the Location field is set to the region in which your virtual network is located.

    • Gateway subnet address range: You'll only see this setting if you didn't previously create a gateway subnet for your virtual network. If you previously created a valid gateway subnet, this setting won't appear.

    • Public IP address: This setting specifies the public IP address object that's associated with the VPN gateway. The public IP address is dynamically assigned to this object when the VPN gateway is created. The VPN gateway currently supports only Dynamic public IP address allocation. However, dynamic allocation doesn't mean that the IP address changes after it has been assigned to your VPN gateway. The only time the public IP address changes is when the gateway is deleted and re-created. It doesn't change across resizing, resetting, or other internal maintenance/upgrades of your VPN gateway.

      • Leave Create new selected.

      • In the text box, enter a name for your public IP address.

    • Configure BGP ASN: Leave this setting unselected, unless your configuration specifically requires it. If you do require this setting, the default ASN is 65515, which you can change.

  5. Verify the settings and select Create to begin creating the VPN gateway. The settings are validated and you'll see the Deploying Virtual network gateway tile on the dashboard. Creating a gateway can take up to 45 minutes. You may need to refresh your portal page to see the completed status.

  6. After you create the gateway, verify the IP address that's been assigned to it by viewing the virtual network in the portal. The gateway appears as a connected device. You can select the connected device (your virtual network gateway) to view more information.

Create and configure TestVNet4

After you've configured TestVNet1, create TestVNet4 by repeating the previous steps and replacing the values with TestVNet4 values. You don't need to wait until the virtual network gateway for TestVNet1 has finished creating before you configure TestVNet4. If you're using your own values, make sure the address spaces don't overlap with any of the VNets to which you want to connect.

Configure the TestVNet1 gateway connection

When the virtual network gateways for both TestVNet1 and TestVNet4 have completed, you can create your virtual network gateway connections. In this section, you create a connection from VNet1 to VNet4. These steps work only for VNets in the same subscription. If your VNets are in different subscriptions, you must use PowerShell to make the connection. However, if your VNets are in different resource groups in the same subscription, you can connect them by using the portal.

  1. In the Azure portal, select All resources, enter virtual network gateway in the search box, and then navigate to the virtual network gateway for your VNet. For example, TestVNet1GW. Select it to open the Virtual network gateway page.

    Connections page

  2. Under Settings, select Connections, and then select Add to open the Add connection page.

    Add connection

  3. On the Add connection page, fill in the values for your connection:

    • Name: Enter a name for your connection. For example, TestVNet1toTestVNet4.

    • Connection type: Select VNet-to-VNet from the drop-down.

    • First virtual network gateway: This field value is automatically filled in because you're creating this connection from the specified virtual network gateway.

    • Second virtual network gateway: This field is the virtual network gateway of the VNet that you want to create a connection to. Select Choose another virtual network gateway to open the Choose virtual network gateway page.

      • View the virtual network gateways that are listed on this page. Notice that only virtual network gateways that are in your subscription are listed. If you want to connect to a virtual network gateway that isn't in your subscription, use the PowerShell.

      • Select the virtual network gateway to which you want to connect.

      • Shared key (PSK): In this field, enter a shared key for your connection. You can generate or create this key yourself. In a site-to-site connection, the key you use is the same for your on-premises device and your virtual network gateway connection. The concept is similar here, except that rather than connecting to a VPN device, you're connecting to another virtual network gateway.

  4. Select OK to save your changes.

Configure the TestVNet4 gateway connection

Next, create a connection from TestVNet4 to TestVNet1. In the portal, locate the virtual network gateway associated with TestVNet4. Follow the steps from the previous section, replacing the values to create a connection from TestVNet4 to TestVNet1. Make sure that you use the same shared key.

Verify your connections

Locate the virtual network gateway in the Azure portal. On the Virtual network gateway page, select Connections to view the Connections page for the virtual network gateway. After the connection is established, you'll see the Status values change to Succeeded and Connected. Select a connection to open the Essentials page and view more information.

Succeeded

When data begins flowing, you'll see values for Data in and Data out.

Essentials

Add additional connections

If you want to add additional connections, navigate to the virtual network gateway from which you want to create the connection, then select Connections. You can create another VNet-to-VNet connection, or create an IPsec Site-to-Site connection to an on-premises location. Be sure to adjust the Connection type to match the type of connection you want to create. Before you create additional connections, verify that the address space for your virtual network doesn't overlap with any of the address spaces you want to connect to. For steps to create a Site-to-Site connection, see Create a Site-to-Site connection.

VNet-to-VNet FAQ

View the FAQ details for additional information about VNet-to-VNet connections.

The VNet-to-VNet FAQ applies to VPN gateway connections. For information about VNet peering, see Virtual network peering.

Does Azure charge for traffic between VNets?

VNet-to-VNet traffic within the same region is free for both directions when you use a VPN gateway connection. Cross-region VNet-to-VNet egress traffic is charged with the outbound inter-VNet data transfer rates based on the source regions. For more information, see VPN Gateway pricing page. If you're connecting your VNets by using VNet peering instead of a VPN gateway, see Virtual network pricing.

Does VNet-to-VNet traffic travel across the internet?

No. VNet-to-VNet traffic travels across the Microsoft Azure backbone, not the internet.

Can I establish a VNet-to-VNet connection across Azure Active Directory (AAD) tenants?

Yes, VNet-to-VNet connections that use Azure VPN gateways work across AAD tenants.

Is VNet-to-VNet traffic secure?

Yes, it's protected by IPsec/IKE encryption.

Do I need a VPN device to connect VNets together?

No. Connecting multiple Azure virtual networks together doesn't require a VPN device unless cross-premises connectivity is required.

Do my VNets need to be in the same region?

No. The virtual networks can be in the same or different Azure regions (locations).

If the VNets aren't in the same subscription, do the subscriptions need to be associated with the same Active Directory tenant?

No.

Can I use VNet-to-VNet to connect virtual networks in separate Azure instances?

No. VNet-to-VNet supports connecting virtual networks within the same Azure instance. For example, you can’t create a connection between global Azure and Chinese/German/US government Azure instances. Consider using a Site-to-Site VPN connection for these scenarios.

Can I use VNet-to-VNet along with multi-site connections?

Yes. Virtual network connectivity can be used simultaneously with multi-site VPNs.

How many on-premises sites and virtual networks can one virtual network connect to?

See the Gateway requirements table.

Can I use VNet-to-VNet to connect VMs or cloud services outside of a VNet?

No. VNet-to-VNet supports connecting virtual networks. It doesn't support connecting virtual machines or cloud services that aren't in a virtual network.

Can a cloud service or a load-balancing endpoint span VNets?

No. A cloud service or a load-balancing endpoint can't span across virtual networks, even if they're connected together.

Can I use a PolicyBased VPN type for VNet-to-VNet or Multi-Site connections?

No. VNet-to-VNet and Multi-Site connections require Azure VPN gateways with RouteBased (previously called dynamic routing) VPN types.

Can I connect a VNet with a RouteBased VPN Type to another VNet with a PolicyBased VPN type?

No, both virtual networks MUST use route-based (previously called dynamic routing) VPNs.

Do VPN tunnels share bandwidth?

Yes. All VPN tunnels of the virtual network share the available bandwidth on the Azure VPN gateway and the same VPN gateway uptime SLA in Azure.

Are redundant tunnels supported?

Redundant tunnels between a pair of virtual networks are supported when one virtual network gateway is configured as active-active.

Can I have overlapping address spaces for VNet-to-VNet configurations?

No. You can't have overlapping IP address ranges.

Can there be overlapping address spaces among connected virtual networks and on-premises local sites?

No. You can't have overlapping IP address ranges.

Next steps

For information about how you can limit network traffic to resources in a virtual network, see Network Security.

For information about how Azure routes traffic between Azure, on-premises, and Internet resources, see Virtual network traffic routing.