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

This article shows you how to 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. When connecting VNets from different subscriptions, the subscriptions do not need to be associated with the same Active Directory tenant.

The steps in this article apply to the Resource Manager deployment model and use the Azure portal. You can also create this configuration using a different deployment tool or deployment model by selecting a different option from the following list:

v2v diagram

Connecting a virtual network to another virtual network (VNet-to-VNet) is similar to connecting a VNet to an on-premises site location. Both connectivity types use a VPN gateway to provide a secure tunnel using IPsec/IKE. It is possible to create Site-to-site (IPsec) connections between VNets, rather than VNet-to-VNet. Both connection types function the same way when communicating. However, when you create a VNet-to-VNet connection, if you update the address space for one VNet, the other VNet will automatically know to route to the updated address space. If you create Site-to-site (IPsec) connections, you need to update the address space for the local network manually.

If your VNets are in the same region, you may want to consider connecting them using VNet Peering. VNet peering does not use a VPN gateway. For more information, see VNet peering.

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

About connections

Why connect virtual networks?

You may 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 Traffic Manager and Load Balancer, 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 isolation or administrative boundary

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

When using these steps as an exercise, you can use the 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. You can use PowerShell or CLI. For more information about VNet-to-VNet connections, see the VNet-to-VNet FAQ at the end of this article.

Example settings

Values for TestVNet1:

  • VNet Name: TestVNet1
  • Address space: 10.11.0.0/16
  • Subscription: Select the subscription you want to use
  • Resource Group: TestRG1
  • Location: East US
  • Subnet Name: FrontEnd
  • Subnet Address range: 10.11.0.0/24
  • Gateway Subnet name: GatewaySubnet (this will auto-fill in the portal)
  • Gateway Subnet address range: 10.11.255.0/27
  • DNS Server: Use the IP address of your DNS Server
  • Virtual Network Gateway Name: TestVNet1GW
  • Gateway Type: VPN
  • VPN type: Route-based
  • SKU: Select the Gateway SKU you want to use
  • Public IP address name: TestVNet1GWIP
  • Connection Name: TestVNet1toTestVNet4
  • Shared key: You can create the shared key yourself. For this example, we'll use abc123. The important thing is that when you create the connection between the VNets, the value must match.

Values for TestVNet4:

  • VNet Name: TestVNet4
  • Address space: 10.41.0.0/16
  • Subscription: Select the subscription you want to use
  • Resource Group: TestRG4
  • Location: West US
  • Subnet Name: FrontEnd
  • Subnet Address range: 10.41.0.0/24
  • GatewaySubnet name: GatewaySubnet (this will auto-fill in the portal)
  • GatewaySubnet address range: 10.41.255.0/27
  • DNS Server: Use the IP address of your DNS Server
  • Virtual Network Gateway Name: TestVNet4GW
  • Gateway Type: VPN
  • VPN type: Route-based
  • SKU: Select the Gateway SKU you want to use
  • Public IP address name: TestVNet4GWIP
  • Connection Name: TestVNet4toTestVNet1
  • Shared key: You can create the shared key yourself. For this example, we'll use abc123. The important thing is that when you create the connection between the VNets, the value must match.

1. 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. If you have overlapping subnets, your connection won't work properly. If 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

To create a VNet in the Resource Manager deployment model by using the Azure portal, follow the steps below. The screenshots are provided as examples. Be sure to replace the values with your own. For more information about working with virtual networks, see the Virtual Network Overview.

Note

In order for this VNet to connect to an on-premises location you need to 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 does not route the way you may expect it to. Additionally, if you want to connect this VNet to another VNet, the address space cannot overlap with other VNet. Take care to plan your network configuration accordingly.

  1. From a browser, navigate to the Azure portal and, if necessary, sign in with your Azure account.
  2. Click +. In the Search the marketplace field, type "Virtual Network". Locate Virtual Network from the returned list and click to open the Virtual Network page.

    Locate Virtual Network resource page

  3. Near the bottom of the Virtual Network page, from the Select a deployment model list, select Resource Manager, and then click Create.

    Select Resource Manager

  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 entered in the field are valid. There may be values that are auto-filled. If so, replace the values with your own. The Create virtual network page looks similar to the following example:

    Create virtual network page

  5. Name: Enter the name for your virtual network.
  6. Address space: Enter the address space. If you have multiple address spaces to add, add your first address space. You can add additional address spaces later, after creating the VNet.
  7. Subscription: Verify that the Subscription listed is the correct one. You can change subscriptions by using the drop-down.
  8. Resource group: Select an existing resource group, or create a new one by typing a name for your new resource group. If you are creating a new group, name the resource group according to your planned configuration values. For more information about resource groups, visit Azure Resource Manager Overview.
  9. Location: Select the location for your VNet. The location determines where the resources that you deploy to this VNet will reside.
  10. Subnet: Add the subnet name and subnet address range. You can add additional subnets later, after creating the VNet.
  11. Select Pin to dashboard if you want to be able to find your VNet easily on the dashboard, and then click Create.

    Pin to dashboard

2. 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 space, under the Settings section on your virtual network page, click Address space to open the Address space page.
  2. Add the additional address space, and then click 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, click Subnets to open the Subnets page.
  2. On the Subnets page, click +Subnet to open the Add subnet page. Name your new subnet and specify the address range.

    Subnet settings

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

    Subnet settings

3. Create a gateway subnet

Before connecting your virtual network to a gateway, you first need to create the gateway subnet for the virtual network to which you want to connect. If possible, it's best to create a gateway subnet using a CIDR block of /28 or /27 in order to provide enough IP addresses to accommodate additional future configuration requirements.

If you are 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 portal, navigate to the Resource Manager virtual network for which you want to create a virtual network gateway.
  2. In the Settings section of your VNet page, click Subnets to expand the Subnets page.
  3. On the Subnets page, click +Gateway subnet to open the Add subnet page.

    Add the gateway subnet

  4. The Name for your subnet is automatically filled in with the value 'GatewaySubnet'. This value is required in order for Azure to recognize the subnet as the gateway subnet. Adjust the auto-filled Address range values to match your configuration requirements, then click OK at the bottom of the page to create the subnet.

    Adding the subnet

4. Specify a DNS server (optional)

DNS is not required for VNet-to-VNet connections. However, if you want to have name resolution for resources that are deployed to your virtual network, you should 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 does not create a DNS server.

  1. On the Settings page for your virtual network, navigate to DNS Servers and click to open the DNS servers blade.

    Add DNS server

    • DNS Servers: Select select Custom.
    • Add DNS server: Enter the IP address of the DNS server that you want to use for name resolution.
  2. When you are done adding DNS servers, click Save at the top of the blade.

5. 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 are creating this configuration as an exercise, you can refer to the Example settings.

To create a virtual network gateway

  1. In the portal, on the left side, click + and type 'virtual network gateway' in search. Locate Virtual network gateway in the search return and click the entry. On the Virtual network gateway page, click Create at the bottom of the page to open the Create virtual network gateway page.
  2. On the Create virtual network gateway page, fill in the values for your virtual network gateway.

    Create virtual network gateway page fields

  3. On the Create virtual network gateway page, specify the values for your virtual network gateway.

    • Name: Name your gateway. This is not the same as naming a gateway subnet. It's the name of the gateway object you are creating.
    • Gateway type: Select VPN. VPN gateways use the virtual network gateway type VPN.
    • 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.
    • Location: You may need to scroll to see Location. Adjust the Location field to point to the location where your virtual network is located. If the location is not pointing to the region where your virtual network resides, when you select a virtual network in the next step, it will not appear in the drop-down list.
    • Virtual network: Choose the virtual network to which you want to add this gateway. Click Virtual network to open the 'Choose a virtual network' page. Select the VNet. If you don't see your VNet, make sure the Location field is pointing to the region in which your virtual network is located.
    • Gateway subnet address range: You will only see this setting if you did not previously create a gateway subnet for your virtual network. If you previously created a valid gateway subnet, this setting will not appear.
    • First IP configuration: The 'Choose public IP address' page creates a public IP address object that gets associated to the VPN gateway. The public IP address is dynamically assigned to this object when the VPN gateway is created. VPN Gateway currently only supports Dynamic Public IP address allocation. However, this does not 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.

      • First, click Create gateway IP configuration to open the 'Choose public IP address' page, then click +Create new to open the 'Create public IP address' page.
      • Next, input a Name for your public IP address. Leave the SKU as Basic unless there is a specific reason to change it to something else, then click OK at the bottom of this page to save your changes.

        Create public IP

  4. Verify the settings. You can select Pin to dashboard at the bottom of the page if you want your gateway to appear on the dashboard.

  5. Click 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.

After the gateway is created, view the IP address that has been assigned to it by looking at the virtual network in the portal. The gateway appears as a connected device. You can click the connected device (your virtual network gateway) to view more information.

6. Create and configure TestVNet4

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

7. 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. See the PowerShell article. However, if your VNets are in different resource groups in the same subscription, you can connect them using the portal.

  1. In All resources, navigate to the virtual network gateway for your VNet. For example, TestVNet1GW. Click TestVNet1GW to open the virtual network gateway page.

    Connections page

  2. Click +Add to open the Add connection page.

    Add connection

  3. On the Add connection page, in the name field, type a name for your connection. For example, TestVNet1toTestVNet4.
  4. For Connection type, select VNet-to-VNet from the dropdown.
  5. The First virtual network gateway field value is automatically filled in because you are creating this connection from the specified virtual network gateway.
  6. The Second virtual network gateway field is the virtual network gateway of the VNet that you want to create a connection to. Click Choose another virtual network gateway to open the Choose virtual network gateway page.
  7. 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 is not in your subscription, please use the PowerShell article.
  8. Click the virtual network gateway that you want to connect to.
  9. In the Shared key field, type a shared key for your connection. You can generate or create this key yourself. In a site-to-site connection, the key you use would be exactly 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 are connecting to another virtual network gateway.
  10. Click OK at the bottom of the page to save your changes.

8. 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.

9. Verify your connections

Locate the virtual network gateway in the portal. On the virtual network gateway page, click Connections to view the connections page for the virtual network gateway. Once the connection is established, you see the Status values change to Succeeded and Connected. You can double-click a connection to open the Essentials page and view more information.

Succeeded

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

Essentials

To add additional connections

If you want to add additional connections, navigate to the virtual network gateway that you want to create the connection from, then click 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 creating additional connections, verify that the address space for your virtual network does not overlap with any of the address spaces that 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. If you are looking for 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 using 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. Refer to the VPN Gateway pricing page for details. If you are connecting your VNets using VNet Peering, rather than VPN Gateway, see the Virtual Network pricing page.

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

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

Is VNet-to-VNet traffic secure?

Yes, it is 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 are not in the same subscription, do the subscriptions need to be associated with the same AD 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 public Azure and the Chinese / German / US Gov Azure instances. For these scenarios, consider using a Site-to-Site VPN connection.

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 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 does not support connecting virtual machines or cloud services that are not 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 are connected together.

Can I used 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 be using 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

See Network Security for information about how you can limit network traffic to resources in a virtual network.

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