# Do not use missing Virtual WAN propagation as proof of network isolation

> Can two secured-hub virtual networks still communicate when their routes are not propagated to each other?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-560-do-not-use-missing-virtual-wan-propagation-as-proof-of-network-isolation/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:22:36+00:00
- Modified: 2026-09-10T02:14:31+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

Can two secured-hub virtual networks still communicate when their routes are not propagated to each other?

## Potentially affected

Apply this check to the documented secured-hub Azure Firewall static-route design without routing intent. Identify aggregate routes as well as specific prefixes before declaring two connected virtual networks isolated.

## DSE recommendation

Express the intended denial in the firewall policy and validate the complete path.

## Article

## Source facts

Microsoft warns that Virtual WAN route associations and propagation settings do not guarantee isolation between virtual networks in a secured hub. An aggregate static route pointing to Azure Firewall can still provide a path between networks that do not propagate to each other. The source directs administrators to firewall network rules for the required block. Its Azure Firewall static-route pattern excludes hubs with routing intent enabled. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/virtual-wan/static-routes).

## Applicability

Apply this check to the documented secured-hub Azure Firewall static-route design without routing intent. Identify aggregate routes as well as specific prefixes before declaring two connected virtual networks isolated.

## DSE recommendation

Express the intended denial in the firewall policy and validate the complete path. Have the network and security owners review the associated route tables, propagated prefixes and aggregate next hops together. Document which traffic must be denied and which neighboring traffic must remain permitted. Keep a routing omission separate from a reviewed security rule. Propose only the required policy change and preserve the existing route and rule state for the authorized test.

## Verification

From approved endpoints, test both the intended denied connection and an explicitly allowed control flow. Retain the actual route and firewall decision with the result. Include destinations covered by a broader static prefix, not only directly listed routes. If traffic still passes through the firewall, investigate the matching rule instead of treating absent peer propagation as proof that the observation is impossible.

## Official references

[Microsoft Learn: Static routes in Azure Virtual WAN](https://learn.microsoft.com/en-us/azure/virtual-wan/static-routes).

## Primary reference

- Name: Static routes in Azure Virtual WAN - Azure Virtual WAN | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/virtual-wan/static-routes
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Do not use missing Virtual WAN propagation as proof of network isolation,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-560-do-not-use-missing-virtual-wan-propagation-as-proof-of-network-isolation/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.