Create a virtual network peering using Azure PowerShell

VNet Peering is a mechanism to connect two Virtual Networks in the same region through the Azure backbone network. Once peered, the two Virtual Networks will appear like a single Virtual Network for all connectivity purposes. Read the VNet Peering overview if you are not familiar with VNet Peering.

Peering VNets in the same subscription

In this scenario you will create a peering between two VNets named VNet1 and VNet2 belonging to the same subscription.

Basic scenario

VNet peering will allow full connectivity between the entire address space of peered virtual networks.

To create a VNet peering by using PowerShell, please follow the steps below:

  1. If you have never used Azure PowerShell, see How to Install and Configure Azure PowerShell and follow the instructions all the way to the end to sign into Azure and select your subscription.

    Note

    The PowerShell cmdlet for managing VNet peering is shipped with Azure PowerShell 1.6.

  2. Read virtual network objects:

     $vnet1 = Get-AzureRmVirtualNetwork -ResourceGroupName vnet101 -Name vnet1
     $vnet2 = Get-AzureRmVirtualNetwork -ResourceGroupName vnet101 -Name vnet2
    
  3. To establish VNet peering, you need to create two links, one for each direction. The following step will create a VNet peering link for VNet1 to VNet2 first:

     Add-AzureRmVirtualNetworkPeering -Name LinkToVNet2 -VirtualNetwork $vnet1 -RemoteVirtualNetworkId $vnet2.Id
    

    Returned output:

     Name            : LinkToVNet2
     Id: /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/vnet101/providers/Microsoft.Network/virtualNetworks/vnet1/virtualNetworkPeerings/LinkToVNet2
     Etag            : W/"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
     ResourceGroupName    : vnet101
     VirtualNetworkName    : vnet1
     PeeringState        : Initiated
     ProvisioningState    : Succeeded
     RemoteVirtualNetwork    : {
     "Id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/vnet101/providers/Microsoft.Network/virtualNetworks/vnet2"
                                     }
     AllowVirtualNetworkAccess    : True
     AllowForwardedTraffic    : False
     AllowGatewayTransit    : False
         UseRemoteGateways    : False
         RemoteGateways        : null
         RemoteVirtualNetworkAddressSpace : null
    
  4. This step will create a VNet peering link for VNet2 to VNet1:

     Add-AzureRmVirtualNetworkPeering -Name LinkToVNet1 -VirtualNetwork $vnet2 -RemoteVirtualNetworkId $vnet1.Id
    

    Returned output:

     Name            : LinkToVNet1
     Id                : /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/vnet101/providers/Microsoft.Network/virtualNetworks/vnet2/virtualNetworkPeerings/LinkToVNet1
     Etag            : W/"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
     ResourceGroupName    : vnet101
     VirtualNetworkName    : vnet2
     PeeringState        : Connected
     ProvisioningState    : Succeeded
     RemoteVirtualNetwork    : {
                                         "Id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/vnet101/providers/Microsoft.Network/virtualNetworks/vnet1"
                                     }
     AllowVirtualNetworkAccess    : True
     AllowForwardedTraffic    : False
     AllowGatewayTransit    : False
     UseRemoteGateways    : False
     RemoteGateways        : null
     RemoteVirtualNetworkAddressSpace : null
    
  5. Once the VNet peering link is created, enter the following command to view the link state:

     Get-AzureRmVirtualNetworkPeering -VirtualNetworkName vnet1 -ResourceGroupName vnet101 -Name linktovnet2
    

    Returned output:

     Name            : LinkToVNet2
     Id                : /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/vnet101/providers/Microsoft.Network/virtualNetworks/vnet1/virtualNetworkPeerings/LinkToVNet2
     Etag            : W/"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
     ResourceGroupName    : vnet101
     VirtualNetworkName    : vnet1
     PeeringState        : Connected
     ProvisioningState    : Succeeded
     RemoteVirtualNetwork    : {
                                          "Id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/vnet101/providers/Microsoft.Network/virtualNetworks/vnet2"
                                     }
     AllowVirtualNetworkAccess    : True
     AllowForwardedTraffic            : False
     AllowGatewayTransit              : False
     UseRemoteGateways                : False
     RemoteGateways                   : null
     RemoteVirtualNetworkAddressSpace : null
    

    There are a few configurable properties for VNet peering:

    Option Description Default
    AllowVirtualNetworkAccess Whether address space of Peer VNet to be included as part of the Virtual_network Tag Yes
    AllowForwardedTraffic Whether traffic not originating from a peered VNet is accepted or dropped No
    AllowGatewayTransit Allows the peer VNet to use your VNet gateway No
    UseRemoteGateways Use your peer’s VNet gateway. The peer VNet must have a gateway configured and AllowGatewayTransit selected. You cannot use this option if you have a gateway configured No

    Each link in a VNet peering has the previous set of properties. For example, you can set AllowVirtualNetworkAccess to True for VNet peering link VNet1 to VNet2 and set it to False for the VNet peering link in the other direction.

     $LinktoVNet2 = Get-AzureRmVirtualNetworkPeering -VirtualNetworkName vnet1 `
     -ResourceGroupName vnet101 -Name LinkToVNet2
    
     $LinktoVNet2.AllowForwardedTraffic = $true
     Set-AzureRmVirtualNetworkPeering -VirtualNetworkPeering $LinktoVNet2
    

    You can run Get-AzureRmVirtualNetworkPeering to double check the property value after the change. From the output, you can see AllowForwardedTraffic changes set to True after running the previous cmdlets.

     Name            : LinkToVNet2
     Id            : /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/vnet101/providers/Microsoft.Network/virtualNetworks/vnet1/virtualNetworkPeerings/LinkToVNet2
     Etag            : W/"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
     ResourceGroupName    : vnet101
     VirtualNetworkName    : vnet1
     PeeringState        : Connected
     ProvisioningState    : Succeeded
     RemoteVirtualNetwork    : {
                                         "Id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/vnet101/providers/Microsoft.Network/virtualNetworks/vnet2"
                                     }
     AllowVirtualNetworkAccess    : True
     AllowForwardedTraffic        : True
     AllowGatewayTransit        : False
     UseRemoteGateways        : False
     RemoteGateways        : null
     RemoteVirtualNetworkAddressSpace : null
    

    After peering is established, VMs should be able to communicate with each other across both VNets. By default, AllowVirtualNetworkAccess is True and VNet peering will provision the proper ACLs to allow the communication between VNets. You can still apply network security group (NSG) rules to block connectivity between specific subnets or virtual machines to gain fine grain control of access between two VNets. Read the network security group article to learn more about NSGs.

Peering across subscriptions

In this scenario you will create a peering between two VNets that exist in different subscriptions.

cross sub scenario

VNet peering relies on role-based access control (RBAC) for authorization. For cross-subscriptions scenario, you first need to grant sufficient permission to users who will create the peering link.

Note

If the same user has the privilege over both subscriptions, then you can skip steps 1-4 that follow.

To create VNet peering across subscriptions using PowerShell, complete the following steps:

  1. Sign in to Azure with privileged User-A's account for Subscription-A and run the following cmdlet:

     New-AzureRmRoleAssignment -SignInName <UserB ID> -RoleDefinitionName "Network Contributor" -Scope /subscriptions/<Subscription-A-ID>/resourceGroups/<ResourceGroupName>/providers/Microsoft.Network/VirtualNetworks/VNet5
    

    This is not a requirement. Peering can be established even if users individually raise peering requests for their respective VNets, as long as the requests match. Adding a privileged user of the other VNet as a user in the local VNet makes it easier to do the setup.

  2. Sign in to Azure with privileged User-B's account for Subscription-B and run the following cmdlet:

     New-AzureRmRoleAssignment -SignInName <UserA ID> -RoleDefinitionName "Network Contributor" -Scope /subscriptions/<Subscription-B-ID>/resourceGroups/<ResourceGroupName>/providers/Microsoft.Network/VirtualNetworks/VNet3
    
    Important

    If the peering you're creating is between two VNets created through the Azure Resource Manager deployment model, continue with the remaining steps in this section. If the two VNets were created through different deployment models, skip the remaining steps of this section and complete the steps in the Peering virtual networks created through different deployment models section of this article.

  3. In User-A’s login session, run the following command:

     $vnet3 = Get-AzureRmVirtualNetwork -ResourceGroupName hr-vnets -Name vnet3
    
     Add-AzureRmVirtualNetworkPeering -Name LinkToVNet5 -VirtualNetwork $vnet3 -RemoteVirtualNetworkId "/subscriptions/<Subscription-B-Id>/resourceGroups/<ResourceGroupName>/providers/Microsoft.Network/virtualNetworks/VNet5" -BlockVirtualNetworkAccess
    
  4. In User-B’s login session, run the cmdlet below:

     $vnet5 = Get-AzureRmVirtualNetwork -ResourceGroupName vendor-vnets -Name vnet5
    
     Add-AzureRmVirtualNetworkPeering -Name LinkToVNet3 -VirtualNetwork $vnet5 -RemoteVirtualNetworkId "/subscriptions/<Subscriptoin-A-Id>/resourceGroups/<ResourceGroupName>/providers/Microsoft.Network/virtualNetworks/VNet3" -BlockVirtualNetworkAccess
    
  5. After peering is established, any VM in VNet3 should be able to communicate with any VM in VNet5.

Service Chaining - Transit through peered VNet

Although the use of system routes facilitates traffic automatically for your deployment, there are cases in which you want to control the routing of packets through a virtual appliance. In this scenario, there are two VNets in a subscription, HubVNet and VNet1 as described in the diagram below. You deploy Network Virtual Appliance(NVA) in VNet HubVNet. After establishing VNet peering between HubVNet and VNet1, you can set up User Defined Routes and specify the next hop to NVA in the HubVNet.

NVA Transit

Note

For the simplicity, assume all VNets here are in the same subscription. But it also works for cross-subscription scenario.

The key property to enable Transit routing is the "Allow Forwarded Traffic" parameter. This allows accepting and sending traffic from/to the NVA in the peered VNet.

  1. In this scenario, run the following PowerShell cmdlets to establish the VNet peering. You need to set the AllowForwardedTraffic property to True and link VNET1 to HubVNet, which allows the inbound traffic from outside of the peering VNet address space.

     $hubVNet = Get-AzureRmVirtualNetwork -ResourceGroupName vnet101 -Name HubVNet
     $vnet1 = Get-AzureRmVirtualNetwork -ResourceGroupName vnet101 -Name vnet1
    
     Add-AzureRmVirtualNetworkPeering -Name LinkToHub -VirtualNetwork $vnet1 -RemoteVirtualNetworkId $HubVNet.Id -AllowForwardedTraffic
    
     Add-AzureRmVirtualNetworkPeering -Name LinkToVNet1 -VirtualNetwork $HubVNet -RemoteVirtualNetworkId $vnet1.Id
    
  2. After peering is established, you can refer to this article and define a user-defined route (UDR) to redirect VNet1 traffic through a virtual appliance to use its capabilities. When you specify the next hop address in the route, you can set it to the IP address of the virtual appliance in the peer VNet HubVNet. The following is a sample:

     $route = New-AzureRmRouteConfig -Name TestNVA -AddressPrefix 10.3.0.0/16 -NextHopType VirtualAppliance -NextHopIpAddress 192.0.1.5
    
     $routeTable = New-AzureRmRouteTable -ResourceGroupName VNet101 -Location brazilsouth -Name TestRT -Route $route
    
     $vnet1 = Get-AzureRmVirtualNetwork -ResourceGroupName VNet101 -Name VNet1
    
     Set-AzureRmVirtualNetworkSubnetConfig -VirtualNetwork $vnet1 -Name subnet-1 -AddressPrefix 10.1.1.0/24 -RouteTable $routeTable
    
     Set-AzureRmVirtualNetwork -VirtualNetwork $vnet1
    

Peering virtual networks created through different deployment models

In this scenario, you will create a peering between two VNets named VNET1 and VNET2. VNET1 is created through the Resource Manager deployment model, while VNET2 is created through the classic deployment model.

asm to arm deployment scenario

  1. If you are creating a peering between VNets deployed through different deployment models in the same subscription, skip to step 2. The ability to create a VNet peering between VNets deployed through different deployment models in different subscriptions is in preview release. Capabilities in preview release do not have the same level of reliability and service level agreement as general release capabilities. If you are creating a peering between VNets deployed through different deployment models in different subscriptions you must first complete the following tasks:
    • Register the preview capability in your Azure subscription by entering the following commands from PowerShell: Register-AzureRmProviderFeature -FeatureName AllowClassicCrossSubscriptionPeering -ProviderNamespace Microsoft.Network and Register-AzureRmResourceProvider -ProviderNamespace Microsoft.Network
    • Complete steps 1-2 in the Peering across subscriptions section of this article.
  2. Read the virtual network object for VNET1, the Azure Resource Manager virtual network, by entering the following command:

     $vnet1 = Get-AzureRmVirtualNetwork -ResourceGroupName vnet101 -Name vnet1
    
  3. To establish VNet peering in this scenario, only one link is needed, specifically a link from VNET1 to VNET2. This step requires knowing your classic VNet's resource ID. The resource group ID format looks like the following example:

     subscriptions/{SubscriptionID}/resourceGroups/{ResourceGroupName}/providers/Microsoft.ClassicNetwork/virtualNetworks/{VirtualNetworkName}
    

    Be sure to replace SubscriptionID, ResourceGroupName, and VirtualNetworkName with the appropriate names.

    This can be accomplished by entering the following command:

     Add-AzureRmVirtualNetworkPeering -Name LinkToVNet2 -VirtualNetwork $vnet1 -RemoteVirtualNetworkId /subscriptions/xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx/resourceGroups/MyResourceGroup/providers/Microsoft.ClassicNetwork/virtualNetworks/VNET2
    
  4. Once the VNet peering link is created, you can see the link state, as shown in the following output:

     Name                             : LinkToVNet2
     Id                               : /subscriptions/xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx/resourceGroups/MyResourceGroup/providers/Microsoft.Network/virtualNetworks/VNET1/virtualNetworkPeerings/LinkToVNet2
     Etag                             : W/"acecbd0f-766c-46be-aa7e-d03e41c46b16"
     ResourceGroupName                : MyResourceGroup
     VirtualNetworkName               : VNET1
     PeeringState                     : Connected
     ProvisioningState                : Succeeded
     RemoteVirtualNetwork             : {
                                      "Id": "/subscriptions/xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx/resourceGroups/MyResourceGroup/providers/Microsoft.ClassicNetwork/virtualNetworks/VNET2"
                                    }
     AllowVirtualNetworkAccess        : True
     AllowForwardedTraffic            : False
     AllowGatewayTransit              : False
     UseRemoteGateways                : False
     RemoteGateways                   : null
     RemoteVirtualNetworkAddressSpace : null
    

Remove a VNet peering

  1. In order to remove a VNet peering, you need to run the following cmdlet:

     Remove-AzureRmVirtualNetworkPeering
    

    To remove both links, enter the following commands:

     Remove-AzureRmVirtualNetworkPeering -ResourceGroupName vnet101 -VirtualNetworkName vnet1 -Name linktovnet2
     Remove-AzureRmVirtualNetworkPeering -ResourceGroupName vnet101 -VirtualNetworkName vnet1 -Name linktovnet2
    
  2. Once you remove one link in a VNET peering, the peer link state will go to Disconnected. In this state, you cannot re-create the link until the peer link state changes to Initiated. We recommend you remove both links before you re-create the VNet peering.