Traffic from secondary VNet address space not routing through VPN Gateway

Question

Traffic from secondary VNet address space not routing through VPN Gateway

Anshul Kumar 0

Why is traffic from the secondary VNet address space 10.9.2.176/29 not going through the VPN Gateway tunnel despite correct routing configuration? What additional configuration is needed?

0 comments

1 answer

Your answer

Answer 1

This is a pretty common one when a second address space gets added to a VNet after the tunnel is already up.

The route table isn't the whole picture. An Azure S2S tunnel only carries prefixes that are in the negotiated IPsec traffic selectors and known to the device on the other end. Adding 10.9.2.176/29 to the VNet updates Azure's internal routing, but it doesn't renegotiate the tunnel or tell the peer anything. So the routes look perfect and the packets still get dropped.

Two things usually need to happen:

Renegotiate the tunnel. If the connection uses policy-based traffic selectors (or the peer is a policy-based device), the selectors were frozen when the tunnel came up and there's simply no SA for the new range. Reset the connection on the Azure side and clear the SA on the peer so it re-proposes. If you turn on IKEDiagnosticLog you'll usually see TS_UNACCEPTABLE for the new pair while the old tunnel happily stays up.

Add the prefix on the remote side. The on-prem device needs a route for 10.9.2.176/29 into the tunnel and its crypto policy has to permit it. Without this, outbound works and the return path dies — which looks identical to "the tunnel is ignoring my traffic." If you're running BGP, double-check Azure is actually advertising it with az network vnet-gateway list-advertised-routes.

One thing worth ruling out first: if that /29 is in a peered VNet rather than a second address space on the same VNet, you also have to re-sync the peering on both sides (az network vnet peering sync) after the address space change. The portal will show the new range while the peering is still serving the old prefix list.

Quickest way to confirm where it's breaking, run this from a NIC in that subnet:

az`` network nic show-effective-route-table -g <rg> -n <nic> -o table

If you see the on-prem destination with next hop VirtualNetworkGateway, Azure's side is fine and the problem is selectors or the peer. If it's missing or pointing somewhere else, it's the gateway/peering side.