Two On-Prem VPN Addresses: Two Azure Peers, Not One

The diagram has two internet links at the branch and one Azure VPN gateway, so the local network gateway gets both public addresses. It looks tidy, and it does not work the way the diagram implies. Each on-premises VPN device is a separate peer relationship, and Microsoft's multiple-device design gives each one its own local network gateway resource and its own connection. Adding a second address to a single resource does not create a second peer. It creates a resource that describes neither device properly.

The myth: one gateway, two addresses

A local network gateway is a description of a remote peer: one public endpoint and the private prefixes behind it. There is no supported way to make that resource mean "either of these two appliances".

The same confusion runs in the other direction, where two Azure public IPs are read as evidence that two Azure gateways exist.

Count the objects, then count the tunnels

Take two independently operated on-premises devices, each with its own public address and access to the same private networks, plus one route-based Azure gateway in active-active mode. The Azure gateway has two active instances with separate public IPs. Each on-premises device connects to both instances. That is the full mesh, and the object count follows from it rather than from the diagram.

The arithmetic is short enough to paste into the design document:

2 on-premises VPN devices
2 local network gateway resources
2 connection resources
4 IPsec tunnels in the complete 2 x 2 mesh

A connection resource can carry more than one underlying tunnel, so four tunnels do not imply four virtual network gateways. Two Azure public IPs are also not the same objects as the two local network gateways describing the remote site.

What active-active adds on the Azure side

Active-active changes the Azure gateway from one active instance to two, each with its own public IP, and it is what makes a full mesh possible at all. It does not double the throughput of a single flow. It also does not remove the need for the on-premises side to support equal-cost multipath if both devices forward at once. Confirm the gateway mode, SKU and remote-device capability before provisioning anything.

A passive-standby gateway is a perfectly valid design; it simply produces a different tunnel count.

BGP makes both paths usable

For the multiple-device design, both on-premises devices run BGP. Give each a unique BGP peer address and advertise the same intended private prefixes across the relevant paths. The private prefixes identify the protected networks, while the public addresses identify where the encrypted carrier connections terminate. Confusing those two produces a design where every tunnel is up and the routes are wrong.

Plan return routing and any stateful inspection that has to tolerate either path. A healthy IKE session on every endpoint does not prove that a workload can use every advertised route.

Flow-based selection is not bandwidth pooling

Azure selects a path per flow using a hash over the flow's addressing and ports. In steady state, packets for a given TCP or UDP flow normally take the same tunnel, and the on-premises side may choose a different tunnel for the return direction. Two devices and four tunnels therefore improve availability, not the speed of one transfer. When a vendor slide promises aggregation, it is describing a different feature or a misunderstanding.

Test with parallel flows if you want to watch the paths spread, and with a single flow if you want to see the limit.

What redundancy you actually removed

Two WAN addresses on one appliance improve access-link options while sharing that appliance's power, software and failure state. They are not the same as two devices, and no amount of Azure-side configuration changes that. Follow the vendor's supported dual-WAN or cluster design instead of inferring redundancy from the address count. Then test it: remove one path at a time and confirm the remaining routes plus a real application exchange in both directions.

Expect detection and convergence delays, and expect some existing sessions to end.