The topology that is not a preference
Start with an investigation. Every suspicious connection in your flow logs resolves to the same internal address — not the workload, not the attacker, but the firewall. You pull the source IP for a data-exfiltration alert on an internet-egress flow. Firewall. You correlate an external-origin connection that passed through DNAT. Firewall again. The attribution chain ends before it starts, and the reason is structural, not misconfiguration — but it is also not universal. Some of that attribution loss is inherent to how centralised inspection works; some of it is controlled by settings you chose or did not choose. Knowing which is which is what this article is about.
Hub-and-spoke is the dominant Azure network topology for a specific reason. It concentrates inspection, policy enforcement, and routing control at a single choke point. That concentration is a deliberate engineering choice, and it carries costs that show up in your logs, your bills, and your operational posture before they show up anywhere else. Understanding those costs is what separates an operator who can use the topology from one who fights it.
The topology exists because of how Azure virtual network peering works — and more precisely, because of what it cannot do by default.
Why peering forces a hub
Peering in Azure is nontransitive. Virtual network peering connections are nontransitive relationships between virtual networks: if two spokes are each peered to a hub, they cannot reach each other through that hub without additional configuration (Source: learn.microsoft.com, https://learn.microsoft.com/en-us/azure/architecture/networking/architecture/hub-spoke). The hub does not relay traffic between spokes automatically. The peering relationship is bilateral and terminates at the hub boundary.
That single fact is the architectural forcing function. If spoke-to-spoke traffic must flow — for service calls, shared APIs, or security telemetry — there are only a few structural options. The most common are: add a direct peering between each pair of spokes, route all traffic through an appliance at the hub, use Azure Virtual WAN, or use Azure Virtual Network Manager to manage connectivity at scale.
Direct peering scales poorly as spoke count grows, because the number of required connections grows combinatorially. For environments with more than a handful of spokes, direct meshing creates operational debt faster than it solves the routing problem. Azure Virtual WAN and Azure Virtual Network Manager address some of these scaling problems but introduce their own complexity, cost profiles, and feature constraints; each warrants its own treatment. This article focuses on the conventional hub-and-spoke model with a centralised NVA or Azure Firewall, which remains the most widely deployed pattern for regulated enterprise environments.
Routing traffic through a central appliance is what produces the hub-and-spoke model as a security architecture. User-defined routes force spoke traffic toward an Azure Firewall or network virtual appliance acting as the hub's router, and the peering connections on both sides must be configured to permit forwarded traffic (Source: learn.microsoft.com, https://learn.microsoft.com/en-us/azure/architecture/networking/architecture/hub-spoke). Without UDRs, the platform's default routing does not send spoke traffic to an NVA — it simply drops packets that have no direct peer relationship. The UDR is the mechanism; the topology is the consequence.
Where inspection can sit
Given that traffic can be forced to a central point, the next decision is where in the flow to place the inspection function. The placement determines what the control can see, what it rewrites, and what breaks for services downstream.
Three positions are structurally distinct.
Hub NVA / Azure Firewall (in-line, east-west and north-south): Traffic from any spoke destined for another spoke or for the internet passes through the appliance. This gives the broadest visibility footprint — every inter-spoke flow, every egress connection. It also produces attribution complications whose severity depends on traffic direction and Azure Firewall configuration, as described in the next section.
Spoke-local NVA or micro-segmentation: An NVA or host-based control sits within the spoke itself, before traffic reaches the hub. This preserves source attribution for inter-spoke flows that do go to the hub, because the spoke-local control can log the original client before forwarding. The trade-off is policy fragmentation: each spoke carries its own enforcement point, and consistency depends on configuration management discipline across potentially many spokes.
Gateway subnet inspection: Traffic entering or leaving via VPN or ExpressRoute gateways can be inspected at the gateway subnet boundary. This position sees hybrid traffic but typically does not see spoke-to-spoke traffic that never crosses the gateway.
In practice, many Azure environments layer spoke-local controls for east-west enforcement and a hub NVA for egress — accepting that the hub will SNAT egress traffic but preserving source attribution for lateral-movement detection within the spoke. That layering adds complexity and requires explicit policy reconciliation between layers.
What centralising traffic rewrites — and when
This is where the architectural choice becomes a forensic problem, and where the details matter.
East-west traffic (spoke to spoke): By default, Azure Firewall does not apply SNAT to traffic between private address ranges. If both source and destination fall within RFC 1918 space, the firewall forwards the packet without rewriting the source IP, and backend workloads see the original client address. Attribution for east-west flows is therefore preserved under default configuration. This is the case worth protecting — misconfiguring SNAT behaviour, or routing east-west traffic through an NVA that does apply SNAT unconditionally, will degrade east-west attribution unnecessarily.
North-south egress traffic: When a spoke workload initiates a connection to a public destination, Azure Firewall applies SNAT on the forward path, rewriting the source IP to the firewall's public address before the packet leaves the Azure boundary. This is what guarantees that return traffic comes back to the firewall rather than attempting to reach the spoke workload directly — which would be unreachable from the internet and would break the flow. The consequence for security operations is that external destinations, and any logging done at those destinations, see the firewall's public IP rather than the originating workload. This is inherent to the egress model and is not configurable away without breaking return routing.
DNAT (inbound from internet): When Azure Firewall applies a DNAT rule to inbound connections, it translates the destination address to a backend workload. On the return path, it applies SNAT to that backend workload's response, rewriting the source so that return traffic flows symmetrically back through the firewall rather than bypassing it. The backend workload therefore observes the firewall's private IP as the source of the inbound connection, not the external client's IP. This attribution loss for inbound flows is inherent to the DNAT-plus-return-SNAT mechanism. Recovering the original client IP requires joining the backend's connection log against the Azure Firewall log on timestamp and destination port.
The practical summary: east-west attribution loss is often a configuration choice; egress SNAT and DNAT-path attribution loss are structural. Operators should know which they are dealing with before declaring a log anomaly a misconfiguration or accepting it as inevitable.
Concrete operational risks
Beyond attribution, the hub introduces several operational risks that deserve explicit attention.
SNAT port exhaustion. Azure Firewall's egress SNAT uses a pool of public IP addresses, and each active outbound flow consumes a SNAT port. Environments with many spoke workloads making concurrent outbound connections — particularly those with high connection churn, such as microservices calling external APIs — can exhaust the available SNAT port space. Exhaustion causes new outbound connections to fail silently from the workload's perspective, while appearing as dropped flows in the firewall log.
The mitigation is to monitor SNAT port utilisation as a first-class capacity metric and to associate additional public IP addresses with the firewall before exhaustion, not after. Azure Firewall Premium supports SNAT with larger port pools, but sizing still requires explicit planning.
Silent bypass. UDRs are the mechanism that forces traffic through the hub, but they are applied at the subnet level and must be maintained consistently as the environment grows. A new subnet deployed without the correct UDR, a subnet whose UDR was modified during a change window, or a peering created without enabling forwarded-traffic permissions will produce flows that bypass the hub entirely — without generating an alert, because the traffic is technically valid. The firewall never sees it.
Detecting silent bypass requires either continuous UDR compliance monitoring or flow-log analysis that flags spoke-to-spoke or spoke-to-internet traffic that did not pass through the hub's IP. Neither is automatic.
Log correlation fields. When joining Azure Firewall logs against backend workload logs or NSG flow logs to reconstruct a flow's origin, the fields that enable the join are: the firewall's translated source or destination IP, the destination port, the protocol, and the timestamp. Azure Firewall Diagnostic Logs (or Azure Firewall Workbook data via Log Analytics) record both the source IP and the translated address in the same log entry.
The correlation query must match on the translated IP as seen by the backend, the port as seen by the backend, and a timestamp window narrow enough to exclude collisions under high connection volume. Retaining firewall logs in the same Log Analytics workspace as NSG flow logs and workload logs is the prerequisite — cross-workspace joins are possible but add latency and query complexity at exactly the moment operational tempo is highest.
The cost of the hub
| Inspection placement | What it can see | What it rewrites | What breaks downstream |
|---|---|---|---|
| Hub NVA — east-west in-line | All spoke-to-spoke flows that UDRs redirect | Source IP only if SNAT is explicitly applied to private ranges (not Azure Firewall default) | Attribution loss if non-default SNAT behaviour is configured or if spoke uses NVA that SNATs unconditionally |
| Hub NVA — egress in-line | All outbound flows from spokes to public destinations | Source IP via SNAT on forward path (structural) | External destination logs show firewall IP; SNAT port exhaustion under high connection volume |
| Hub NVA — DNAT inbound | Inbound flows matching DNAT rules | Destination (DNAT) and return source (SNAT on return path) | Backend sees firewall private IP as client; correlation requires firewall log join |
| Spoke-local NVA (pre-hub) | Flows within the spoke before forwarding | Varies by NVA mode; may SNAT depending on configuration | Policy inconsistency if spoke NVAs diverge in configuration |
| Gateway subnet control | Hybrid/on-premises-origin traffic | Varies by NVA mode | Misses spoke-to-spoke traffic that never crosses the gateway |
The hub's costs fall into three categories:
Throughput concentration. All traffic that UDRs redirect must pass through the NVA instance. Scaling the appliance becomes a dependency for scaling the workloads behind it. Environments with high-bandwidth spoke workloads — video processing, large-scale data transfer, ML training data pipelines — may find the hub NVA is the first bottleneck to appear under load. Azure Firewall scales automatically within its tier limits, but NVA-based hubs require explicit instance sizing and may require scale-set configuration to handle burst traffic. SNAT port exhaustion is a separate scaling constraint from throughput and must be planned independently.
Blast radius. A misconfigured UDR or a failed NVA instance can black-hole traffic for all spokes that depend on it. The hub is a single operational dependency for all routed traffic, which makes its availability, change-management posture, and UDR governance critical. Silent bypass — where traffic avoids the hub due to a missing or misconfigured UDR — is the complementary failure mode: instead of blocking everything, a configuration gap passes everything uninspected.
Log correlation debt. Centralising inspection without centralising log access means the control and the evidence it produces are only as useful as the logging pipeline that connects them. The firewall's connection log is a first-class forensic artifact and should be retained, indexed, and queryable with the same priority as any endpoint detection source. If firewall logs are stored in a separate retention tier, under a different access policy, or with a different Log Analytics workspace, the correlation join that recovers source attribution will fail at the moment it matters most.
The hub-and-spoke topology in Azure is not the wrong architecture for enterprises with regulated workloads and a need for centralised policy enforcement. It is the architecture that concentrates control, concentrates risk, and concentrates the forensic problem in one place. Knowing which attribution losses are inherent, which are configurable, and what log joins are required to recover them — before the investigation starts — is the difference between designing for the topology and discovering its constraints under pressure.
