Spoke-to-Spoke Traffic Through a Hub Firewall, and an Overlapping Acquisition

Frame the path first. Traffic from 10.0.0.0/16 goes to the firewall because of its UDR; the firewall then routes it to 10.101.0.0/16 across the hub-to-prod peering; the reply comes back to the firewall and out across the hub-to-acquired peering. Every hop of that return path is a place the packet can be dropped, and the working spokes only prove the prod and dev side of it.

Most likely cause 1: forwarded traffic is not allowed on the peerings. Traffic leaving the hub toward the acquired VNet was originated in another VNet and forwarded by the firewall. That requires 'Allow forwarded traffic' to be enabled on the peering through which the forwarded packet enters the acquired VNet, and the matching setting in the other direction must not block the request path. The default on peerings created in the portal is off, which matches the symptom exactly: the peering can be Connected and still silently drop the forwarded return traffic.

Most likely cause 2: the firewall policy does not include the new range. Rules written for 10.101.0.0/16 and 10.102.0.0/16 will not match source 10.0.0.0/16. Check the network rule collection source and destination, and confirm the effective policy on the firewall, not the intent.

Then, in order. Verify both halves of every peering exist and are Connected, not Initiated. Use IP flow verify and next hop from a VM in the acquired VNet to confirm the UDR is effective and that the next hop is the firewall. Use connection monitor or Network Watcher to test TCP 443 end to end. Check NSGs on the acquired subnet, the firewall subnet, and the prod subnet for the return direction, and confirm no overlapping prefix (10.0.0.0/16 against 10.101.0.0/16 is fine, but the legacy VNet is not).

Note the gateway transit proposal is unrelated. Gateway transit governs on-premises reachability through the hub VPN gateway; it will not fix spoke-to-spoke routing.

The constraint. VNet peering requires that the two address spaces do not overlap in either direction. The legacy VNet uses 10.101.0.0/16 and prod uses 10.101.0.0/16, so the peering cannot be created at all - this is not a configuration preference, it is a hard validation failure. Peering is also non-transitive: even if the acquired VNet peers to the hub, prod cannot reach the legacy range through the hub, because the hub has no unambiguous route for 10.101.0.0/16.

Option 1: renumber the legacy VNet. Most work, best long-term outcome. Prioritise it for anything that will live more than a year. Sequence it while the legacy workload has the least dependency on prod.

Option 2: NAT at an edge device. Neither VNet peering nor the Azure VPN Gateway or ExpressRoute performs address translation between VNets. You would need an NVA or firewall positioned so that the legacy side appears to prod as a non-overlapping prefix, translating source and destination. This works but adds a stateful hop, a throughput ceiling, and a component whose failure mode is total loss of connectivity between the two estates.

Option 3: publish only the specific services. Use Private Link so the legacy workload consumes a private endpoint for the exact service it needs instead of routing whole subnets. This avoids broad connectivity and is the fastest acceptable interim answer, but with overlapping address space the private IP of the endpoint lands inside 10.101.0.0/16 in the consumer VNet, which collides with prod routes - so validate the addressing carefully, and it does not give general connectivity.

Option 4: keep the estates disconnected. Often the right call while an acquisition is being integrated: replicate or export the data needed and avoid building a permanent overlapping-network workaround.

What I would say to the team. Peer the non-overlapping acquired VNet to the hub and fix its routing; treat the legacy VNet as a migration project with a funded renumbering plan.

What it changes. The hub already has the site-to-site VPN gateway in GatewaySubnet. Enabling 'Allow gateway transit' on the hub's peering to a spoke, and 'Use remote gateways' on that spoke's peering back to the hub, lets the spoke use the hub's gateway instead of needing its own. The spoke then receives routes for 192.168.0.0/16 from the hub gateway, so VMs in the spoke can reach on-premises without a gateway of their own.

When it is required. Only when a spoke must reach on-premises and has no gateway. It is not required for spoke-to-spoke traffic, and the settings must match: the spoke cannot use remote gateways unless the hub side allows transit, and a VNet cannot use remote gateways if it already hosts a gateway. Address spaces must still not overlap.

Why it does not fix the current symptom. The acquired VNet cannot reach prod. That path is spoke→firewall→spoke, which depends on UDRs, firewall policy, and forwarded-traffic settings on the peerings. Gateway transit adds on-premises routes; it changes nothing about 10.101.0.0/16 reachability.

The risk. Once a spoke learns the on-premises routes from the hub gateway, traffic can take that path directly instead of being steered to 10.100.1.4, bypassing firewall inspection and logging. The mitigation is to keep the 0.0.0.0/0 UDR to the firewall on every spoke subnet, or add a specific 192.168.0.0/16 → 10.100.1.4 route, and to keep those route tables associated with all subnets, including any new ones. Also confirm the GatewaySubnet is not associated with a route table that sends 0.0.0.0/0 to the firewall, which breaks the gateway itself.

Recommendation. Enable it deliberately, per spoke, with the UDR in place first and verified with next-hop checks afterwards - not as a blanket change while troubleshooting a different problem.