Route traffic between two branches through an Azure VPN gateway
Two Site-to-Site connections on one Azure VPN gateway can pass branch traffic, but only when both ends learn the prefix and the LAN return path exists.
Two branches can exchange traffic through an Azure VPN gateway without any direct tunnel between them. Each branch opens a Site-to-Site connection to the same gateway, and the gateway passes the learned prefixes between the two connections. What makes this work is not the second tunnel but the route exchange: branch A has to learn branch B's prefix, and B has to learn A's. Work through the checks below in order and stop at the first one that fails, because every later step depends on it.
Preconditions, before you configure anything
Four conditions decide whether this design can work at all. The gateway must be route-based and on a SKU that supports BGP, both connections must have BGP enabled, the branch address spaces must not overlap, and neither side may rely on NAT to hide its real prefix.
Plan the ASNs deliberately. Azure's documented default is 65515, and each branch router needs its own private ASN that does not collide with the gateway or the other branch. Reusing a default without checking an existing gateway configuration is how an AS path gets rejected later.
Also confirm that you are not expecting VNet peering behaviour. The gateway exchanges routes between the two connections you configured; it does not make arbitrary peerings transitive. If a third network has to reach both branches, it needs its own connection or its own route path, not an assumption that the gateway will fan traffic out. Write that boundary down before the first change window, because it is the design decision people revisit when a later site is added.
Configure in this order
Each step has an observable result, so do not move on until it appears.
- Enable BGP on the virtual network gateway and note its ASN and peer address.
- Create a local network gateway per branch with that branch's real address space, its ASN and its BGP peer address.
- Create each Site-to-Site connection and enable BGP on the connection itself.
- Configure the branch router to peer with the gateway address Azure assigned, not with the gateway's public IKE endpoint by assumption.
Step four is where most attempts stall. The BGP peer address Azure reports is the one the branch router must use as its neighbour, and it is not always the address people expect from the tunnel diagram.
Advertise the branch prefix itself, for example 10.10.0.0/16 from A and 10.20.0.0/16 from B. Do not advertise a default route or a wide aggregate to cover a missing specific network; the gap comes back as a silent black hole later.
Verify the route exchange at both ends
Connection status is not the check. IPsec can be up on both connections while no prefix crosses between them. Read the gateway's BGP peers and its learned routes, then confirm that the route toward the other branch appears as a usable path.
| Check | Where | Stop if |
|---|---|---|
| BGP session established | Gateway BGP peers, branch router neighbour state | Session is Idle or Active on either side |
| Prefix learned | Gateway learned routes, branch BGP table | The other branch's prefix is absent |
| Prefix selected | Branch routing table, effective routes on the VNet | Prefix is known but a more specific route wins |
A prefix present in a BGP table can still lose the forwarding decision to a static route or a more specific prefix. Check the selected route, not only the received one.
Follow the return path on the LAN side
This is the part that looks correct in Azure and fails on site. A host in branch A sends its packet to A's VPN router only if that router is its default gateway, or if the host or its gateway holds a route for B's prefix. The same must be true in the other direction.
If a separate core switch is the LAN default gateway, it needs the route toward the other branch pointing at the VPN router. Without it, the request arrives and the reply leaves through the internet path, and the user sees a connection that opens and then hangs.
Do not reach for a network security group on the gateway subnet to fix this. That subnet has its own requirements and an NSG there is not a supported substitute for branch-side policy. Filtering belongs on the branch firewalls and on the workloads themselves, where the rules can be reviewed by the people who own them. Moving those rules to a subnet NSG also hides them from the team that will debug the next outage.
Admit the operation, then prove it with a denied test
A learned route is not a permission. Permit the source, destination and service you actually need through the branch firewalls and the endpoint policy, and leave the rest denied.
Test from an ordinary workload in branch A to a real service in branch B, confirm the reply, then attempt an operation that should stay prohibited. Traffic generated by the VPN appliance itself can use a different source address and skip the LAN routing stage, so a successful ping from the router proves less than it appears to.
Finish by writing down four facts: the prefixes exchanged, the ASNs in use, the LAN return path for each side, and the policy that admits the service. If one of them is missing, the setup works until the first change, and then nobody can explain why.