Edit

Create, change, or delete a virtual network peering

  • Article
  • 24 minutes to read

Learn how to create, change, or delete a virtual network peering. Virtual network peering enables you to connect virtual networks in the same region and across regions (also known as Global VNet Peering) through the Azure backbone network. Once peered, the virtual networks are still managed as separate resources. If you're new to virtual network peering, you can learn more about it in the virtual network peering overview or by completing the virtual network peering tutorial.

Prerequisites

If you don't have an Azure account with an active subscription, create one for free. Complete one of these tasks before starting the remainder of this article:

  • Portal users: Sign in to the Azure portal with an Azure account that has the necessary permissions to work with peerings.

  • PowerShell users: Either run the commands in the Azure Cloud Shell, or run PowerShell locally from your computer. The Azure Cloud Shell is a free interactive shell that you can use to run the steps in this article. It has common Azure tools preinstalled and configured to use with your account. In the Azure Cloud Shell browser tab, find the Select environment dropdown list, then pick PowerShell if it isn't already selected.

    If you're running PowerShell locally, use Azure PowerShell module version 1.0.0 or later. Run Get-Module -ListAvailable Az.Network to find the installed version. If you need to install or upgrade, see Install Azure PowerShell module. Run Connect-AzAccount to sign in to Azure with an account that has the necessary permissions to work with VNet peerings.

  • Azure CLI users: Either run the commands in the Azure Cloud Shell, or run Azure CLI locally from your computer. The Azure Cloud Shell is a free interactive shell that you can use to run the steps in this article. It has common Azure tools preinstalled and configured to use with your account. In the Azure Cloud Shell browser tab, find the Select environment dropdown list, then pick Bash if it isn't already selected.

    If you're running Azure CLI locally, use Azure CLI version 2.0.31 or later. Run az --version to find the installed version. If you need to install or upgrade, see Install Azure CLI. Run az login to sign in to Azure with an account that has the necessary permissions to work with VNet peerings.

The account you log into, or connect to Azure with, must be assigned to the network contributor role or to a custom role that gets assigned the appropriate actions listed in Permissions.

Create a peering

Before creating a peering, familiarize yourself with the requirements and constraints and necessary permissions.

  1. In the search box at the top of the Azure portal, enter Virtual networks in the search box. When Virtual networks appear in the search results, select it. Don't select Virtual networks (classic), as you can't create a peering from a virtual network deployed through the classic deployment model.

    Screenshot of searching for virtual networks.

  2. Select the virtual network in the list that you want to create a peering for.

    Screenshot of selecting VNetA from the virtual networks page.

  3. Select Peerings under Settings and then select + Add.

    Screenshot of peerings page for VNetA.

  4. Enter or select values for the following settings, and then select Add.

    Settings Description
    This virtual network
    Peering link name The name of the peering on this virtual network. The name must be unique within the virtual network.
    Traffic to remote virtual network - Select Allow (default) if you want to enable communication between the two virtual networks through the default VirtualNetwork flow. Enabling communication between virtual networks allows resources that are connected to either virtual network to communicate with each other over the Azure private network. The VirtualNetwork service tag for network security groups encompasses the virtual network and peered virtual network when this setting is set to Allow. To learn more about service tags, see Azure service tags.
    - Select Block all traffic to the remote virtual network if you don't want traffic to flow to the peered virtual network by default. You can select this setting if you have peering between two virtual networks but occasionally want to disable default traffic flow between the two. You may find enabling/disabling is more convenient than deleting and re-creating peerings. When this setting is selected, traffic doesn't flow between the peered virtual networks by default; however, traffic may still flow if explicitly allowed through a network security group rule that includes the appropriate IP addresses or application security groups.

    NOTE: Selecting the Block all traffic to remote virtual network setting only changes the definition of the VirtualNetwork service tag. It doesn't fully prevent traffic flow across the peer connection, as explained in this setting description.
    Traffic forwarded from remote virtual network Select Allow (default) if you want traffic forwarded by a network virtual appliance in the remote virtual network (that didn't originate from the remote virtual network) to flow to this virtual network through a peering. For example, consider three virtual networks named Spoke1, Spoke2, and Hub. A peering exists between each spoke virtual network and the Hub virtual network, but peerings doesn't exist between the spoke virtual networks. A network virtual appliance gets deployed in the Hub virtual network, and user-defined routes gets applied to each spoke virtual network that route traffic between the subnets through the network virtual appliance. If this setting isn't selected for the peering between each spoke virtual network and the hub virtual network, traffic doesn't flow between the spoke virtual networks because the hub isn't forwarding the traffic between the virtual networks. While enabling this capability allows the forwarded traffic through the peering, it doesn't create any user-defined routes or network virtual appliances. User-defined routes and network virtual appliances are created separately. Learn about user-defined routes.

    NOTE: You don't need to select this setting if traffic is forwarded between virtual networks through an Azure VPN Gateway.
    Virtual network gateway or Route Server Select Use this virtual network's gateway or Route Server:
    - If you have a virtual network gateway deployed in this virtual network and want to allow traffic from the peered virtual network to flow through the gateway. For example, this virtual network may be attached to an on-premises network through a virtual network gateway. The gateway can be an ExpressRoute or VPN gateway. Selecting this setting allows traffic from the peered virtual network to flow through the gateway deployed in this virtual network to the on-premises network.
    - If you have a Route Server deployed in this virtual network and you want the peered virtual network to communicate with the Route Server to exchange routes. For more information, see Azure Route Server.

    If you select Use this virtual network's gateway or Router Server, the peered virtual network can't have a gateway configured. The peered virtual network must have the Use the remote virtual network's gateway or Route Server selected when setting up the peering from the other virtual network to this virtual network. If you leave this setting as None (default), traffic from the peered virtual network still flows to this virtual network, but can't flow through a virtual network gateway deployed in this virtual network. If the peering is between a virtual network (Resource Manager) and a virtual network (classic), the gateway must be in the virtual network (Resource Manager).

    In addition to forwarding traffic to an on-premises network, a VPN gateway can forward network traffic between virtual networks that are peered with the virtual network the gateway is in, without the virtual networks needing to be peered with each other. Using a VPN gateway to forward traffic is useful when you want to use a VPN gateway in a hub (see the hub and spoke example described for Allow forwarded traffic) virtual network to route traffic between spoke virtual networks that aren't peered with each other. To learn more about allowing use of a gateway for transit, see Configure a VPN gateway for transit in a virtual network peering. This scenario requires implementing user-defined routes that specify the virtual network gateway as the next hop type. Learn about user-defined routes. You can only specify a VPN gateway as a next hop type in a user-defined route, you can't specify an ExpressRoute gateway as the next hop type in a user-defined route.

    Select Use the remote virtual network's gateway or Route Server:
    - If you want to allow traffic from this virtual network to flow through a virtual network gateway deployed in the virtual network you're peering with. For example, the virtual network you're peering with has a VPN gateway that enables communication to an on-premises network. Selecting this setting allows traffic from this virtual network to flow through the VPN gateway in the peered virtual network.
    - If you want this virtual network to use the remote Route Server to exchange routes. For more information, see Azure Route Server.

    If you select this setting, the peered virtual network must have a virtual network gateway deployed in it, and must have the Use this virtual network's gateway or Route Server setting selected. If you leave this setting as None (default), traffic from this virtual network can still flow to the peered virtual network, but can't flow through a virtual network gateway in the peered virtual network. Only one peering for this virtual network can have this setting enabled.

    NOTE: You can't use remote gateways if you already have a gateway configured in your virtual network. To learn more about using a gateway for transit, see Configure a VPN gateway for transit in a virtual network peering.
    Remote virtual network
    Peering link name The name of the peering on the remote virtual network. The name must be unique within the virtual network.
    Virtual network deployment model Select which deployment model the virtual network you want to peer with was deployed through.
    I know my resource ID If you have read access to the virtual network you want to peer with, leave this checkbox unchecked. If you don't have read access to the virtual network or subscription you want to peer with, check this checkbox. Enter the full resource ID of the virtual network you want to peer with in the Resource ID box that appeared when you checked the checkbox. The resource ID you enter must be for a virtual network that exists in the same, or supported different Azure region as this virtual network. The full resource ID looks similar to /subscriptions/<Id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>. You can get the resource ID for a virtual network by viewing the properties for a virtual network. To learn how to view the properties for a virtual network, see Manage virtual networks. If the subscription is associated to a different Azure Active Directory tenant than the subscription with the virtual network you're creating the peering from, first add a user from each tenant as a guest user in the opposite tenant.
    Resource ID This field appears when you check I know my resource ID checkbox. The resource ID you enter must be for a virtual network that exists in the same, or supported different Azure region as this virtual network. The full resource ID looks similar to /subscriptions/<Id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>. You can get the resource ID for a virtual network by viewing the properties for a virtual network. To learn how to view the properties for a virtual network, see Manage virtual networks. If the subscription is associated to a different Azure Active Directory tenant than the subscription with the virtual network you're creating the peering from, first add a user from each tenant as a guest user in the opposite tenant.
    Subscription Select the subscription of the virtual network you want to peer with. One or more subscriptions are listed, depending on how many subscriptions your account has read access to. If you checked the I know my resource ID checkbox, this setting isn't available.
    Virtual network Select the virtual network you want to peer with. You can select a virtual network created through either Azure deployment model. If you want to select a virtual network in a different region, you must select a virtual network in a supported region. You must have read access to the virtual network for it to be visible in the list. If a virtual network is listed, but grayed out, it may be because the address space for the virtual network overlaps with the address space for this virtual network. If virtual network address spaces overlap, they can't be peered. If you checked the I know my resource ID checkbox, this setting isn't available.
    Traffic to remote virtual network - Select Allow (default) if you want to enable communication between the two virtual networks through the default VirtualNetwork flow. Enabling communication between virtual networks allows resources that are connected to either virtual network to communicate with each other over the Azure private network. The VirtualNetwork service tag for network security groups encompasses the virtual network and peered virtual network when this setting is set to Allow. To learn more about service tags, see Azure service tags.
    - Select Block all traffic to the remote virtual network if you don't want traffic to flow to the peered virtual network by default. You can select this setting if you have peering between two virtual networks but occasionally want to disable default traffic flow between the two. You may find enabling/disabling is more convenient than deleting and re-creating peerings. When this setting is selected, traffic doesn't flow between the peered virtual networks by default; however, traffic may still flow if explicitly allowed through a network security group rule that includes the appropriate IP addresses or application security groups.

    NOTE: Selecting the Block all traffic to remote virtual network setting only changes the definition of the VirtualNetwork service tag. It doesn't fully prevent traffic flow across the peer connection, as explained in this setting description.
    Traffic forwarded from remote virtual network Select Allow (default) if you want traffic forwarded by a network virtual appliance in the remote virtual network (that didn't originate from the remote virtual network) to flow to this virtual network through a peering. For example, consider three virtual networks named Spoke1, Spoke2, and Hub. A peering exists between each spoke virtual network and the Hub virtual network, but peerings doesn't exist between the spoke virtual networks. A network virtual appliance gets deployed in the Hub virtual network, and user-defined routes gets applied to each spoke virtual network that route traffic between the subnets through the network virtual appliance. If this setting isn't selected for the peering between each spoke virtual network and the hub virtual network, traffic doesn't flow between the spoke virtual networks because the hub isn't forwarding the traffic between the virtual networks. While enabling this capability allows the forwarded traffic through the peering, it doesn't create any user-defined routes or network virtual appliances. User-defined routes and network virtual appliances are created separately. Learn about user-defined routes.

    NOTE: You don't need to select this setting if traffic is forwarded between virtual networks through an Azure VPN Gateway.
    Virtual network gateway or Route Server Select Use this virtual network's gateway or Route Server:
    - If you have a virtual network gateway deployed in this virtual network and want to allow traffic from the peered virtual network to flow through the gateway. For example, this virtual network may be attached to an on-premises network through a virtual network gateway. The gateway can be an ExpressRoute or VPN gateway. Selecting this setting allows traffic from the peered virtual network to flow through the gateway deployed in this virtual network to the on-premises network.
    - If you have a Route Server deployed in this virtual network and you want the peered virtual network to communicate with the Route Server to exchange routes. For more information, see Azure Route Server.

    If you select Use this virtual network's gateway or Router Server, the peered virtual network can't have a gateway configured. The peered virtual network must have the Use the remote virtual network's gateway or Route Server selected when setting up the peering from the other virtual network to this virtual network. If you leave this setting as None (default), traffic from the peered virtual network still flows to this virtual network, but can't flow through a virtual network gateway deployed in this virtual network. If the peering is between a virtual network (Resource Manager) and a virtual network (classic), the gateway must be in the virtual network (Resource Manager).

    In addition to forwarding traffic to an on-premises network, a VPN gateway can forward network traffic between virtual networks that are peered with the virtual network the gateway is in, without the virtual networks needing to be peered with each other. Using a VPN gateway to forward traffic is useful when you want to use a VPN gateway in a hub (see the hub and spoke example described for Allow forwarded traffic) virtual network to route traffic between spoke virtual networks that aren't peered with each other. To learn more about allowing use of a gateway for transit, see Configure a VPN gateway for transit in a virtual network peering. This scenario requires implementing user-defined routes that specify the virtual network gateway as the next hop type. Learn about user-defined routes. You can only specify a VPN gateway as a next hop type in a user-defined route, you can't specify an ExpressRoute gateway as the next hop type in a user-defined route.

    Select Use the remote virtual network's gateway or Route Server:
    - If you want to allow traffic from this virtual network to flow through a virtual network gateway deployed in the virtual network you're peering with. For example, the virtual network you're peering with has a VPN gateway that enables communication to an on-premises network. Selecting this setting allows traffic from this virtual network to flow through the VPN gateway in the peered virtual network.
    - If you want this virtual network to use the remote Route Server to exchange routes. For more information, see Azure Route Server.

    If you select this setting, the peered virtual network must have a virtual network gateway deployed in it, and must have the Use this virtual network's gateway or Route Server setting selected. If you leave this setting as None (default), traffic from this virtual network can still flow to the peered virtual network, but can't flow through a virtual network gateway in the peered virtual network. Only one peering for this virtual network can have this setting enabled.

    NOTE: You can't use remote gateways if you already have a gateway configured in your virtual network. To learn more about using a gateway for transit, see Configure a VPN gateway for transit in a virtual network peering.

    Screenshot of peering configuration page.

    Note

    If you use a Virtual Network Gateway to send on-premises traffic transitively to a peered VNet, the peered VNet IP range for the on-premises VPN device must be set to 'interesting' traffic. You may need to add all Azure VNet's CIDR addresses to the Site-2-Site IPSec VPN Tunnel configuration on the on-premises VPN device. CIDR addresses include resources like such as Hub, Spokes, and Point-2-Site IP address pools. Otherwise, your on-premises resources won't be able to communicate with resources in the peered VNet. Intersting traffic is communicated through Phase 2 security associations. The security association creates a dedicated VPN tunnel for each specified subnet. The on-premises and Azure VPN Gateway tier have to support the same number of Site-2-Site VPN tunnels and Azure VNet subnets. Otherwise, your on-premises resources won't be able to communicate with resources in the peered VNet. Consult your on-premises VPN documentation for instructions to create Phase 2 security associations for each specified Azure VNet subnet.

  5. Select the Refresh button after a few seconds, and the peering status will change from Updating to Connected.

    Screenshot of virtual network peering status on peerings page.

For step-by-step instructions for implementing peering between virtual networks in different subscriptions and deployment models, see next steps.

View or change peering settings

Before changing a peering, familiarize yourself with the requirements and constraints and necessary permissions.

  1. Select the virtual network that you would like to view or change its peering settings.

    Screenshot of the list of virtual networks in the subscription.

  2. Select Peerings under Settings and then select the peering you want to view or change settings for.

    Screenshot of select a peering to change settings from the virtual network.

  3. Change the appropriate setting. Read about the options for each setting in step 4 of create a peering. Then select Save to complete the configuration changes.

    Screenshot of changing virtual network peering settings.

Delete a peering

Before deleting a peering, familiarize yourself with the requirements and constraints and necessary permissions.

When a peering between two virtual networks is deleted, traffic can no longer flow between the virtual networks. If you want virtual networks to communicate sometimes, but not always, rather than deleting a peering, you can set the Traffic to remote virtual network setting to Block all traffic to the remote virtual network instead. You may find disabling and enabling network access easier than deleting and recreating peerings.

  1. Select the virtual network in the list that you want to delete a peering for.

    Screenshot of selecting a virtual network in the subscription.

  2. Select Peerings under Settings.

    Screenshot of select a peering to delete from the virtual network.

  3. On the right side of the peering you want to delete, select the ... and then select Delete.

    Screenshot of deleting a peering from the virtual network.

  4. Select Yes to confirm that you want to delete the peering and the corresponding peer.

    Screenshot of peering delete confirmation.

    Note

    When you delete a virtual network peering from a virtual network, the peering from the remote virtual network will also be deleted.

Requirements and constraints

  • You can peer virtual networks in the same region, or different regions. Peering virtual networks in different regions is also referred to as Global VNet Peering.

  • When creating a global peering, the peered virtual networks can exist in any Azure public cloud region or China cloud regions or Government cloud regions. You can't peer across clouds. For example, a VNet in Azure public cloud can't be peered to a VNet in Azure China cloud.

  • Resources in one virtual network can't communicate with the front-end IP address of a Basic Load Balancer (internal or public) in a globally peered virtual network. Support for Basic Load Balancer only exists within the same region. Support for Standard Load Balancer exists for both, VNet Peering and Global VNet Peering. Some services that use a Basic load balancer don't work over global virtual network peering. For more information, see Constraints related to Global VNet Peering and Load Balancers.

  • You can use remote gateways or allow gateway transit in globally peered virtual networks and locally peered virtual networks.

  • The virtual networks can be in the same, or different subscriptions. When you peer virtual networks in different subscriptions, both subscriptions can be associated to the same or different Azure Active Directory tenant. If you don't already have an AD tenant, you can create one.

  • The virtual networks you peer must have non-overlapping IP address spaces.

  • You can peer two virtual networks deployed through Resource Manager or a virtual network deployed through Resource Manager with a virtual network deployed through the classic deployment model. You can't peer two virtual networks created through the classic deployment model. If you're not familiar with Azure deployment models, read the Understand Azure deployment models article. You can use a VPN Gateway to connect two virtual networks created through the classic deployment model.

  • When peering two virtual networks created through Resource Manager, a peering must be configured for each virtual network in the peering. You see one of the following types for peering status:

    • Initiated: When you create the first peering, its status is Initiated.
    • Connected: When you create the second peering, peering status becomes Connected for both peerings. The peering isn't successfully established until the peering status for both virtual network peerings is Connected.

  • When peering a virtual network created through Resource Manager with a virtual network created through the classic deployment model, you only configure a peering for the virtual network deployed through Resource Manager. You can't configure peering for a virtual network (classic), or between two virtual networks deployed through the classic deployment model. When you create the peering from the virtual network (Resource Manager) to the virtual network (Classic), the peering status is Updating, then shortly changes to Connected.

  • A peering is established between two virtual networks. Peerings by themselves aren't transitive. If you create peerings between:

    • VirtualNetwork1 and VirtualNetwork2

    • VirtualNetwork2 and VirtualNetwork3

      There's no connectivity between VirtualNetwork1 and VirtualNetwork3 through VirtualNetwork2. If you want VirtualNetwork1 and VirtualNetwork3 to directly communicate, you have to create an explicit peering between VirtualNetwork1 and VirtualNetwork3, or go through an NVA in the Hub network. To learn more, see Hub-spoke network topology in Azure.

  • You can't resolve names in peered virtual networks using default Azure name resolution. To resolve names in other virtual networks, you must use Azure Private DNS or a custom DNS server. To learn how to set up your own DNS server, see Name resolution using your own DNS server.

  • Resources in peered virtual networks in the same region can communicate with each other with the same latency as if they were within the same virtual network. The network throughput is based on the bandwidth that's allowed for the virtual machine, proportionate to its size. There isn't any extra restriction on bandwidth within the peering. Each virtual machine size has its own maximum network bandwidth. To learn more about maximum network bandwidth for different virtual machine sizes, see Sizes for virtual machines in Azure.

  • A virtual network can be peered to another virtual network, and also be connected to another virtual network with an Azure virtual network gateway. When virtual networks are connected through both peering and a gateway, traffic between the virtual networks flows through the peering configuration, rather than the gateway.

  • Point-to-Site VPN clients must be downloaded again after virtual network peering has been successfully configured to ensure the new routes are downloaded to the client.

  • There's a nominal charge for ingress and egress traffic that utilizes a virtual network peering. For more information, see the pricing page.

Permissions

The accounts you use to work with virtual network peering must be assigned to the following roles:

If your account isn't assigned to one of the previous roles, it must be assigned to a custom role that is assigned the necessary actions from the following table:

Action Name
Microsoft.Network/virtualNetworks/virtualNetworkPeerings/write Required to create a peering from virtual network A to virtual network B. Virtual network A must be a virtual network (Resource Manager)
Microsoft.Network/virtualNetworks/peer/action Required to create a peering from virtual network B (Resource Manager) to virtual network A
Microsoft.ClassicNetwork/virtualNetworks/peer/action Required to create a peering from virtual network B (classic) to virtual network A
Microsoft.Network/virtualNetworks/virtualNetworkPeerings/read Read a virtual network peering
Microsoft.Network/virtualNetworks/virtualNetworkPeerings/delete Delete a virtual network peering

Next steps