Troubleshooter for virtual network peering issues

Applies to: Virtual Network

What does this guide do?

This troubleshooting guide provides steps to help you resolve most virtual network peering issues.

Who is it for? 

Anyone who uses virtual network peering.

How does it work?

It provides a checklist and a sequence of steps to identify the issue and guide you to a resolution.

Estimated time of completion

The time to complete this troubleshooter varies depending on your scenario. Typically, it takes anywhere from 20 to 45 minutes.

Select your scenario:

Select your scenario:

What is the networking topology that you want to implement?

Network Topology

Are the virtual networks in the same subscription or in different subscriptions?

To configure virtual network peering for the virtual networks that are in the same subscription, use the methods that are provided in the following articles, as appropriate:

  • If the virtual networks are in the same region, follow the steps to create a peering for virtual networks in the same subscription.
  • If the virtual networks are in the different regions, follow the steps to set up global virtual network peering.  

    Note Connectivity will not work over Global VNet 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 Always-on (uses Basic ILB SKU)
    • App Service Environments (ASE) (uses Basic ILB SKU)
    • API Management (uses Basic ILB SKU)
    • Azure Active Directory Domain Service (ADDS) (uses Basic ILB SKU)

For more information, see the requirements and constraints of global peering.

Did this resolve your issue?

To configure virtual network peering for virtual networks in different subscriptions or Active Directory tenants, follow the steps in Create peering in different subscriptions for Azure CLI.

Note To configure network peering, you must have Network Contributor permissions in both subscriptions. For more information, see Peering permissions.

Did this resolve your issue?

Select the Spoke configuration you want to use:

Spoke-configuration

 

For site-to-site connection or ExpressRoute connection

Follow the steps in: Configure VPN gateway transit for virtual network peering.

For point-to-site connections

  1. Follow the steps in: Configure VPN gateway transit for virtual network peering.
  2. After virtual network peering is established or changed, the point-to-site package must be downloaded and installed again in order for the point-to-site clients to get the updated routes to the spoke virtual network.

Did this resolve your issue?

The virtual networks are in the same region

You must configure a Network Virtual Appliance (NVA) in the hub virtual network and have user-defined routes with next hop "Network Virtual Appliance" applied in the spoke virtual networks. For more information, see Service chaining.

Note If you require help to set up an NVA, contact the NVA vendor.

For help to troubleshoot the NVA device setup and routing, see Network virtual appliance issues in Azure.

The virtual networks are in different regions

Transit over Global VNet Peering is now supported. Connectivity does not work over Global VNet 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 Always-on (uses Basic ILB SKU)
  • App Service Environments (ASE) (uses Basic ILB SKU)
  • API Management (uses Basic ILB SKU)
  • Azure Active Directory Domain Service (ADDS) (uses Basic ILB SKU)

To learn more about Global Peering requirements and restraints, see Virtual network peering.

Did this resolve your issue?

Does the issue occur between two peered networks or in a hub-spoke topology?

Network Topology

Go to Azure portal, select the virtual network, select Peering, and then check the Status field.

What is the status?

To troubleshoot the issue, follow these steps:

  1. 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 are usinga firewall or NVA appliance, follow these steps:
    1. Document the UDR parameters so that you can restore them after this step is completed.
    2. Remove the UDR from the source VM subnet or NIC that points to the NVA as the next hop. Verify connectivity from source VM directly to the destination that is bypassing the NVA. If this step works, refer to the NVA troubleshooter.
  2. Take a network trace. To do this, follow these steps:
    1. Start a network trace on the destination VM. For Windows, you can use Netsh. For Linux, use TCPDump.
    2. Run TcpPing or PsPing from the source to the destination IP. The following is an example of a TcpPing command: 
      tcping64.exe -t <destination VM address> 3389
    3. After the TcpPing is complete, stop the network trace on the destination.
       
    4. If you see packets arriving from the source, this rules out the possibility of a networking issue. Therefore, you must examine both the VM firewall and the application listening on that port to locate the configuration issue.

You cannot 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 Always-on (uses Basic ILB SKU)
  • App Service Environments (ASE) (uses Basic ILB SKU)
  • API Management (uses Basic ILB SKU)
  • Azure Active Directory Domain Service (ADDS) (uses Basic ILB SKU)

For more information, see the requirements and constraints of global peering.

Did this resolve your issue?

You must delete peerings from both VNets and re-create them.

Did this resolve your issue?

The connectivity issue occurs:

Do you use a third-party NVA or VPN gateway?

To troubleshoot connectivity issues that affect a third-party NVA or VPN gateway, see the following articles:

Did this resolve your issue? 

Do both the hub and spoke virtual networks have a VPN gateway?

Because of a VNet Peering  limitation, "Use Remote Gateway" is not supported on the spoke VNet if the Spoke VNet already has a VPN gateway.

Did this resolve your issue?

For site-to-site or ExpressRoute connections

Check the these primary causes of connectivity issues to the remote virtual network from on-premises.

  • Make sure that the Allow forwarded traffic check box is selected on the virtual network that has a gateway.
  • Make sure that the Use remote gateway check box is selected on the virtual network that does not have a gateway.
  • Have your network administrator check your on-premises devices to make sure that they all have the remote virtual network address space added. This is commonly overlooked.

For Point-to-Site connections

  • Make sure that the Allow forwarded traffic check box is selected on the virtual network that has a gateway.
  • Make sure that the Use remote gateway check box is selected on the virtual network that does not have a gateway.
  • Download and install the Point-to-Site client package again. Virtual network routes that are newly peered do not automatically add routes to Point-to-Site clients.

Transit over Global VNet Peering is now supported. Connectivity will not work over Global VNet 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 Always-on (uses Basic ILB SKU)
  • App Service Environments (ASE) (uses Basic ILB SKU)
  • API Management (uses Basic ILB SKU)
  • Azure Active Directory Domain Service (ADDS) (uses Basic ILB SKU)

For more information, see the requirements and constraints of global peering, and Different VPN Topologies.

Did this resolve your issue?

You must have an NVA in a hub network. You must also configure UDRs in spokes that have an NVA set as the next hop. Also, you must enable Allow Forwarded Traffic in the hub virtual network. For more information, see Service chainingand discuss these requirements with the NVA vendor of your choice.

Did this resolve your issue?

 

To troubleshoot this issue, follow these steps:

  1. Sign in to the Azure portal. Go to the web app, select networking, and then select VNet Integration.
  2. Check whether you can see the remote virtual network. Manually input the remote virtual network address space (Sync Network and Add Routes).

For more information, see the following articles:

Integrate your app with an Azure Virtual Network

About Point-to-Site VPN routing

Did this resolve your issue?

Select the error message that you received:

To resolve this issue, follow the steps in Create peering - Azure CLI.

Did this resolve your issue?

You must delete peerings from both VNets and recreate them.                            

Did this resolve your issue?

Congratulations! Your issue is resolved.

If your issue persists, please contact Azure Support for further assistance. 

To resolve this issue,  configure the virtual network peering from the Azure Databricks blade, 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.