Configure a VNet-to-VNet connection using PowerShell

This article walks you through the steps to create a connection between VNets in the Resource Manager deployment model by using VPN Gateway. The virtual networks can be in the same or different regions, and from the same or different subscriptions.

v2v diagram

Deployment models and methods for VNet-to-VNet connections

It's important to understand that Azure currently works with two deployment models: Resource Manager and classic. Before beginning your configuration, verify that you are using the instructions for the deployment model that you want to work in. For more information, see Understanding deployment models.

The following table shows the currently available deployment models and methods for VNet-to-VNet configurations. When an article with configuration steps is available, we link directly to it from this table.

Deployment Model/Method Azure Portal Classic Portal PowerShell
Classic Not Supported Article* Supported
Resource Manager Article+ Not Supported Article
Connections between different deployment models Article* Supported* Article

(+) denotes this deployment method is available only for VNets in the same subscription.
(*) denotes that this deployment method also requires PowerShell.

VNet peering

It's also possible to connect VNets without using a VPN gateway. If your VNets are in the same region, you may want to consider connecting them by using VNet peering. For more information, see the VNet peering article.

About VNet-to-VNet connections

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 an Azure VPN gateway to provide a secure tunnel using IPsec/IKE. The VNets you connect can be in different regions. Or in different subscriptions. You can even combine VNet-to-VNet communication with multi-site configurations. This lets you establish network topologies that combine cross-premises connectivity with inter-virtual network connectivity, 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.

VNet-to-VNet considerations

Does Azure charge for traffic between VNets?

VNet-to-VNet traffic within the same region is free for both directions. 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 pricing page for details.

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

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.

Which set of steps should I use?

In this article, you see two different sets of steps. One set of steps for VNets that reside in the same subscription, and another for VNets that reside in different subscriptions. The key difference between the sets is whether you can create and configure all virtual network and gateway resources within the same PowerShell session.

The steps in this article use variables that are declared at the beginning of each section. If you already are working with existing VNets, modify the variables to reflect the settings in your own environment.

Both connections

How to connect VNets that are in the same subscription

v2v diagram

Before you begin

Before beginning, you need to install the Azure Resource Manager PowerShell cmdlets. See How to install and configure Azure PowerShell for more information about installing the PowerShell cmdlets.

Step 1 - Plan your IP address ranges

In the following steps, we create two virtual networks along with their respective gateway subnets and configurations. We then create a VPN connection between the two VNets. It’s important to plan the IP address ranges for your network configuration. Keep in mind that you must make sure that none of your VNet ranges or local network ranges overlap in any way.

We use the following values in the examples:

Values for TestVNet1:

  • VNet Name: TestVNet1
  • Resource Group: TestRG1
  • Location: East US
  • TestVNet1: 10.11.0.0/16 & 10.12.0.0/16
  • FrontEnd: 10.11.0.0/24
  • BackEnd: 10.12.0.0/24
  • GatewaySubnet: 10.12.255.0/27
  • DNS Server: 8.8.8.8
  • GatewayName: VNet1GW
  • Public IP: VNet1GWIP
  • VPNType: RouteBased
  • Connection(1to4): VNet1toVNet4
  • Connection(1to5): VNet1toVNet5
  • ConnectionType: VNet2VNet

Values for TestVNet4:

  • VNet Name: TestVNet4
  • TestVNet2: 10.41.0.0/16 & 10.42.0.0/16
  • FrontEnd: 10.41.0.0/24
  • BackEnd: 10.42.0.0/24
  • GatewaySubnet: 10.42.255.0/27
  • Resource Group: TestRG4
  • Location: West US
  • DNS Server: 8.8.8.8
  • GatewayName: VNet4GW
  • Public IP: VNet4GWIP
  • VPNType: RouteBased
  • Connection: VNet4toVNet1
  • ConnectionType: VNet2VNet

Step 2 - Create and configure TestVNet1

  1. Declare your variables

    Start by declaring variables. This example declares the variables using the values for this exercise. In most cases, you should replace the values with your own. However, you can use these variables if you are running through the steps to become familiar with this type of configuration. Modify the variables if needed, then copy and paste them into your PowerShell console.

     $Sub1 = "Replace_With_Your_Subcription_Name"
     $RG1 = "TestRG1"
     $Location1 = "East US"
     $VNetName1 = "TestVNet1"
     $FESubName1 = "FrontEnd"
     $BESubName1 = "Backend"
     $GWSubName1 = "GatewaySubnet"
     $VNetPrefix11 = "10.11.0.0/16"
     $VNetPrefix12 = "10.12.0.0/16"
     $FESubPrefix1 = "10.11.0.0/24"
     $BESubPrefix1 = "10.12.0.0/24"
     $GWSubPrefix1 = "10.12.255.0/27"
     $DNS1 = "8.8.8.8"
     $GWName1 = "VNet1GW"
     $GWIPName1 = "VNet1GWIP"
     $GWIPconfName1 = "gwipconf1"
     $Connection14 = "VNet1toVNet4"
     $Connection15 = "VNet1toVNet5"
    
  2. Connect to your subscription

    Switch to PowerShell mode to use the Resource Manager cmdlets. Open your PowerShell console and connect to your account. Use the following example to help you connect:

     Login-AzureRmAccount
    

    Check the subscriptions for the account.

     Get-AzureRmSubscription 
    

    Specify the subscription that you want to use.

     Select-AzureRmSubscription -SubscriptionName $Sub1
    
  3. Create a new resource group

     New-AzureRmResourceGroup -Name $RG1 -Location $Location1
    
  4. Create the subnet configurations for TestVNet1

    This example creates a virtual network named TestVNet1 and three subnets, one called GatewaySubnet, one called FrontEnd, and one called Backend. When substituting values, it's important that you always name your gateway subnet specifically GatewaySubnet. If you name it something else, your gateway creation will fail.

    The following example uses the variables that you set earlier. In this example, the gateway subnet is using a /27. While it is possible to create a gateway subnet as small as /29, we recommend that you create a larger subnet that includes more addresses by selecting at least /28 or /27. This will allow for enough addresses to accommodate possible additional configurations that you may want in the future.

     $fesub1 = New-AzureRmVirtualNetworkSubnetConfig -Name $FESubName1 -AddressPrefix $FESubPrefix1
     $besub1 = New-AzureRmVirtualNetworkSubnetConfig -Name $BESubName1 -AddressPrefix $BESubPrefix1
     $gwsub1 = New-AzureRmVirtualNetworkSubnetConfig -Name $GWSubName1 -AddressPrefix $GWSubPrefix1
    
  5. Create TestVNet1

     New-AzureRmVirtualNetwork -Name $VNetName1 -ResourceGroupName $RG1 `
     -Location $Location1 -AddressPrefix $VNetPrefix11,$VNetPrefix12 -Subnet $fesub1,$besub1,$gwsub1
    
  6. Request a public IP address

    Request a public IP address to be allocated to the gateway you will create for your VNet. Notice that the AllocationMethod is Dynamic. You cannot specify the IP address that you want to use. It's dynamically allocated to your gateway.

     $gwpip1 = New-AzureRmPublicIpAddress -Name $GWIPName1 -ResourceGroupName $RG1 `
     -Location $Location1 -AllocationMethod Dynamic
    
  7. Create the gateway configuration

    The gateway configuration defines the subnet and the public IP address to use. Use the example to create your gateway configuration.

     $vnet1 = Get-AzureRmVirtualNetwork -Name $VNetName1 -ResourceGroupName $RG1
     $subnet1 = Get-AzureRmVirtualNetworkSubnetConfig -Name "GatewaySubnet" -VirtualNetwork $vnet1
     $gwipconf1 = New-AzureRmVirtualNetworkGatewayIpConfig -Name $GWIPconfName1 `
     -Subnet $subnet1 -PublicIpAddress $gwpip1
    
  8. Create the gateway for TestVNet1

    In this step, you create the virtual network gateway for your TestVNet1. VNet-to-VNet configurations require a RouteBased VpnType. Creating a gateway can take a while (45 minutes or more to complete).

     New-AzureRmVirtualNetworkGateway -Name $GWName1 -ResourceGroupName $RG1 `
     -Location $Location1 -IpConfigurations $gwipconf1 -GatewayType Vpn `
     -VpnType RouteBased -GatewaySku Standard
    

Step 3 - Create and configure TestVNet4

Once you've configured TestVNet1, create TestVNet4. Follow the steps below, replacing the values with your own when needed. This step can be done within the same PowerShell session because it is in the same subscription.

  1. Declare your variables

    Be sure to replace the values with the ones that you want to use for your configuration.

     $RG4 = "TestRG4"
     $Location4 = "West US"
     $VnetName4 = "TestVNet4"
     $FESubName4 = "FrontEnd"
     $BESubName4 = "Backend"
     $GWSubName4 = "GatewaySubnet"
     $VnetPrefix41 = "10.41.0.0/16"
     $VnetPrefix42 = "10.42.0.0/16"
     $FESubPrefix4 = "10.41.0.0/24"
     $BESubPrefix4 = "10.42.0.0/24"
     $GWSubPrefix4 = "10.42.255.0/27"
     $DNS4 = "8.8.8.8"
     $GWName4 = "VNet4GW"
     $GWIPName4 = "VNet4GWIP"
     $GWIPconfName4 = "gwipconf4"
     $Connection41 = "VNet4toVNet1"
    

    Before you continue, make sure you are still connected to Subscription 1.

  2. Create a new resource group

     New-AzureRmResourceGroup -Name $RG4 -Location $Location4
    
  3. Create the subnet configurations for TestVNet4

     $fesub4 = New-AzureRmVirtualNetworkSubnetConfig -Name $FESubName4 -AddressPrefix $FESubPrefix4
     $besub4 = New-AzureRmVirtualNetworkSubnetConfig -Name $BESubName4 -AddressPrefix $BESubPrefix4
     $gwsub4 = New-AzureRmVirtualNetworkSubnetConfig -Name $GWSubName4 -AddressPrefix $GWSubPrefix4
    
  4. Create TestVNet4

     New-AzureRmVirtualNetwork -Name $VnetName4 -ResourceGroupName $RG4 `
     -Location $Location4 -AddressPrefix $VnetPrefix41,$VnetPrefix42 -Subnet $fesub4,$besub4,$gwsub4
    
  5. Request a public IP address

     $gwpip4 = New-AzureRmPublicIpAddress -Name $GWIPName4 -ResourceGroupName $RG4 `
     -Location $Location4 -AllocationMethod Dynamic
    
  6. Create the gateway configuration

     $vnet4 = Get-AzureRmVirtualNetwork -Name $VnetName4 -ResourceGroupName $RG4
     $subnet4 = Get-AzureRmVirtualNetworkSubnetConfig -Name "GatewaySubnet" -VirtualNetwork $vnet4
     $gwipconf4 = New-AzureRmVirtualNetworkGatewayIpConfig -Name $GWIPconfName4 -Subnet $subnet4 -PublicIpAddress $gwpip4
    
  7. Create the TestVNet4 gateway

     New-AzureRmVirtualNetworkGateway -Name $GWName4 -ResourceGroupName $RG4 `
     -Location $Location4 -IpConfigurations $gwipconf4 -GatewayType Vpn `
     -VpnType RouteBased -GatewaySku Standard
    

Step 4 - Connect the gateways

  1. Get both virtual network gateways

    In this example, because both gateways are in the same subscription, this step can be completed in the same PowerShell session.

     $vnet1gw = Get-AzureRmVirtualNetworkGateway -Name $GWName1 -ResourceGroupName $RG1
     $vnet4gw = Get-AzureRmVirtualNetworkGateway -Name $GWName4 -ResourceGroupName $RG4
    
  2. Create the TestVNet1 to TestVNet4 connection

    In this step, you create the connection from TestVNet1 to TestVNet4. You'll see a shared key referenced in the examples. You can use your own values for the shared key. The important thing is that the shared key must match for both connections. Creating a connection can take a short while to complete.

     New-AzureRmVirtualNetworkGatewayConnection -Name $Connection14 -ResourceGroupName $RG1 `
     -VirtualNetworkGateway1 $vnet1gw -VirtualNetworkGateway2 $vnet4gw -Location $Location1 `
     -ConnectionType Vnet2Vnet -SharedKey 'AzureA1b2C3'
    
  3. Create the TestVNet4 to TestVNet1 connection

    This step is similar to the one above, except you are creating the connection from TestVNet4 to TestVNet1. Make sure the shared keys match.

     New-AzureRmVirtualNetworkGatewayConnection -Name $Connection41 -ResourceGroupName $RG4 `
     -VirtualNetworkGateway1 $vnet4gw -VirtualNetworkGateway2 $vnet1gw -Location $Location4 `
     -ConnectionType Vnet2Vnet -SharedKey 'AzureA1b2C3'
    

    The connection should be established after a few minutes.

  4. Verify your connection. See the section How to verify your connection.

How to connect VNets that are in different subscriptions

v2v diagram

In this scenario, we connect TestVNet1 and TestVNet5. TestVNet1 and TestVNet5 reside in a different subscription. The steps for this configuration add an additional VNet-to-VNet connection in order to connect TestVNet1 to TestVNet5.

The difference here is that some of the configuration steps need to be performed in a separate PowerShell session in the context of the second subscription. Especially when the two subscriptions belong to different organizations.

The instructions continue from the previous steps listed above. You must complete Step 1 and Step 2 to create and configure TestVNet1, and the VPN Gateway for TestVNet1. Once you complete Step 1 and Step 2, continue with Step 5 to create TestVNet5.

Step 5 - Verify the additional IP address ranges

It is important to make sure that the IP address space of the new virtual network, TestVNet5, does not overlap with any of your VNet ranges or local network gateway ranges.

In this example, the virtual networks may belong to different organizations. For this exercise, you can use the following values for the TestVNet5:

Values for TestVNet5:

  • VNet Name: TestVNet5
  • Resource Group: TestRG5
  • Location: Japan East
  • TestVNet5: 10.51.0.0/16 & 10.52.0.0/16
  • FrontEnd: 10.51.0.0/24
  • BackEnd: 10.52.0.0/24
  • GatewaySubnet: 10.52.255.0.0/27
  • DNS Server: 8.8.8.8
  • GatewayName: VNet5GW
  • Public IP: VNet5GWIP
  • VPNType: RouteBased
  • Connection: VNet5toVNet1
  • ConnectionType: VNet2VNet

Additional Values for TestVNet1:

  • Connection: VNet1toVNet5

Step 6 - Create and configure TestVNet5

This step must be done in the context of the new subscription. This part may be performed by the administrator in a different organization that owns the subscription.

  1. Declare your variables

    Be sure to replace the values with the ones that you want to use for your configuration.

     $Sub5 = "Replace_With_the_New_Subcription_Name"
     $RG5 = "TestRG5"
     $Location5 = "Japan East"
     $VnetName5 = "TestVNet5"
     $FESubName5 = "FrontEnd"
     $BESubName5 = "Backend"
     $GWSubName5 = "GatewaySubnet"
     $VnetPrefix51 = "10.51.0.0/16"
     $VnetPrefix52 = "10.52.0.0/16"
     $FESubPrefix5 = "10.51.0.0/24"
     $BESubPrefix5 = "10.52.0.0/24"
     $GWSubPrefix5 = "10.52.255.0/27"
     $DNS5 = "8.8.8.8"
     $GWName5 = "VNet5GW"
     $GWIPName5 = "VNet5GWIP"
     $GWIPconfName5 = "gwipconf5"
     $Connection51 = "VNet5toVNet1"
    
  2. Connect to subscription 5

    Open your PowerShell console and connect to your account. Use the following sample to help you connect:

     Login-AzureRmAccount
    

    Check the subscriptions for the account.

     Get-AzureRmSubscription 
    

    Specify the subscription that you want to use.

     Select-AzureRmSubscription -SubscriptionName $Sub5
    
  3. Create a new resource group

     New-AzureRmResourceGroup -Name $RG5 -Location $Location5
    
  4. Create the subnet configurations for TestVNet4

     $fesub5 = New-AzureRmVirtualNetworkSubnetConfig -Name $FESubName5 -AddressPrefix $FESubPrefix5
     $besub5 = New-AzureRmVirtualNetworkSubnetConfig -Name $BESubName5 -AddressPrefix $BESubPrefix5
     $gwsub5 = New-AzureRmVirtualNetworkSubnetConfig -Name $GWSubName5 -AddressPrefix $GWSubPrefix5
    
  5. Create TestVNet5

     New-AzureRmVirtualNetwork -Name $VnetName5 -ResourceGroupName $RG5 -Location $Location5 `
     -AddressPrefix $VnetPrefix51,$VnetPrefix52 -Subnet $fesub5,$besub5,$gwsub5
    
  6. Request a public IP address

     $gwpip5 = New-AzureRmPublicIpAddress -Name $GWIPName5 -ResourceGroupName $RG5 `
     -Location $Location5 -AllocationMethod Dynamic
    
  7. Create the gateway configuration

     $vnet5 = Get-AzureRmVirtualNetwork -Name $VnetName5 -ResourceGroupName $RG5
     $subnet5  = Get-AzureRmVirtualNetworkSubnetConfig -Name "GatewaySubnet" -VirtualNetwork $vnet5
     $gwipconf5 = New-AzureRmVirtualNetworkGatewayIpConfig -Name $GWIPconfName5 -Subnet $subnet5 -PublicIpAddress $gwpip5
    
  8. Create the TestVNet5 gateway

     New-AzureRmVirtualNetworkGateway -Name $GWName5 -ResourceGroupName $RG5 -Location $Location5 `
     -IpConfigurations $gwipconf5 -GatewayType Vpn -VpnType RouteBased -GatewaySku Standard
    

Step 7 - Connecting the gateways

In this example, because the gateways are in the different subscriptions, we've split this step into two PowerShell sessions marked as [Subscription 1] and [Subscription 5].

  1. [Subscription 1] Get the virtual network gateway for Subscription 1

    Make sure you log in and connect to Subscription 1.

     $vnet1gw = Get-AzureRmVirtualNetworkGateway -Name $GWName1 -ResourceGroupName $RG1
    

    Copy the output of the following elements and send these to the administrator of Subscription 5 via email or another method.

     $vnet1gw.Name
     $vnet1gw.Id
    

    These two elements will have values similar to the following example output:

     PS D:\> $vnet1gw.Name
     VNet1GW
     PS D:\> $vnet1gw.Id
     /subscriptions/b636ca99-6f88-4df4-a7c3-2f8dc4545509/resourceGroupsTestRG1/providers/Microsoft.Network/virtualNetworkGateways/VNet1GW
    
  2. [Subscription 5] Get the virtual network gateway for Subscription 5

    Make sure you log in and connect to Subscription 5.

     $vnet5gw = Get-AzureRmVirtualNetworkGateway -Name $GWName5 -ResourceGroupName $RG5
    

    Copy the output of the following elements and send these to the administrator of Subscription 1 via email or another method.

     $vnet5gw.Name
     $vnet5gw.Id
    

    These two elements will have values similar to the following example output:

     PS C:\> $vnet5gw.Name
     VNet5GW
     PS C:\> $vnet5gw.Id
     /subscriptions/66c8e4f1-ecd6-47ed-9de7-7e530de23994/resourceGroups/TestRG5/providers/Microsoft.Network/virtualNetworkGateways/VNet5GW
    
  3. [Subscription 1] Create the TestVNet1 to TestVNet5 connection

    In this step, you create the connection from TestVNet1 to TestVNet5. The difference here is that $vnet5gw cannot be obtained directly because it is in a different subscription. You will need to create a new PowerShell object with the values communicated from Subscription 1 in the steps above. Use the example below. Replace the Name, Id, and shared key with your own values. The important thing is that the shared key must match for both connections. Creating a connection can take a short while to complete.

    Make sure you connect to Subscription 1.

     $vnet5gw = New-Object Microsoft.Azure.Commands.Network.Models.PSVirtualNetworkGateway
     $vnet5gw.Name = "VNet5GW"
     $vnet5gw.Id   = "/subscriptions/66c8e4f1-ecd6-47ed-9de7-7e530de23994/resourceGroups/TestRG5/providers/Microsoft.Network/virtualNetworkGateways/VNet5GW"
     $Connection15 = "VNet1toVNet5"
     New-AzureRmVirtualNetworkGatewayConnection -Name $Connection15 -ResourceGroupName $RG1 -VirtualNetworkGateway1 $vnet1gw -VirtualNetworkGateway2 $vnet5gw -Location $Location1 -ConnectionType Vnet2Vnet -SharedKey 'AzureA1b2C3'
    
  4. [Subscription 5] Create the TestVNet5 to TestVNet1 connection

    This step is similar to the one above, except you are creating the connection from TestVNet5 to TestVNet1. The same process of creating a PowerShell object based on the values obtained from Subscription 1 applies here as well. In this step, be sure that the shared keys match.

    Make sure you connect to Subscription 5.

     $vnet1gw = New-Object Microsoft.Azure.Commands.Network.Models.PSVirtualNetworkGateway
     $vnet1gw.Name = "VNet1GW"
     $vnet1gw.Id = "/subscriptions/b636ca99-6f88-4df4-a7c3-2f8dc4545509/resourceGroups/TestRG1/providers/Microsoft.Network/virtualNetworkGateways/VNet1GW "
     New-AzureRmVirtualNetworkGatewayConnection -Name $Connection51 -ResourceGroupName $RG5 -VirtualNetworkGateway1 $vnet5gw -VirtualNetworkGateway2 $vnet1gw -Location $Location5 -ConnectionType Vnet2Vnet -SharedKey 'AzureA1b2C3'
    

How to verify a connection

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?

You can verify that your connection succeeded by using the Get-AzureRmVirtualNetworkGatewayConnection cmdlet, with or without -Debug.

  1. Use the following cmdlet example, configuring the values to match your own. If prompted, select 'A' in order to run 'All'. In the example, -Name refers to the name of the connection that you created and want to test.

     Get-AzureRmVirtualNetworkGatewayConnection -Name MyGWConnection -ResourceGroupName MyRG
    
  2. After the cmdlet has finished, view the values. In the example below, the connection status shows as 'Connected' and you can see ingress and egress bytes.

     Body:
     {
       "name": "MyGWConnection",
       "id":
     "/subscriptions/086cfaa0-0d1d-4b1c-94544-f8e3da2a0c7789/resourceGroups/MyRG/providers/Microsoft.Network/connections/MyGWConnection",
       "properties": {
         "provisioningState": "Succeeded",
         "resourceGuid": "1c484f82-23ec-47e2-8cd8-231107450446b",
         "virtualNetworkGateway1": {
           "id":
     "/subscriptions/086cfaa0-0d1d-4b1c-94544-f8e3da2a0c7789/resourceGroups/MyRG/providers/Microsoft.Network/virtualNetworkGa
     teways/vnetgw1"
         },
         "localNetworkGateway2": {
           "id":
     "/subscriptions/086cfaa0-0d1d-4b1c-94544-f8e3da2a0c7789/resourceGroups/MyRG/providers/Microsoft.Network/localNetworkGate
     ways/LocalSite"
         },
         "connectionType": "IPsec",
         "routingWeight": 10,
         "sharedKey": "abc123",
         "connectionStatus": "Connected",
         "ingressBytesTransferred": 33509044,
         "egressBytesTransferred": 4142431
       }
    

Next steps