VNet Has Peering Connection: Reviewing Azure Network Peerings

Virtual network peering is one of those features that quietly accumulates over time. Someone connects two VNets to share a database, a team peers a hub to a new spoke, a partner subscription gets wired in for a short project, and three years later nobody remembers why half of them exist. This Lensix check exists to surface those connections so you can answer a simple question for each one: should this still be here?

The check itself is not declaring a peering "bad." It is telling you that a trust relationship exists between networks, and trust relationships deserve periodic human review.

---

What this check detects

The network_unknownpeering check inspects your Azure Virtual Networks and reports any that have an active peering connection. A peering links two VNets together so resources in each can communicate using private IP addresses, as if they were on the same network.

Azure supports two kinds:

• Regional VNet peering connects VNets in the same Azure region.
• Global VNet peering connects VNets across different regions, and even across subscriptions and tenants.

When the check fires, it is pointing at a specific peering on a specific VNet and asking you to confirm it is intentional and correctly scoped. This is a review check, not a hard failure, which makes it valuable for catching drift that strict pass/fail rules tend to miss.

---

Why it matters

A peering connection is a direct, private, low-latency path between two networks. That is exactly what you want when you build it on purpose, and exactly what an attacker wants when they land in one of those networks.

Lateral movement

If an attacker compromises a workload in a peered spoke, the peering gives them a private route toward whatever lives on the other side. Network Security Groups still apply, but plenty of internal traffic is left wide open because "it's all internal anyway." A forgotten peering to a legacy subscription can turn a contained incident into a multi-environment breach.

Cross-subscription and cross-tenant exposure

Global peering can connect VNets that belong to different subscriptions or even different Azure AD tenants. A peering to a partner, contractor, or acquired company's tenant means their security posture is now part of yours. If their environment is breached, your private network is reachable.

Data exfiltration paths

Peering combined with features like allowGatewayTransit and useRemoteGateways can route traffic through a remote VNet's gateway. A misconfigured peering can hand an unexpected path to on-premises networks or to the internet via a remote NVA, bypassing the egress controls you thought were in place.

Compliance scope creep

If a peering connects a non-regulated environment to one carrying cardholder or health data, you may have just dragged the non-regulated environment into PCI or HIPAA scope. Auditors care about network reachability, not org charts.

---

How to fix it

"Fixing" this check means reviewing the peering and then either confirming it as intended or removing it. Start by gathering the facts.

1. Inventory your peerings

List every peering on a given VNet:

az network vnet peering list \
  --resource-group my-rg \
  --vnet-name my-vnet \
  --output table

To inspect a single peering in detail, including which remote VNet it points to and what traffic settings are enabled:

az network vnet peering show \
  --resource-group my-rg \
  --vnet-name my-vnet \
  --name peering-to-hub \
  --query "{state:peeringState, remote:remoteVirtualNetwork.id, forwardedTraffic:allowForwardedTraffic, gatewayTransit:allowGatewayTransit, remoteGateways:useRemoteGateways}" \
  --output jsonc

To sweep every VNet in a subscription at once:

az network vnet list --query "[].{rg:resourceGroup, vnet:name}" -o tsv | \
while read rg vnet; do
  az network vnet peering list --resource-group "$rg" --vnet-name "$vnet" \
    --query "[].{vnet:'$vnet', peering:name, state:peeringState, remote:remoteVirtualNetwork.id}" -o table
done

The remote VNet ID includes the subscription ID. If that subscription is not one you recognize, you have found a cross-subscription or cross-tenant peering worth investigating immediately.

2. Decide: keep, restrict, or remove

For each peering, answer three questions: Do I know why it exists? Is the remote VNet trusted? Are the traffic settings tighter than the defaults? If you cannot answer the first two confidently, lean toward removal.

3. Tighten settings instead of deleting (when the peering is legitimate)

If the peering is needed but too permissive, reduce what it allows. For example, disable forwarded traffic if this VNet should not act as a transit point:

az network vnet peering update \
  --resource-group my-rg \
  --vnet-name my-vnet \
  --name peering-to-hub \
  --set allowForwardedTraffic=false

Remember to review the peering from both directions. Peerings are configured as a pair, and the settings on each side are independent.

4. Remove an unwanted peering

az network vnet peering delete \
  --resource-group my-rg \
  --vnet-name my-vnet \
  --name peering-to-legacy

Delete the matching peering on the remote VNet as well, otherwise it lingers in a disconnected state:

az network vnet peering delete \
  --resource-group remote-rg \
  --vnet-name remote-vnet \
  --name peering-to-mine

---

How to prevent it from happening again

Manual review catches problems once. Automation keeps them from coming back. The goal is to make every new peering a deliberate, reviewed, documented decision.

Manage peerings as code

Define peerings in Terraform or Bicep so every connection is visible in version control and goes through pull request review. A Terraform example:

resource "azurerm_virtual_network_peering" "hub_to_spoke" {
  name                         = "hub-to-spoke"
  resource_group_name          = azurerm_resource_group.net.name
  virtual_network_name         = azurerm_virtual_network.hub.name
  remote_virtual_network_id    = azurerm_virtual_network.spoke.id
  allow_virtual_network_access = true
  allow_forwarded_traffic      = false
  allow_gateway_transit        = true
  use_remote_gateways          = false
}

Gate peerings with Azure Policy

Use Azure Policy to deny peerings to remote VNets outside an approved set of subscriptions. The policy below denies any peering whose remote VNet is not in an allowed subscription list:

{
  "if": {
    "allOf": [
      {
        "field": "type",
        "equals": "Microsoft.Network/virtualNetworks/virtualNetworkPeerings"
      },
      {
        "not": {
          "field": "Microsoft.Network/virtualNetworks/virtualNetworkPeerings/remoteVirtualNetwork.id",
          "contains": "[parameters('allowedSubscriptionId')]"
        }
      }
    ]
  },
  "then": {
    "effect": "deny"
  }
}

Assign this at the management group level so it applies across every subscription, including new ones created later.

Continuous monitoring

Let Lensix run network_unknownpeering on a schedule so any new peering surfaces for review automatically. Pair it with a review cadence: a peering that has been flagged and acknowledged once should re-flag if its configuration changes, so you catch the case where someone quietly flips allowForwardedTraffic back on.

---

Best practices

• Use a hub-and-spoke topology deliberately. Centralize shared services and egress in a hub, peer spokes only to the hub, and avoid spoke-to-spoke peerings unless there is a clear reason. This keeps the peering graph readable.
• Tag and document every peering. Record the owner, the reason, and an expiry date. A peering with no owner is a peering that will eventually be deleted by mistake or kept by mistake, both bad outcomes.
• Default to least permissive traffic settings. Leave allowForwardedTraffic, allowGatewayTransit, and useRemoteGateways off unless a specific design requires them.
• Layer NSGs on top of peering. Peering controls reachability between VNets, but NSGs control reachability between subnets and workloads. Do not treat a peering boundary as a security boundary on its own.
• Review cross-subscription and cross-tenant peerings quarterly. These carry the most risk and change ownership most often.
• Set expiry reminders for temporary peerings. If a peering is created for a project, schedule its removal when you create it, not after.

Peering is a powerful tool that makes private connectivity simple, and that simplicity is precisely why it deserves scrutiny. Every active peering is a standing answer to the question "who can reach this network." Make sure the answer is one you chose on purpose.