VNet peering blocks traffic between subnets due to conflicting NSG rules and service endpoints for secure ERP integration

Cloud Platforms Microsoft Azure
, , , , , , , ,
1

We set up VNet peering between our main ERP VNet and a secondary VNet for integration services. After peering configuration, traffic between specific subnets is completely blocked even though peering status shows connected.

Our NSG rules seem to be conflicting with the service endpoint routing. The main issue is that the ERP module connectivity fails when trying to reach the integration service subnet. We’ve verified NSG rule precedence and the peering configuration looks correct on both sides.


# Current peering status
ProvisioningState: Succeeded
PeeringState: Connected
AllowVirtualNetworkAccess: true

The service endpoints are configured on both subnets but traffic still doesn’t flow. Has anyone encountered similar NSG precedence issues with VNet peering?

2

The issue stems from how Azure evaluates traffic when both VNet peering and service endpoints are configured. Let me walk through the complete solution addressing all three areas:

NSG Rule Precedence Fix: Your NSG rules need proper priority ordering. Create explicit allow rules at priority 100-150 for peered VNet traffic:


az network nsg rule create --name AllowPeeredVNet \
  --nsg-name YourNSG --priority 100 \
  --source-address-prefixes 10.1.0.0/16 \
  --destination-address-prefixes 10.2.0.0/16

Service Endpoint Routing Resolution: The conflict occurs because service endpoints modify the routing path. When service endpoints are enabled, traffic to Azure services bypasses VNet peering. You have two options:

  1. Disable service endpoints on subnets that need to communicate via peering
  2. Use Private Endpoints instead, which maintain VNet peering traffic flow

For your ERP integration, I recommend Private Endpoints as they provide better network isolation and work seamlessly with VNet peering.

VNet Peering Configuration: Verify these peering settings on both VNets:

  • AllowForwardedTraffic: true (if using network virtual appliances)
  • UseRemoteGateways: false (unless specifically needed)
  • AllowGatewayTransit: Configure based on your gateway topology

The root cause is typically that service endpoint routes (priority 0) override VNet peering routes. The effective solution is to migrate from service endpoints to Private Endpoints for your Azure PaaS resources, which resolves the routing conflict entirely while maintaining security.

After implementing Private Endpoints, update your NSG rules to allow traffic on the private endpoint subnet (typically 10.x.x.x/28) and remove the service endpoint configuration. This ensures VNet peering traffic flows correctly through the Azure backbone network.

3

Thanks for the suggestions. I checked the effective routes and found that service endpoint routes are indeed taking precedence. The NSG rules show allow for VNet address spaces but they’re at priority 1000. Should I move them higher?

4

One thing that often gets overlooked is the direction of NSG rules. You need matching inbound rules on the destination subnet NSG and outbound rules on the source subnet NSG. I’ve seen situations where only one direction was configured properly. Check both NSGs associated with your subnets and ensure bidirectional rules exist for the VNet address spaces.