Troubleshoot virtual network peering issues
This troubleshooting guide provides steps to help you resolve most virtual network peering issues.
Configure virtual network peering between two virtual networks
Are the virtual networks in the same subscription or in different subscriptions?
The virtual networks are in the same subscription
To configure virtual network peering for the virtual networks that are in the same subscription, use the methods in the following articles:
- If the virtual networks are in the same region, see Create a peering.
- If the virtual networks are in the different regions, see Virtual network peering.
Note
Connectivity doesn't work over global virtual network peering for the following resources:
- Virtual machines (VMs) behind Basic internal load balancer (ILB) SKU
- Redis cache (uses Basic ILB SKU)
- Application gateway v1 (uses Basic ILB SKU)
- Virtual machine scale sets (uses Basic ILB SKU)
- Azure Service Fabric clusters (uses Basic ILB SKU)
- SQL Server Always On (uses Basic ILB SKU)
- Azure App Service Environment for Power Apps (uses Basic ILB SKU)
- Azure API Management (uses Basic ILB SKU)
- Microsoft Entra Domain Services (uses Basic ILB SKU)
For more information, see the requirements and constraints of global peering.
The virtual networks are in different subscriptions or Active Directory tenants
To configure virtual network peering for virtual networks in different subscriptions or Active Directory tenants, see Create a virtual network peering between different subscriptions.
Note
To configure network peering, you must have Network Contributor permissions in both subscriptions. For more information, see Peering permissions.
Configure virtual network peering with hub-spoke topology that uses on-premises resources
For a site-to-site connection or an ExpressRoute connection
Follow the steps in: Configure VPN gateway transit for virtual network peering.
For point-to-site connections
- Follow the steps in: Configure VPN gateway transit for virtual network peering.
- After virtual network peering is established or changed, download and reinstall the point-to-site package so that the point-to-site clients get the updated routes to the spoke virtual network.
Configure virtual network peering with hub-spoke topology virtual network
The virtual networks are in the same region
- In the hub virtual network, configure a network virtual appliance (NVA).
- In the spoke virtual networks, have user-defined routes with the next hop type "network virtual appliance" applied.
For more information, see Service chaining.
Note
If you require help to set up an NVA, contact the NVA vendor.
For help with troubleshooting the NVA device setup and routing, see Network virtual appliance issues in Azure.
The virtual networks are in different regions
Transit over global virtual network peering is now supported. Connectivity does not work over global virtual network peering for the following resources:
- VMs behind Basic ILB SKU
- Redis cache (uses Basic ILB SKU)
- Application gateway (uses Basic ILB SKU)
- Scale sets (uses Basic ILB SKU)
- Service Fabric clusters (uses Basic ILB SKU)
- SQL Server Always On (uses Basic ILB SKU)
- App Service Environment (uses Basic ILB SKU)
- API Management (uses Basic ILB SKU)
- Microsoft Entra Domain Services (uses Basic ILB SKU)
To learn more about global peering requirements and restraints, see Virtual network peering.
Troubleshoot a connectivity issue between two peered virtual networks
Sign in to the Azure portal with an account that has the necessary roles and permissions. Select the virtual network, select Peering, and then check the Status field. What is the status?
The peering status is "Connected"
To troubleshoot this issue:
Check the network traffic flows:
Use Connection Troubleshoot and IP flow verify from the source VM to the destination VM to determine whether there is an NSG or UDR that is causing interference in traffic flows.
If you're using a firewall or NVA:
- Document the UDR parameters so that you can restore them after this step is complete.
- Remove the UDR from the source VM subnet or NIC that points to the NVA as the next hop. Verify connectivity from the source VM directly to the destination that is bypassing the NVA. If this step doesn't work, see the NVA troubleshooter.
Take a network trace:
Start a network trace on the destination VM. For Windows, you can use Netsh. For Linux, use TCPDump.
Run TcpPing or PsPing from the source to the destination IP.
This is an example of a TcpPing command:
tcping64.exe -t <destination VM address> 3389After the TcpPing is complete, stop the network trace on the destination.
If packets arrive from the source, there is no networking issue. Examine both the VM firewall and the application listening on that port to locate the configuration issue.
Note
You can't connect to the following resource types over global virtual network peering (virtual networks in different regions):
- VMs behind Basic ILB SKU
- Redis cache (uses Basic ILB SKU)
- Application gateway (uses Basic ILB SKU)
- Scale sets (uses Basic ILB SKU)
- Service Fabric clusters (uses Basic ILB SKU)
- SQL Server Always On (uses Basic ILB SKU)
- App Service Environment (uses Basic ILB SKU)
- API Management (uses Basic ILB SKU)
- Microsoft Entra Domain Services (uses Basic ILB SKU)
For more information, see the requirements and constraints of global peering.
The peering status is "Disconnected"
To resolve this issue, delete the peering from both virtual networks, and then re-create them.
Troubleshoot a connectivity issue between a hub-spoke virtual network and an on-premises resource
Does your network use a third-party NVA or VPN gateway?
My network uses a third-party NVA or VPN gateway
To troubleshoot connectivity issues that affect a third-party NVA or VPN gateway, see the following articles:
My network does not use a third-party NVA or VPN gateway
Do the hub virtual network and the spoke virtual network have a VPN gateway?
Both the hub virtual network and the spoke virtual network have a VPN gateway
Using a remote gateway isn't supported.
If the spoke virtual network already has a VPN gateway, the Use remote gateway option isn't supported on the spoke virtual network. This is because of a virtual network peering limitation.
Both the hub virtual network and the spoke virtual network do not have a VPN gateway
For site-to-site or Azure ExpressRoute connections, check the following primary causes of connectivity issues to the remote virtual network from on-premises:
- On the virtual network that has a gateway, verify that the Allow forwarded traffic check box is selected.
- On the virtual network that doesn't have a gateway, verify that the Use remote gateway check box is selected.
- Have your network administrator check your on-premises devices to verify that they all have the remote virtual network address space added.
For point-to-site connections:
- On the virtual network that has a gateway, verify that the Allow forwarded traffic check box is selected.
- On the virtual network that doesn't have a gateway, verify that the Use remote gateway check box is selected.
- Download and reinstall the point-to-site client package. Virtual network routes that are newly peered don't automatically add routes to point-to-site clients.
Troubleshoot a hub-spoke network connectivity issue between spoke virtual networks in the same region
A hub network must include an NVA. Configure UDRs in spokes that have an NVA set as the next hop, and enable Allow forwarded traffic in the hub virtual network.
For more information, see Service chaining, and discuss these requirements with the NVA vendor of your choice.
Troubleshoot a hub-spoke network connectivity issue between spoke virtual networks in different regions
Transit over global virtual network peering is now supported. Connectivity doesn't work over global virtual network peering for the following resources:
- VMs behind Basic ILB SKU
- Redis cache (uses Basic ILB SKU)
- Application gateway (uses Basic ILB SKU)
- Scale sets (uses Basic ILB SKU)
- Service Fabric clusters (uses Basic ILB SKU)
- SQL Server Always On (uses Basic ILB SKU)
- App Service Environment (uses Basic ILB SKU)
- API Management (uses Basic ILB SKU)
- Microsoft Entra Domain Services (uses Basic ILB SKU)
For more information, see the requirements and constraints of global peering and Different VPN Topologies.
Troubleshoot a hub-spoke network connectivity issue between a web app and the spoke virtual network
To troubleshoot this issue:
- Sign in to the Azure portal.
- In the web app, select networking, and then select VNet Integration.
- Check whether you can see the remote virtual network. Manually enter the remote virtual network address space (Sync Network and Add Routes).
For more information, see the following articles:
Troubleshoot a virtual network peering configuration error message
Current tenant <TENANT ID> isn't authorized to access linked subscription
To resolve this issue, see Create a virtual network peering between different subscriptions.
Not connected
To resolve this issue, delete the peering from both virtual networks, and then recreate them.
Failed to peer a Databricks virtual network
To resolve this issue, configure the virtual network peering under Azure Databricks, and then specify the target virtual network by using Resource ID. For more information, see Peer a Databricks virtual network to a remote virtual network.
The remote virtual network lacks a gateway
This issue occurs when you peer virtual networks from different tenants and later want to configure Use Remote Gateways. A limitation of the Azure portal is that it can't validate the presence of a virtual network gateway in another tenant's virtual network.
There are two ways to resolve the issue:
- Delete the peerings and activate the
Use Remote Gatewaysoption when you create a new peering. - Use PowerShell or CLI, instead of the Azure portal, to enable
Use Remote Gateways.