Skip to content

VNET peer is not connected#

Operational Excellence · Virtual Network · Rule · 2020_06 · Important

VNET peering connections must be connected.

Description#

When peering virtual networks, a peering connection must be established from both virtual networks. Only once both peering connections are in the Connected state will traffic be allowed to flow between the virtual networks.

Connections in the Initiated or Disconnected state should be investigated to determine if the connection is required. When the connection is no longer required, it should be removed to prevent confusion during management and monitoring operations.

Most customers will use a hub and spoke topology to connect virtual networks. For guidance on defining your network topology in Azure see Cloud Adoption Framework (CAF).

Recommendation#

Consider removing peering connections that are not longer required or complete peering connections.

Examples#

Configure with Azure template#

To deploy virtual networks that pass this rule:

  • Create a peering connection from the spoke to the hub. AND
  • Create a peering connection from the hub to the spoke.

For example a peering connection from a spoke to a hub:

Azure Template snippet
{
  "type": "Microsoft.Network/virtualNetworks/virtualNetworkPeerings",
  "apiVersion": "2023-05-01",
  "name": "[format('{0}/{1}', parameters('spokeName'), format('peer-to-{0}', parameters('hubName')))]",
  "properties": {
    "remoteVirtualNetwork": {
      "id": "[resourceId('Microsoft.Network/virtualNetworks', parameters('hubName'))]"
    },
    "allowVirtualNetworkAccess": true,
    "allowForwardedTraffic": true,
    "allowGatewayTransit": false,
    "useRemoteGateways": true
  }
}

For example a peering connection from a hub to a spoke:

Azure Template snippet
{
  "type": "Microsoft.Network/virtualNetworks/virtualNetworkPeerings",
  "apiVersion": "2023-05-01",
  "name": "[format('{0}/{1}', parameters('hubName'), format('peer-to-{0}', parameters('spokeName')))]",
  "properties": {
    "remoteVirtualNetwork": {
      "id": "[resourceId('Microsoft.Network/virtualNetworks', parameters('spokeName'))]"
    },
    "allowVirtualNetworkAccess": true,
    "allowForwardedTraffic": false,
    "allowGatewayTransit": true,
    "useRemoteGateways": false
  }
}

Configure with Bicep#

To deploy virtual networks that pass this rule:

  • Create a peering connection from the spoke to the hub. AND
  • Create a peering connection from the hub to the spoke.

For example a peering connection from a spoke to a hub:

Azure Bicep snippet
resource toHub 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2023-05-01' = {
  parent: spoke
  name: 'peer-to-${hub.name}'
  properties: {
    remoteVirtualNetwork: {
      id: hub.id
    }
    allowVirtualNetworkAccess: true
    allowForwardedTraffic: true
    allowGatewayTransit: false
    useRemoteGateways: true
  }
}

For example a peering connection from a hub to a spoke:

Azure Bicep snippet
resource toSpoke 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2023-05-01' = {
  parent: hub
  name: 'peer-to-${spoke.name}'
  properties: {
    remoteVirtualNetwork: {
      id: spoke.id
    }
    allowVirtualNetworkAccess: true
    allowForwardedTraffic: false
    allowGatewayTransit: true
    useRemoteGateways: false
  }
}

Notes#

This rule applies when analyzing resources deployed to Azure (in-flight).

Comments