Business Challenge
BGP has been doing quiet work in the background of this whole networking run. #78 put it second in the route-selection priority order; #79 used it as one of two ways to force-tunnel; #75 noted that ExpressRoute has no alternative to it. This post is the protocol itself.
The framing in the documentation is a straight swap: “BGP is an optional feature you can use with Azure Route-Based VPN gateways… It’s the equivalent of using static routes (without BGP) vs. using dynamic routing with BGP.” On ExpressRoute there is no swap available at all: “With ExpressRoute you must use BGP… while with VPN you can optionally use BGP.”
What the swap framing hides is that turning BGP on hands several decisions to Azure, and takes a few away from you. Four of them are worth knowing before the first peering attempt:
| What you would naturally do | What actually happens |
|---|---|
Use 65515 — a tidy private ASN | It is Azure's own default, and reserved against you |
| Advertise your virtual network's own prefix | Filtered, if gateway transit is on |
| Tune the keepalive and hold timers | Fixed at 60 and 180 seconds |
| Advertise a few thousand routes | 4,000, and exceeding it drops the session |
None of those is unreasonable. All four are the kind of thing discovered during a maintenance window rather than during design.
Architecture
Prerequisites: two exclusions, and one service where it is not optional
| Condition | Rule |
|---|---|
| Gateway SKU | “BGP is supported on all Azure VPN Gateway SKUs except the Basic SKU” |
| VPN type | “BGP is supported on route-based VPN gateways only” — not policy-based |
| ExpressRoute | Mandatory, not optional |
Both VPN exclusions were already implied by earlier posts. #73 found Basic lacks BGP in the SKU table and that policy-based is a dead end for nearly everything; this is the same conclusion arriving from the routing side. If a design needs dynamic routing, Basic and policy-based are both out before the conversation starts.
The ASN rules, and the number that is both default and forbidden
| Category | Values |
|---|---|
| Reserved by Azure — public | 8074, 8075, 12076 |
| Reserved by Azure — private | 65515, 65517, 65518, 65519, 65520 |
| Reserved by IANA | 23456, 64496–64511, 65535–65551, 429496729 |
| Usable private | 64512–65514 and 65521–65534 |
One of those public numbers should look familiar: 12076 is the ExpressRoute ASN from #75. Azure reserves it globally rather than only on circuits, so a lab that picked it as an arbitrary on-premises ASN will fail against a VPN gateway too.
The two usable ranges hold 1,017 numbers between them, which is ample — but the prohibition matters more than the supply, because “You can’t specify these ASNs for your on-premises VPN devices when you’re connecting to VPN gateways.” This is not advice about collisions; it is a rejected configuration.
And 32-bit ASNs work, with a tooling caveat that matches the pattern from #79's Default Site: “Azure VPN Gateway now supports 32-bit (4-byte) ASNs. To configure by using ASN in decimal format, use Azure PowerShell, the Azure CLI, or the Azure SDK.” No portal.
Why This Architecture Holds Up
Because 65515 is simultaneously the default and off-limits
Read these two statements together, because they appear in different answers on the same page:
“Azure VPN gateways have a default ASN of 65515 assigned, whether BGP is enabled or not for your cross-premises connectivity.”
And in the reserved list: “Private ASNs: 65515, 65517, 65518, 65519, 65520” — which you “can’t specify… for your on-premises VPN devices”.
That is coherent once stated — Azure holds the number on its own side, so you cannot also hold it on yours — and it is the single most likely first failure, because 65515 is a natural pick from the private range and it is the number already visible on the gateway blade. Somebody reading the gateway's own ASN and mirroring it on the on-premises device has chosen a configuration Azure will refuse.
The underlying rule is more general and worth stating separately: “No. You must assign different ASNs between your on-premises networks and your Azure virtual networks.” Same ASN on both sides is not supported regardless of which number it is.
One detail in that default worth keeping: the ASN exists “whether BGP is enabled or not”. So every VPN gateway has an autonomous system number sitting on it, used or not, and changing it later is permitted — “you can change the ASN after the gateway is created” — which is a rarity in this series, where most things decided at creation stay decided.
Because the reserved and usable lists do not quite meet
A small gap, noted because anyone deriving a value programmatically from these lists will hit it. Azure's reserved private ASNs are 65515, 65517, 65518, 65519, 65520. The usable ranges are 64512–65514 and 65521–65534.
65516 falls in neither list. It is not named as reserved by Azure or IANA, and it is not inside either usable range — the first range stops at 65514 and the second starts at 65521.
I am not going to guess what Azure does with it. The operational conclusion is the safe one: treat the usable ranges as authoritative rather than deducing availability from the absence of a number in the reserved list. The two lists are not complements, and a script that computes “everything private that is not reserved” will propose at least one value the documentation never sanctions.
Because whether you may advertise a prefix depends on a peering setting
This is the most consequential rule on the page, and it is conditional on something configured somewhere else entirely:
| Gateway transit | Can you advertise your VNet's exact prefix? |
|---|---|
| Enabled | “You cannot… Azure blocks or filters the advertisement of any prefixes that match your virtual network address prefixes. However, you can advertise a prefix that is a superset” |
| Not enabled | “The gateway does not learn peered virtual network prefixes, allowing you to advertise the exact prefixes as your peered virtual network” |
The worked example is precise and a little surprising: “if your virtual network uses the address space 10.0.0.0/16, you can advertise 10.0.0.0/8, but not 10.0.0.0/16 or 10.0.0.0/24.”
Note that /24 is blocked too. A more specific prefix inside your virtual network's space is refused, not just the exact match — so the filter is on overlap with the virtual network range, not on equality. The only direction that works is outward: a supernet.
That matters because gateway transit is the setting #71 and #77 both treated as a thing you turn on to let spokes use the hub's gateway. Turning it on is how a hub-and-spoke estate works — and it is also what starts filtering your on-premises advertisements. An advertisement that was accepted before someone enabled gateway transit on the hub peering will stop being accepted afterwards, and nothing about the advertisement changed.
The general form of the same rule appears on the BGP overview too: “the prefixes can’t be identical with any one of your VNet prefixes. Those routes identical to your VNet prefixes will be rejected.” And it is consistent with #78's carve-out, where virtual network system routes “are preferred… even if BGP routes are more specific”. Azure protects its own view of the virtual network's address space from BGP, at both the acceptance and the selection stage.
Because the prefix ceiling drops the session, not the surplus
“Azure VPN Gateway supports up to 4,000 prefixes. The BGP session is dropped if the number of prefixes exceeds the limit.”
That is the same failure mode #75 found on ExpressRoute, where “the default behavior when BGP session prefix limits are exceeded is to terminate the session”, and the same number as ExpressRoute private peering's default IPv4 limit. So both hybrid connectivity options converge on 4,000 and on dropping the peering rather than ignoring the excess.
The consequence is that the prefix count is a availability parameter rather than a capacity one. Crossing it does not degrade routing, it removes it — and because the trigger is a count your on-premises side controls, a routine summarisation change at the other end of the tunnel can take the session down. The mitigation is the one #75 named and #78 repeated: summarise on-premises to the largest ranges possible, and monitor the count rather than the session.
Because the timers are fixed, so the mismatch is yours to avoid
“The BGP keepalive timer is 60 seconds, and the hold timer is 180 seconds. Azure VPN Gateways use fixed timer values and do not support configurable keepalive or hold timers.”
The ratio is the conventional 3:1, which is reassuring, and the consequence is stated plainly: “on-premises devices should be configured with matching timer values, as mismatched settings may result in BGP instability.”
Since only one side can be changed, the configuration burden is entirely on the device you own. A hold timer of 180 seconds also sets the floor on failure detection: a dead peer is not noticed for up to three minutes, which is the number to put next to any availability claim about automatic failover.
And the usual remedy for that latency is unavailable here: “Azure VPN Gateways do not support Bidirectional Forwarding Detection (BFD) for site-to-site (S2S) VPN connections.” Which is a direct contrast with the other hybrid option, where #76 found BFD “is configured by default on all Private Peerings on ExpressRoute circuits”. Sub-second failure detection on a circuit; three minutes on a tunnel.
Because the Address space field does two jobs once BGP is on
The local network gateway's Address space field is where you declare on-premises prefixes without BGP. With BGP it changes meaning, and the documentation flags its own reversal:
“Important: This is a change from the previously documented requirement. Azure VPN Gateway adds a host route internally to the on-premises BGP peer IP over the IPsec tunnel. Don’t add the /32 route in the Address space field, because it’s redundant.”
And if you use APIPA for the peer, the field will not take it: “you can’t add it to this field”.
The part to internalise is what the field does with anything else you put in it: “If you add any other prefixes in the Address space field, they’re added as static routes on the Azure VPN gateway, in addition to the routes learned via BGP.”
So on a BGP connection that field is not documentation of the remote network, it is a static route table that coexists with the dynamic one. Leftover prefixes from a pre-BGP configuration do not become inert when BGP is enabled — they keep being installed, and they will outlive a BGP withdrawal. That is the mechanism by which a decommissioned on-premises range stays reachable in Azure long after the other side stopped advertising it.
Worth pairing with #78's finding that disabling gateway route propagation “applies to both static routes and BGP routes”. Both kinds arrive through the same channel, and both disappear together.
Because the peer addresses come from the gateway subnet, and the rules on your side are narrow
Azure's side is automatic: “Azure VPN Gateway allocates a single IP address from the GatewaySubnet range for active-standby VPN gateways, or two IP addresses for active-active… allocated automatically when you create the VPN gateway.” You read it back from the bgpPeeringAddress property.
That is one more reason the gateway subnet sizing argument in #77 matters: BGP consumes addresses from it, two of them in the active-active configuration that #73 recommended because it costs the same as active-passive.
Your side has two prohibitions and one recommendation: the on-premises peer address “must not be the same as the public IP address of your VPN device or from the VNet address space of the VPN gateway… It can be an address assigned to the loopback interface”. A loopback is the right answer and the one that survives an interface flapping.
One asymmetry worth knowing for firewall rules: “VPN gateways initiate BGP peering sessions to the on-premises BGP peer IP addresses… by using the private IP addresses on the VPN gateways.” Azure calls you, from a private address, and your device needs a host route pointing that address down the tunnel — “if the Azure VPN peer IP is 10.12.255.30, you add a host route for 10.12.255.30 with a next-hop interface of the matching IPsec tunnel interface”.
Because transit routing works, with one thing it will never carry
BGP is what makes VPN gateways transitive, which is the exception to the non-transitivity theme running through #71 and everything after it: “BGP can also enable transit routing among multiple networks by propagating routes a BGP gateway learns from one BGP peer to all other BGP peers.”
Two conditions and one permanent exclusion:
- “To enable transit routing across multiple VPN gateways, you must enable BGP on all intermediate connections” — one non-BGP hop breaks the chain.
- “VPN gateways don’t advertise default routes to other BGP peers” — so a default route learned at one site is not propagated onward.
That second one is a useful safety property rather than a limitation. It means a site advertising 0.0.0.0/0 — the BGP method of forced tunnelling from #79 — cannot accidentally force-tunnel every other site in the mesh through its own perimeter. The blast radius of an accidental default route stops at the gateway that learned it.
Worth restating what accepting that default route does locally, because the documentation is explicit about both effects: “advertising the default route forces all VNet egress traffic toward your on-premises site. It also prevents the virtual network VMs from accepting public communication from the internet directly, such as… RDP or SSH.” One advertisement, two consequences, and the second one locks out the management path people use to investigate the first.
Key Architecture Decisions
| Decision point | Choose | Because |
|---|---|---|
| A design needing dynamic routing | Route-based, not Basic | BGP is unsupported on Basic and on policy-based gateways. |
| Picking an on-premises ASN | From 64512–65514 or 65521–65534 |
Those are the stated usable private ranges, 1,017 numbers in total. |
| Mirroring the gateway’s visible ASN | Don’t | 65515 is Azure’s default and reserved against you. |
| Deriving available ASNs programmatically | Use the usable ranges, not “not reserved” | 65516 appears in neither list, so the two are not complements. |
| Reusing one ASN on both sides | Don’t | Different ASNs are required, whatever the numbers. |
| An arbitrary lab ASN | Avoid 12076 |
That is the ExpressRoute ASN and Azure reserves it. |
| Using a 4-byte ASN | PowerShell, CLI or SDK | Decimal-format configuration is not available in the portal. |
| Enabling gateway transit on a hub | Re-check your on-premises advertisements | It starts filtering prefixes that match virtual network space. |
| Advertising your own virtual network range | A supernet only | A /16 VNet permits /8, but not /16 or /24. |
| Approaching the prefix limit | Summarise on-premises, and alert on the count | 4,000 prefixes, and exceeding it drops the session rather than the surplus. |
| Promising a failover time | Budget the 180-second hold timer | Timers are fixed and BFD is unsupported on site-to-site VPN. |
| Configuring the on-premises BGP timers | Match 60 and 180 exactly | Only your side is adjustable, and mismatch causes instability. |
| Needing sub-second detection | ExpressRoute, not VPN | BFD is on by default on ExpressRoute private peerings. |
| The local network gateway Address space field | Treat it as a static route list | Anything there is installed as a static route alongside BGP routes. |
| Migrating a connection to BGP | Clear out the old prefixes | They persist as static routes and survive a BGP withdrawal. |
The peer /32 in Address space |
Leave it out | Azure adds that host route internally; the guidance changed. |
| On-premises BGP peer address | A loopback | It cannot be the device’s public IP or in the gateway’s VNet space, and a loopback survives interface flaps. |
| Using APIPA for the peer | Also set Azure APIPA BGP addresses | Required when the on-premises BGP IP is in 169.254.x.x. |
Sizing GatewaySubnet |
Remember BGP consumes addresses from it | One for active-standby, two for active-active. |
| Firewall rules for the peering | Expect Azure to initiate, from a private address | And add a host route for that address down the tunnel. |
| Transit routing across gateways | Enable BGP on every intermediate connection | One non-BGP hop breaks the chain. |
| Worrying that one site’s default route will capture the mesh | Don’t | VPN gateways never advertise default routes onward. |
| Accepting a default route over BGP | Keep a management path that is not RDP or SSH from the internet | It also blocks VMs accepting direct inbound internet traffic. |
| Redundant tunnels to one site | BGP on both, and count them against the quota | Both tunnels consume the gateway’s tunnel allowance. |
| Multiple tunnels between two virtual networks | At least one gateway in active-active | Stated requirement for that topology. |
| Any estate-wide propagation policy | Exempt GatewaySubnet |
Disabling propagation there stops the gateway functioning. |
Closing Thought
The static-versus-dynamic framing is accurate and incomplete. Enabling BGP does replace hand-maintained prefixes with learned ones, and it does buy real capabilities — automatic withdrawal on tunnel failure, transit between sites, advertisement as small as a single host route. It also moves four decisions out of your hands: the ASN space you may occupy, which of your prefixes Azure will accept, how fast a dead peer is noticed, and how many routes may exist before the session rather than the surplus is discarded.
Two of those four are conditional on things configured elsewhere, which is what makes this an architecture topic rather than a device-configuration one. Whether Azure accepts your virtual network's prefix depends on whether somebody enabled gateway transit on a peering, possibly in another team's hub. And whether the routes you declared in the Address space field are documentation or active static routes depends on whether BGP is on — with the uncomfortable property that enabling BGP does not retire them.
The number I would carry into an availability conversation is 180 seconds. The hold timer is fixed, BFD is unsupported on site-to-site VPN, and together those set the floor on how long a failed tunnel can keep attracting traffic before BGP withdraws its routes. Active-active tunnels with automatic failover are a genuine capability and they are not fast; a design that needs faster than three minutes needs a circuit, where detection is on by default, rather than a better-configured tunnel.
#81 moves to the managed alternative that has been the road not taken for the last several posts: Azure Virtual WAN — what a hub actually is, what Microsoft operates on your behalf, and which of the controls from the customer-managed design you give up to get it.
Official Azure Reference
- Azure VPN Gateway FAQ, BGP and routing section — the reserved and usable ASN ranges, the default ASN, the peer address and APIPA rules, the Address space field change, what Azure advertises, the 4,000-prefix limit, the fixed timers, the BFD exclusion and the gateway transit filtering rule
- About BGP with VPN Gateway — what BGP enables, the minimum-prefix and multiple-tunnel capabilities, transit routing, and the rejection of prefixes identical to virtual network prefixes
- Azure virtual network traffic routing — BGP’s place in the route selection priority, the system-route carve-out that outranks it, per-subnet propagation of advertised prefixes, and the gateway subnet propagation prohibition
- ExpressRoute circuit configuration workflow — the ExpressRoute ASN of 12076 that appears in Azure’s reserved public list
- About ExpressRoute Direct — BFD being configured by default on private peerings, which site-to-site VPN does not support
- ExpressRoute circuits and peering — the matching session-termination behaviour when a BGP prefix limit is exceeded
- Configure BGP for Azure VPN Gateway — the step-by-step including APIPA peer configuration (no claims drawn from it)
Comments