VNet Peering Security Considerations

VNet peering is a networking feature that connects two Azure virtual networks (VNets) directly, enabling private IP address space communication between resources in different VNets. Traffic flows over the Microsoft backbone network, never traversing the public internet. This provides low latency, high bandwidth, and a secure connection. VNet peering is non-transitive by default, meaning if VNet A is peered with VNet B, and VNet B is peered with VNet C, VNet A cannot communicate with VNet C unless explicitly configured via a hub-and-spoke topology with gateway transit or additional peerings.

When you create a peering, Azure establishes a connection between the two VNets at the Azure networking layer. The peering is bidirectional, requiring two peering objects: one from VNet A to VNet B, and one from VNet B to VNet A. Once established, resources in both VNets can communicate using private IP addresses as if they were on the same network. The routing is handled by Azure's system routes, which add a route for the peered VNet's address space to each VNet's route table. No gateways are required for the peering itself; however, if you want to use a VPN gateway in one VNet to connect to on-premises (gateway transit), that requires additional configuration.

1. Network Security Groups (NSGs): NSGs are fully supported across VNet peering. By default, NSGs in each VNet apply to traffic coming from the peered VNet. You can create rules to allow or deny specific traffic. Remember that NSGs are stateful: if you allow inbound traffic from the peered VNet, the return traffic is automatically allowed regardless of outbound rules.

2. Azure Firewall: Can be deployed in a hub VNet and used to inspect traffic between spokes. You must configure UDRs in each spoke to send traffic to the Azure Firewall's private IP. The peering must have 'Allow Forwarded Traffic' enabled on the hub side.

3. Private Link and Private Endpoints: These do not require VNet peering; they work across peered VNets as long as DNS resolution is configured correctly. However, peering can simplify connectivity.

4. Data Encryption: Traffic between peered VNets is private but not encrypted by default. For sensitive data, use application-level encryption (e.g., TLS) or deploy a VPN gateway in one VNet and use site-to-site VPN over the peering (though this adds complexity).

5. Gateway Transit Security: When using gateway transit, the spoke VNet's traffic to on-premises traverses the hub's gateway. The hub's NSGs and firewall rules apply. Ensure the hub is secured appropriately.

6. Peering Across Regions (Global VNet Peering): Global peering works across Azure regions. However, there are additional considerations: data may traverse the Azure backbone across regions, but it never leaves the Microsoft network. There is no charge for ingress/egress across regions, but there is a data transfer cost. Some services (like Basic internal load balancers) do not support global peering.

7. Subscription and Tenant Scoping: VNet peering can be between VNets in different subscriptions within the same Azure AD tenant. Cross-tenant peering is also possible, but requires consent from both tenants. Security implications: each subscription's administrator controls their own side of the peering. A misconfiguration in one subscription can affect the other.

8. Non-Transitivity: This is a key security feature. If VNet A is peered with VNet B, and VNet B is peered with VNet C, VNet A cannot talk to VNet C unless additional peerings or gateway transit is configured. This prevents unintended access.

9. Address Space Overlap: Peering requires non-overlapping address spaces. If there is overlap, the peering fails. Overlap can lead to routing issues and security holes if not caught early.

10. Traffic Monitoring and Logging: Use NSG flow logs, Traffic Analytics, or Network Watcher to monitor traffic between peered VNets. This helps detect anomalous patterns.

To create a peering, you can use Azure Portal, Azure CLI, or PowerShell. Example CLI:

# Create peering from VNet1 to VNet2
az network vnet peering create \
  --name VNet1-To-VNet2 \
  --resource-group RG1 \
  --vnet-name VNet1 \
  --remote-vnet /subscriptions/.../resourceGroups/RG2/providers/Microsoft.Network/virtualNetworks/VNet2 \
  --allow-vnet-access true \
  --allow-forwarded-traffic false \
  --allow-gateway-transit false

# Create peering from VNet2 to VNet1
az network vnet peering create \
  --name VNet2-To-VNet1 \
  --resource-group RG2 \
  --vnet-name VNet2 \
  --remote-vnet /subscriptions/.../resourceGroups/RG1/providers/Microsoft.Network/virtualNetworks/VNet1 \
  --allow-vnet-access true \
  --allow-forwarded-traffic false \
  --use-remote-gateways false

To verify peering state:

az network vnet peering list --resource-group RG1 --vnet-name VNet1 --output table

A multinational corporation deploys a hub-and-spoke topology across multiple Azure regions. The hub VNet contains shared services like Azure Firewall, Active Directory Domain Controllers, and a VPN gateway for on-premises connectivity. Each spoke VNet hosts application tiers (web, app, data) in different subscriptions. VNet peering connects each spoke to the hub. To enforce security, the hub's Azure Firewall inspects all traffic between spokes and to on-premises. UDRs in each spoke route all traffic (0.0.0.0/0) to the firewall's private IP. The hub VNet peering has 'Allow forwarded traffic' enabled to accept traffic from spokes destined elsewhere. The spokes do not have direct peerings between each other, preventing lateral movement. This design centralizes security policy management and reduces the attack surface. Common issues: misconfigured UDRs that bypass the firewall, or enabling 'Allow forwarded traffic' on the spoke side, which could allow unintended forwarding.

A SaaS provider runs a multi-tier application with web servers in East US and database servers in West US for disaster recovery. They use global VNet peering to connect the two VNets. NSGs on the database subnet only allow inbound traffic from the web subnet's IP range over port 1433. The peering is configured with 'Allow virtual network access' enabled, but 'Allow forwarded traffic' disabled because no NVAs are used. The application uses TLS for encryption between tiers. Performance is critical: global peering adds ~60ms latency, which is acceptable for database queries. The challenge is ensuring that DNS resolution works across regions; they use Azure Private DNS zones linked to both VNets. Misconfiguration: if the database VNet's NSG accidentally allows all inbound traffic, the database could be exposed.

After an acquisition, Company A needs to connect its Azure VNet to Company B's VNet, which resides in a different Azure AD tenant. They use cross-tenant VNet peering. Company A's administrator initiates the peering from their subscription, and Company B's administrator accepts it from their side. To maintain security, both sides apply restrictive NSGs. They also set up Azure Policy to deny any peering that allows forwarded traffic or gateway transit. This ensures that the peering is used only for direct resource communication, not for routing traffic to third parties. Common pitfalls: one side may accidentally enable 'Allow forwarded traffic', creating a backdoor. Regular audits are essential.

In production, a single VNet can have up to 500 peerings. For large-scale hub-and-spoke designs with hundreds of spokes, consider using Virtual WAN instead, which simplifies routing and security. Bandwidth is not a limitation of peering itself, but VM sizes and NICs determine throughput. For high-throughput scenarios, use accelerated networking on VMs. Global peering charges apply for data transfer (ingress/egress), which can be significant for large volumes. Always monitor costs.