Share via

Routing Topology Visibility with NVA-Secured vWAN Hub

Rina Frusman 20 Reputation points
2026-05-24T17:02:12.21+00:00

Environment Overview

  • Deployment Model: Azure Virtual WAN Hub with Routing Intent enabled
  • Security Appliance: Checkpoint CloudGuard Network (NVA) deployed as hub firewall
  • Requirement: Full topology visibility for return traffic flows (hub → peered VNets, hub → on-premises, hub → VPN)

Problem Statement

When Routing Intent is configured with an NVA (instead of Azure Firewall), we face a critical visibility gap in understanding the complete traffic topology.

Current Situation

  1. Outbound Routes Visible: Routes from VNets/on-prem/VPN → NVA are properly exposed via Azure APIs
  2. Return Routes Hidden: Routes from NVA back to peered VNets, on-premises networks, and VPN gateways are NOT visible
  3. Azure Firewall Comparison: When Azure Firewall secures the hub, the equivalent routing tables ARE exposed via the Azure "azure firewall" route table resource
  4. NVA Gap: No equivalent route table exposure exists for NVA deployments

Observable Discrepancy on NVA

  • NVA routing tables show next-hop IPs (example: 10.x.x.x) that are part of the hub's address space
  • These next-hop IPs cannot be found in any Azure resource (not in subnet IPs, not in NVA NICs, not in load balancer configurations)
  • CP documentation diagrams reference a load balancer, but this resource is not visible in Azure Portal or via Azure CLI

Key Questions for Support

For Azure Support:

  1. Route Table Access:
    • When an NVA is set as the Routing Intent secure hub appliance, what is the equivalent to the "azure firewall" route table that exposes return traffic routes?
      • If no route table exists, can Azure expose the NVA return-path routes via an API/CLI method (similar to Azure Firewall)?
      1. Next-Hop IP Resolution:
        • When we observe next-hop IPs (e.g., 10.x.x.x from hub address space) on the NVA's routing table for peered VNet destinations, what Azure resources do these IPs represent?
          • Are these virtual IPs (VIPs) provisioned dynamically by vWAN for the Routing Intent infrastructure?
            • Can we query these via Azure APIs or are they internal/undocumented?
            1. Hidden Load Balancer:
              • The CP documentation references a load balancer in the traffic flow diagram, but it's not visible in Azure Portal/CLI
                • Is this load balancer an internal/managed resource created by vWAN that is not exposed to the user?
                  • Should this load balancer be visible under a specific resource group or subscription context?
  2. Routing Intent Architecture:
  • Can Microsoft document the complete architecture of how Routing Intent handles traffic when an NVA (vs. Azure Firewall) secures the hub?
    • Specifically: What internal Azure infrastructure components handle routing from the NVA back to spokes/on-prem/VPN?
Azure Virtual WAN
Azure Virtual WAN

An Azure virtual networking service that provides optimized and automated branch-to-branch connectivity.

0 comments

3 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Sina Salam 29,846 Reputation points Volunteer Moderator
    2026-05-31T15:26:56.5+00:00

    Hello Rina Frusman,

    Welcome to the Microsoft Q&A and thank you for posting your questions here.

    I understand that you are having issue with Routing Topology Visibility with NVA-Secured vWAN Hub.

    Just to give you more clarity and your specific scenario recommendation:

    The AI-generated response in the thread was broadly correct but incomplete.

    In addition to the AI-generated response, the decisive Microsoft-documented conclusion is that Azure Virtual WAN does not expose a public Azure Firewall-equivalent return-path route table for an integrated NVA used as the Routing Intent next hop.

    Meaning that Azure Virtual WAN with an integrated NVA used through Routing Intent does not expose a documented Azure Firewall-style return-path route table or a documented NVA-specific effective-routes surface. The idea that there is a public NVA return-route table equivalent to Azure Firewall is not supported by Microsoft documentations, and the suggested NvaConnection-style effective-routes lookup is not documented in the Azure CLI reference. The correct and supportable answer is therefore: there is no public NVA route-table object to query for the return path. - https://learn.microsoft.com/en-us/azure/virtual-wan/effective-routes-virtual-hub, https://learn.microsoft.com/en-us/cli/azure/network/vhub?view=azure-cli-latest, and https://learn.microsoft.com/en-us/azure/virtual-wan/how-to-routing-policies gives more insights.

    The Microsoft-documented conclusion is that Azure Virtual WAN does not expose an Azure Firewall-equivalent return-path route table or a documented NVA-specific effective-routes API for an integrated NVA used as the Routing Intent next hop. The return path is implemented through Microsoft-managed integrated NVA infrastructure inside the hub, and Microsoft Learn documents that this infrastructure includes VM scale sets and Azure Load Balancers in the Virtual WAN hub. The 10.x next-hop IPs seen on the NVA are therefore platform-managed internal datapath addresses, not customer-visible Azure resources that can be mapped through a supported public API. - https://learn.microsoft.com/en-us/azure/virtual-wan/third-party-integrations, https://learn.microsoft.com/en-us/azure/virtual-wan/about-nva-hub, and https://learn.microsoft.com/en-us/azure/virtual-wan/how-to-network-virtual-appliance-add-ip-configurations

    What you can do as resolution is to:

    • Use Virtual Hub effective routes for the relevant route table and supported hub connection resources to validate which prefixes and next-hop types the hub sees.
    • Validate the Routing Intent policy to confirm whether Private and/or Internet traffic is being steered to the NVA.
    • Validate the NVA’s own route/BGP table from the appliance side, because this is the authoritative view of what the NVA has learned.
    • Do not continue searching for a public “NVA return-route table,” because Microsoft documentation does not expose one.

    After validating the hub effective routes, the Routing Intent policy, and the NVA-side routing table, you will have the only Microsoft-supported end-to-end method to confirm the actual return path for hub-to-spoke, hub-to-branch, and hub-to-VPN traffic in this design.

    Use the below official Microsoft resources for the exact product behavior and supported commands:

    I hope this is helpful! Do not hesitate to let me know if you have any other questions, steps or clarifications.

    Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.

    Was this answer helpful?

    0 comments
  2. Venkatesan S 9,055 Reputation points Microsoft External Staff Moderator
    2026-05-27T06:07:58.0433333+00:00

    Hi Rina Frusman,

    Thanks for reaching out in Microsoft Q&A forum,

    You’re right, when you swap out Azure Firewall for a third-party NVA in a Secure vWAN Hub, the familiar “azureFirewall” route-table resource (which surfaces inbound and return paths) isn’t created. Here’s what’s happening under the covers and how you can still get full visibility:

    1. No exposed “NVA route table” resource
      • Virtual WAN doesn’t spin up a dedicated ARM route-table object for NVAs the way it does for Azure Firewall. All routing is managed by the hub’s internal router fabric.
    2. Use the “effective routes” API/CLI instead
      • You can pull every single route (including return paths) for your hub + its connections via the Effective Routes endpoint. • CLI: 
             az network vwan hub list-effective-routes --resource-group <RG> --name <VirtualHubName> --connection-type NvaConnection
        • REST: GET /subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Network/virtualHubs/{hub}/effectiveRoutes?api-version=2022-05-01
      • That output will show you all prefixes, next hops and where they’ll actually go—even the return-path rules you’re missing in the portal.
    3. What are those mysterious 10.x.x.x next hops?
      • They’re the VIPs of the hub’s internal load balancer(s) and router fabric. Traffic to/from your NVA is front-ended by a platform-managed LB you don’t see in your subscription.
      • Those VIPs aren’t part of your VNet, NIC or public LB—they’re ephemeral frontends inside the Virtual WAN service. They’re not user-exposed as resources but do show up as “next hop IP” in your NVA’s routing table.
    4. The hidden load balancer
      • Azure Virtual WAN uses an internal Azure Load Balancer + distributed router to steer packets to NVAs (or Azure Firewall). This LB is entirely managed by the vWAN service and doesn’t appear in the portal/CLI under your RG.
      • It lives in the Virtual WAN’s infrastructure plane and is how Routing Intent ensures scale and HA.
    5. High-level Routing Intent architecture
      • When you configure an NVA as the next hop: a. Hub router (scale units) uses an internal LB VIP to send traffic to your NVA instances. b. NVA processes/inspects the packet and sends it back to the same LB VIP. c. Hub router picks it up and forwards it to the spoke VNet, on-prem site or VPN gateway per your policies.
      • All of this is built on top of the Virtual Hub Routing Infrastructure Units and hidden Azure Load Balancers mentioned in the Virtual WAN docs.

    Hope that helps clear up where the routes live and what those IPs represent.

    Kindly let us know if the above helps or you need further assistance on this issue.

    Reference List

    Please do not forget to 210246-screenshot-2021-12-10-121802.pngand “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

    Was this answer helpful?

  3. AI answer

    2026-05-24T17:02:37.2033333+00:00

    Azure Virtual WAN currently exposes effective routing only for the Virtual Hub router and for Azure Firewall when it is the security solution. When a third‑party NVA is integrated via routing intent, the return‑path routing from the NVA back into the hub (toward VNets, branches, and other hubs) is not surfaced as a user‑visible route table resource.

    Based on the available documentation, the following points are supported:

    1. Route table exposure for NVA‑secured hubs
    • Virtual WAN routing intent is a declarative feature that steers traffic to a next‑hop security solution (Azure Firewall, integrated NGFW NVA, or SaaS security) using two policies: a private routing policy (for VNet/branch/inter‑hub traffic) and an internet routing policy (for 0.0.0.0/0) in each hub.
    • For Azure Firewall, effective routes on the firewall can be viewed when routing intent or direct internet access is configured, and the platform explicitly documents how the 0.0.0.0/0 route with next hop Internet is applied on the security solution in the hub.
    • For NVAs, the documentation only states that they can be integrated as the next hop for routing intent and that traffic is steered to them as a class (private or internet). There is no documented equivalent of the “azure firewall” route table resource that exposes the NVA’s return‑path routes.
    • The documentation explicitly directs customers to use routing intent and policies when routing traffic to an NVA in the Virtual WAN hub or when inspecting inter‑hub and branch‑to‑branch traffic, but it does not provide any API/CLI surface to inspect the internal return‑path routing for NVAs.

    From the available material, there is no documented API/CLI that exposes a dedicated “NVA route table” comparable to the Azure Firewall route table in a secured virtual hub.

    1. Nature of the next‑hop IPs seen on the NVA
    • When an NVA is integrated in the Virtual WAN hub with routing intent, the platform manages routing between:
      • VNets and the hub
      • Branches (ExpressRoute, site‑to‑site VPN, point‑to‑site VPN) and the hub
      • Other hubs (inter‑hub)
    • The documentation describes that routing intent steers traffic to the configured next hop (Azure Firewall, integrated NGFW NVA, or SaaS security) as a class, but it does not enumerate or document the internal IPs used as next hops inside the hub.
    • The presence of next‑hop IPs in the hub address space that do not correspond to user‑visible NICs, subnets, or load balancers is consistent with internal/managed infrastructure used by Virtual WAN to connect the hub router, the security solution, and the various connections.
    • The documentation does not describe these IPs as queryable resources, nor does it provide any API to list them. They should be treated as internal implementation details of the Virtual WAN hub and routing intent.

    From the available documentation, these next‑hop IPs are internal/managed addresses used by the Virtual WAN platform and are not exposed as first‑class Azure resources or via public APIs.

    1. Hidden load balancer and internal components
    • The Virtual WAN documentation and the Azure landing zone guidance describe that:
      • A secured virtual hub is an Azure Virtual WAN hub with associated security and routing policies configured by Azure Firewall Manager.
      • Routing intent can use Azure Firewall, an integrated NGFW NVA, or a SaaS security solution as the next hop.
    • The documentation does not list or expose any user‑visible load balancer resources that sit between the hub router and the NVA when routing intent is configured.
    • The behavior described (traffic steered to a security solution, then forwarded to VNets/branches or directly to Internet) implies internal components (such as managed load‑balancing and internal IPs) within the hub, but these are not documented as resources that appear in a resource group or subscription.

    From the available material, any load balancer used to integrate an NVA with routing intent in a Virtual WAN hub is an internal/managed component of the Virtual WAN service and is not exposed as a standard Azure Load Balancer resource in the portal or CLI.

    1. Documented architecture for routing intent with NVAs
    • Routing intent is documented as follows:
      • A hub can have up to two routing policies:
        • Private routing policy: steers VNet‑to‑VNet, branch‑to‑VNet (ExpressRoute, site‑to‑site VPN, point‑to‑site VPN), and inter‑hub traffic to the configured next hop as a single class. By default, it matches RFC1918 aggregates and can be extended with additional prefixes.
        • Internet routing policy: steers 0.0.0.0/0 traffic to the configured next hop, which forwards inspected traffic directly to the internet from the hub (direct access).
      • Each policy’s next hop can be Azure Firewall, an integrated NGFW NVA, or a SaaS security solution.
    • The documentation also notes:
      • For dual‑role NVAs (SD‑WAN + NGFW) in active‑active configurations, Azure performs ECMP and does not guarantee flow‑level symmetry, which can cause asymmetric routing and dropped flows on stateful firewalls unless the NVA supports asymmetric forwarding or session synchronization.
      • For scenarios where traffic must be inspected by an NVA deployed in the hub, routing intent and policies must be used; static routes alone are not sufficient or supported for several inspection scenarios.
    • However, the documentation does not provide a low‑level diagram of all internal components (e.g., internal load balancers, internal IPs) used when an NVA is the security solution.

    From the available documentation, the architecture is described at a functional level (traffic classes, routing policies, and supported patterns) but does not expose or document the internal infrastructure components that implement routing from the NVA back to spokes/on‑prem/VPN.

    In summary, with the information available:

    • There is no documented, user‑accessible equivalent of the Azure Firewall route table for NVAs integrated via routing intent in a Virtual WAN hub.
    • The next‑hop IPs observed on the NVA that belong to the hub address space are internal/managed addresses used by the Virtual WAN platform and are not exposed as standard Azure resources or via public APIs.
    • Any load balancer used in the NVA integration path is an internal/managed component of the Virtual WAN hub and is not visible in the portal or CLI.
    • The routing intent architecture with NVAs is documented at a high level (traffic classes, policies, and supported scenarios), but the internal return‑path routing and infrastructure components are not publicly documented.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

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.