Same-subnet Private Endpoint access fails with UDR policies enabled in secured vWAN

Viktor Garai 0 Reputation points
2026-09-24T21:14:32.48+00:00

Hello,

In an Azure Virtual WAN setup with a secured hub and Azure Firewall routing intent for private and internet traffic, same-subnet VM-to-Private Endpoint connectivity fails with the following configuration.

Each application has its own subnet containing VMs and private endpoints. Each subnet has two UDRs:

  • VNet address range -> Azure Firewall
  • Own subnet address range -> Virtual network

The goal is to keep same subnet traffic local while inspecting traffic between subnets.

With Private Endpoint route-table policies enabled:

  • Same-subnet VM > VM works.
  • Same-subnet VM > Azure Files PE fails.
  • Adding an explicit PE /32 > VnetLocal doesn’t help.
  • Adding PE /32 > Firewall works, provided a firewall allow rule exists.

Disabling PE route-table policies restores access, but also lets traffic from other subnets bypass firewall inspection. Adding the PE /32 to the secured hub’s Private Traffic Prefixes didn’t resolve the local-access issue. The source VM’s effective routes showed the PE’s system /32 InterfaceEndpoint route as Invalid, while the own-subnet VnetLocal route remained Active.

Is this expected behaviour?

Is there a supported way to keep same-subnet VM-to-PE traffic local while forcing traffic from other subnets through the firewall, without maintaining per-PE /32 routes and firewall allow rules for connections that should remain local?

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 No comments

2 answers

Sort by: Oldest
  1. Andriy Bilous 12,191 Reputation points MVP
    2026-09-25T04:47:49.94+00:00

    Hello Viktor Garai

    Yes, the observed behavior is expected.

    With Private Endpoint route-table policies enabled, a UDR covering the PE address can override the normal /32 InterfaceEndpoint route. UDR with Next hop = VirtualNetwork does not restore Private Endpoint reachability, while Next hop = NVA/Azure Firewall does.

    That explains:

    • PE /32 -> VirtualNetwork → fails
    • PE /32 -> Firewall → works
    • disabling PE route policies → restores the InterfaceEndpoint path

    However, you do not necessarily need per-PE /32 routes.

    Instead of:

    VNet CIDR -> Firewall Own subnet -> VirtualNetwork

    use routes only for the other subnets that must be inspected:

    Other-app-subnet-A -> Firewall Other-app-subnet-B -> Firewall

    and have no UDR covering the local subnet.

    Then:

    • same-subnet VM → VM uses the normal VNet system route;
    • same-subnet VM → PE keeps the /32 InterfaceEndpoint route;
    • traffic to a PE in another subnet is overridden by that destination-subnet UDR and sent through Azure Firewall.

    So this same pattern is typical for forcing traffic between subnets in the same vWAN-connected VNet: use UDRs for the specific remote subnet prefix, rather than a VNet-wide route plus a VirtualNetwork exception.

    Also, adding the PE /32 to the secured hub Private Traffic Prefixes does not create a same-subnet local exception. Microsoft states that same-VNet PE inspection is controlled with subnet UDRs and Private Endpoint network policies.

    And the recommended design is:

    Do not use VNet CIDR -> Firewall + own subnet -> VirtualNetwork when VMs and PEs share that subnet. Use destination-subnet routes to the firewall only for the subnets that require inspection.

    For PE traffic that actually traverses Azure Firewall, also review SNAT requirements; Microsoft recommends SNAT when inspecting Private Endpoint traffic to avoid asymmetric return-path issues.Yes, the observed behavior is expected.

    https://learn.microsoft.com/en-us/azure/private-link/disable-private-endpoint-network-policy
    https://learn.microsoft.com/en-us/answers/questions/2183987/network-policy-fails-for-private-endpoint

    Was this answer helpful?

    0 comments No comments

  2. Viktor Garai 0 Reputation points
    2026-09-25T08:49:38.3066667+00:00

    Thanks @Andriy Bilous Then based on my understanding would an aggregated version of this approach also work, to avoid maintaining a route for every other subnet?

    Assume a VNet 10.0.0.0/15 containing 50+ application subnets, each /24.

    For the source subnet 10.0.0.0/24, replace the VNet-wide firewall route and own-subnet VirtualNetwork exception with these destinations, all pointing to Azure Firewall:

    10.0.1.0/24
    10.0.2.0/23
    10.0.4.0/22
    10.0.8.0/21
    10.0.16.0/20
    10.0.32.0/19
    10.0.64.0/18
    10.0.128.0/17
    10.1.0.0/16
    

    These cover the entire VNet except the source subnet. Each subnet would receive its own calculated exclusions, with PE route-table policies remaining enabled.

    The intention is:

    Same-subnet VM-to-VM and VM-to-PE traffic stays local using system routes.

    Traffic to other subnets traverses the firewall.

    Internet and inter-VNet inspection remains governed by vWAN routing intent.

    Would this be equivalent to your suggested destination-subnet routing approach, including for PEs? It would require nine UDRs per table in this example, without adding routes whenever another subnet or PE is deployed.

    Was this answer helpful?

    0 comments No 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.