Share via

NHRP traffic is from Azure Spoke is not forwarding to other on Prem Spoke

Catzilla 0 Reputation points
2025-11-29T09:46:27.2466667+00:00

Recently, one of the Cisco virtual routers was installed in Azure. The virtual router is one of the spoke routers, like other on-prem spoke routers, which have a phase 3 dmvpn tunnel. There is no issue that the spoke router creates a dmvpn tunnel to the Hub routers, but the problem arises when the spoke router is trying to connect to other spokes on-prem. The configuration is identical to that of other spokes. I have also posted the issue on the Cisco forum, but so far, there has been no response, and I think the problem lies on the Azure side. I have allowed UDP ports 500 and 4500 under NSG. I have set static IP address and allow IP forward. Inbound rule.pngIP Forward. pngoutbound rule.png.

With the debug I have seen on the Azure spoke, the nhrp is incomplete, which indicates something is blocking on the Azure side.

It would be great if someone has experience the same issue or can give an idea where I should look in Azure to find out the root cause of it.

Azure Virtual Network
Azure Virtual Network
An Azure networking service that is used to provision private networks and optionally to connect to on-premises datacenters.
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Vinodh247 40,031 Reputation points MVP Volunteer Moderator
    2025-11-29T10:07:56.4466667+00:00

    If NHRP remains stuck in “incomplete” on a DMVPN spoke inside Azure, the issue is almost never the DMVPN config. It is almost always Azure blocking something at the platform layer. Even if you enable IP forwarding on the NIC and VM, DMVPN Phase3 usually fails unless you also fix these 3 points:

    1. Disable Azure’s default SNAT If the VM’s outbound traffic is going through Azure’s default internet SNAT, DMVPN and NHRP will break. You must place the VM in a subnet with a proper Standard SKU public IP + Standard Load Balancer, or use User Defined Routes to avoid Azure SNAT.
    2. Ensure UDR allows end-to-end GRE/IP protocol 47 NSGs do not block GRE, but Azure virtual network fabric does not support GRE unless traffic stays inside the same VNet or goes through an NVA that handles it locally. DMVPN relies on GRE (protocol 47), and Azure will not forward GRE packets between subnets like a physical router. That means: DMVPN is not supported as a routed protocol in Azure unless the GRE tunnel is terminated inside the same VM. Your onprem spokes can talk to the hub because the endpoint is reachable, but Azure cannot forward GRE from your Azure spoke to the other on-prem spokes.

    Check if the Hub is doing spoke-to-spoke redirection Even in Phase 3, Azure cannot hairpin GRE unless the hub NVA supports full packet re-encapsulation. Most do not.

    The bottom line Azure will not forward GRE between spokes. DMVPN Phase 3 requiring GRE redirection will not work in an Azure VNet. Your Azure spoke can build the tunnel to the hub, but spoke-to-spoke NHRP discovery will never complete.

    What to do instead Use one of these supported patterns:

    Use IPsec route-based VPN instead of DMVPN for Azure spokes.

    Terminate DMVPN on a single Azure NVA hub, not as a spoke.

    Use SD-WAN or Azure Virtual WAN for multi-branch connectivity.

    Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful. This will be benefitting other community members who face the same issue.

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.