I have an Azure VPN Gateway with two connections to our on-premises site, each using a separate Internet connection. BGP is configured with AS-path prepending so the primary link is always preferred and traffic does not route asynchronously.
This worked normally until Azure migrated the gateway from the Basic SKU to Standard. Before the migration, the FortiGate was configured with Azure BGP peers x.x.x48.4 and x.x.x48.5. The primary BGP session is still established, but its remote router ID is now x.x.x48.6. The secondary session toward x.x.x48.5 has remained in the Active state for weeks.
Azure's BGP monitoring now shows local addresses x.x.x48.6 and x.x.x48.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 connection attempts from x.x.x48.7 being rejected because no matching peer is configured.
The confusing part is that the gateway configuration still lists .4 and .5 as the default BGP peer addresses, while monitoring and route information only reference .6 and .7. It looks like the migration changed the effective peer addresses but did not update every part of the configuration. Should I add .6 and .7 as FortiGate neighbors, rebuild the gateway, or handle this another way?
2 Answers
The migration may have created replacement gateway instances that took the next available addresses in the gateway subnet. That would explain why the operational BGP view shows .6 and .7 even though the saved connection settings still contain .4 and .5.
Before rebuilding everything, capture the current gateway, connection, BGP, and route configuration and open an Azure support case describing the mismatch between the configured peer addresses and the operational local addresses. A rebuild could work, but it may also discard useful evidence or reproduce the same behavior. If the operational peers really are .6 and .7, the on-premises firewall must be prepared to accept those addresses; otherwise the secondary session will continue to be rejected.
The immediate issue is probably that the new gateway instances selected different BGP addresses during the migration. The FortiGate will reject .7 until it has a neighbor definition for that address, so compare the effective addresses shown in Azure monitoring with the configured neighbors on the firewall.
If .6 and .7 are the actual Azure-side peers, update the FortiGate neighbors accordingly, verify the required routes from those addresses to the correct tunnel interfaces, and reapply the AS-path prepending policy. Depending on the FortiGate configuration, eBGP multihop may also be required. Validate the exact syntax and behavior for your FortiOS version before changing production settings.
For future gateway deployments, consider explicitly configuring custom APIPA BGP addresses instead of relying on automatically selected gateway-subnet addresses. That makes migrations and replacements less likely to change the peer identities unexpectedly.
That is the confusing part: Azure's main configuration still lists .4 and .5, so neither Azure nor the firewall has any explicit configuration for .6 and .7. Only the monitoring and BGP views show the new addresses. I may try adding .6 and .7 as neighbors, but it feels like the migration left the gateway in an inconsistent state.
The migration was performed automatically and took roughly half an hour. The configuration view still shows .4 and .5, but the BGP peer monitoring view has only .6 and .7, with .7 unable to connect. That makes me suspect the migration did not finish cleanly rather than simply changing the expected addresses.