I have an Azure VPN gateway with two connections to the same on-premises site, using separate internet links. BGP and AS-path prepending were configured so the primary path is always preferred and asymmetric routing is avoided.
This worked correctly until Azure migrated the gateway from the Basic SKU to Standard. The FortiGate is still configured with Azure BGP peers x.x.x48.4 and x.x.x48.5. The primary session is established, but its remote router ID is unexpectedly x.x.x48.6. The secondary session targeting x.x.x48.5 has remained in the Active state for weeks.
Azure's BGP monitoring now shows local addresses .6 and .7 rather than .4 and .5. It reports .6 connected to the primary on-premises firewall, while .7 is stuck Connecting to the backup firewall with no routes received. FortiGate logs show repeated connections from .7 being rejected because no matching peer is configured.
The gateway configuration still lists .4 and .5 as the default BGP peer addresses, so it looks like the migration may have partially changed the actual peer addresses without updating the configuration view. Should I add .6 and .7 as neighbors, rebuild the gateway, or take another approach to restore BGP safely?
2 Answers
The immediate issue appears to be that the new gateway instances are using .6 and .7 as their actual BGP source addresses, while the FortiGate still expects .4 and .5. Confirm the addresses in the gateway's operational BGP view, then configure the FortiGate neighbors for .6 and .7 on the correct tunnel interfaces. Make sure the gateway subnet has routes that allow those addresses to reach the corresponding tunnels; without that, the new sessions may never establish. Reapply the AS-path prepending settings to the replacement neighbors as well.
Depending on the FortiGate design, you may also need eBGP multihop enabled. Validate the exact syntax and required hop count for this topology rather than copying a generic example. Azure custom APIPA BGP addresses can help avoid depending on automatically selected gateway addresses in future migrations.
A gateway replacement can consume different addresses from the gateway subnet, so the operational BGP endpoints may legitimately change during migration. However, the fact that the configuration view still advertises .4 and .5 while monitoring reports only .6 and .7 suggests more than a normal FortiGate-side change; it may be stale or incomplete Azure configuration state.
Before rebuilding everything, compare the effective BGP settings, connection-specific peer settings, gateway subnet routes, and tunnel associations. If the documented configuration cannot be updated to match the operational addresses, open an Azure support case and include the migration timestamp, both sets of peer addresses, and the BGP logs. Rebuilding could clear the inconsistency, but it is disruptive and should be a last resort after preserving the current configuration and confirming the replacement addresses.
The migration took roughly half an hour, and the mismatch has remained ever since. The primary session now works through .6, while .7 repeatedly attempts to connect to the backup firewall and is rejected as an unknown peer. I am leaning toward treating .6 and .7 as the effective addresses, but I want to avoid making the routing situation worse without resolving the stale Azure configuration first.
That is the confusing part: Azure's configuration page still lists .4 and .5, but the operational peer list and connection attempts only use .6 and .7. There is currently no configuration for .6 or .7 on either side, so I may need to add those neighbors or rebuild the gateway if the control-plane state is inconsistent.