Azure Site-to-Site VPN BGP Peering with APIPA Address not connecting

Question

Azure Site-to-Site VPN BGP Peering with APIPA Address not connecting

Trevor Reed 5

BGP peering between VpnGw1AZ gateway VPN01 and an external ISP is stuck in Connecting state indefinitely, with 0 messages sent/received in either direction.

Configuration confirmed correct:

Local Network Gateway gw01 has BGP peer IP set to APIPA address 169.254.21.1
Connection conn01 has gatewayCustomBgpIpAddresses correctly bound to 169.254.21.2
IPsec tunnel shows Connected with active bidirectional traffic (confirmed via az network vpn-connection show)
Gateway is VpnGw1AZ, Generation1, single-instance — SKU supports APIPA BGP addressing
Performed a full gateway reset (az network vnet-gateway reset) — no change

Issue: az network vnet-gateway list-bgp-peer-status persistently reports localAddress: 10.91.1.254 (the default GatewaySubnet IP) for both BGP peers, instead of the expected custom APIPA address 169.254.21.2. This appears to contradict documented Azure behavior, which states the gateway should automatically use the custom APIPA address when the corresponding LNG has an APIPA peer IP configured.

I am looking for any tips and assistance on configuring this BGP peering

Vinayteja Lellela 110 Reputation points Microsoft External Staff Moderator

2026-08-07T00:45:30.49+00:00

Hello @Trevor Reed , I have converted the comment into answer. I hope this has been helpful!

Please don’t forget to close the thread by clicking "Accept the answer" and "Yes" wherever the information provided helps you, as this can be beneficial to other community members.

3 answers

Your answer

Vinayteja Lellela 110 Reputation points Microsoft External Staff Moderator

2026-08-07T00:45:30.49+00:00

Hello @Trevor Reed , I have converted the comment into answer. I hope this has been helpful!

Please don’t forget to close the thread by clicking "Accept the answer" and "Yes" wherever the information provided helps you, as this can be beneficial to other community members.

Answer 1

Hello Trevor Reed,

It sounds like you’ve done the right high-level setup (LNG BGP peer IP set to the APIPA address, connection binding set, tunnel shows Connected), but BGP never establishes and list-bgp-peer-status keeps reporting the Azure “localAddress” as the default GatewaySubnet IP (for example 10.91.1.254) instead of the custom APIPA BGP address (169.254.21.2).

A couple things from Microsoft’s documented behavior are important here:

1) Azure only uses the custom Azure APIPA BGP when the LNG peer IP is APIPA

Azure VPN Gateway’s behavior is:

By default, Azure assigns a private IP from GatewaySubnet as the Azure BGP peer IP.
The custom Azure APIPA BGP address is used only if the corresponding Local Network Gateway has an APIPA address configured for the on-premises BGP peer.
If the LNG peer is not APIPA (or doesn’t match as expected), the gateway “reverts” to the private GatewaySubnet address.

So the symptom you’re seeing (Azure localAddress shown as the GatewaySubnet IP) generally points to: Azure doesn’t consider the configured LNG BGP peer as APIPA for that session, even if the portal/CLI you checked suggests it is. This is especially relevant with APIPA because there are strict matching expectations.

2) APIPA peer / BGP sessions are expected to be initiated by the on-premises device

Microsoft notes a key limitation for APIPA-based BGP on VPN Gateway:

When APIPA is used as BGP addressing, Azure does not initiate BGP peering sessions with APIPA source IPs.
The on-premises VPN device must initiate the BGP session.

So “tunnel Connected but BGP Connecting indefinitely with 0 messages” is consistent with the on-premises side not successfully reaching/starting the session (common culprits: reachability/routing to the Azure APIPA peer, TCP/179 allowed, no NAT, correct ASN/OPEN expectations, etc.).

3) Common causes when APIPA BGP adjacency stays in Connecting

Based on the troubleshooting guidance for BGP on Azure VPN Gateway, the most frequent APIPA/BGP blockers are:

Incorrect Azure BGP peer IP (APIPA mismatch) (even off-by-one cases, wrong side reversed, or not actually taking the custom APIPA)
ASN mismatch (Azure default ASN is 65515 unless overridden)
APIPA reachability issues inside the tunnel
NAT applied to APIPA traffic (should be none for APIPA BGP)
Missing static route to Azure’s APIPA via the tunnel interface on the on-premises device
Local/Remote peer reversed (Azure = local in APIPA terms; on-premises = remote, as per the doc guidance)

4) Also double-check the APIPA address pairing rules

From the APIPA selection guidance:

APIPA addresses should be in the Azure-reserved VPN range (169.254.21.0 – 169.254.22.255).
If you use a /30, AWS uses the first IP and Azure uses the second (the doc includes an example of 169.254.21.1 vs 169.254.21.2).
If multiple APIPA BGP peer addresses are configured, you must configure all Connection objects to match them; otherwise Azure can fall back to the first APIPA in the list (this is an important “gotcha” if you have multiple sessions).

Even though your case sounds like single-peer, it’s still worth confirming you don’t have multiple APIPA peers configured on the gateway and only bound one connection correctly.

Can you please update us if the action plan provided was helpful?

Should there be any follow-up questions or concerns, please let us know and we shall try to address them.

If these answer your question, click "Upvote" which may be beneficial to other community members reading this thread.

Answer 2

Trevor Reed 5

Vinayteja Lellela's comment above resolved this

Vinayteja Lellela 110 Reputation points Microsoft External Staff Moderator

2026-08-05T17:04:48.5633333+00:00

Hello @Trevor Reed , I have converted the comment into answer. I hope this has been helpful!

Please don’t forget to close the thread by clicking "Accept the answer" and "Yes" wherever the information provided helps you, as this can be beneficial to other community members.

Answer 3

For APIPA-based BGP on Azure VPN Gateway, the supported behavior is:

The IPsec tunnel must be up first. That is already satisfied because the connection is Connected.
The local network gateway must use the APIPA BGP peer IP.
The VPN gateway must have a matching custom Azure APIPA BGP IP configured from the allowed Azure VPN APIPA range 169.254.21.0 to 169.254.22.255.
APIPA addresses must not overlap between the on-premises device and Azure gateway.
The on-premises BGP device must initiate the BGP session. When APIPA addresses are used, Azure VPN Gateway does not initiate BGP peering with APIPA source IP addresses.

Given the current symptoms:

IPsec is established
BGP is stuck in Connecting
0 messages are sent and received

The most relevant checks are:

In Azure portal, go to Virtual network gateway > Configuration and verify the gateway actually shows the custom Azure APIPA BGP IP address as 169.254.21.2.
In Local network gateway > Configuration, verify the BGP peer IP is 169.254.21.1.
On the external ISP device, verify it is configured to peer to Azure’s APIPA BGP IP 169.254.21.2 and to initiate the BGP session.
Verify the remote ASN configured on the ISP side matches the Azure gateway ASN, and that the Azure ASN and on-premises ASN are different.
Verify the ISP device is not peering to the gateway public IP or default GatewaySubnet BGP IP instead of the configured APIPA BGP IP.
Verify TCP port 179 is not blocked between the BGP peers across the tunnel.

For diagnostics, enable gateway diagnostic logs:

Go to Virtual network gateway > Diagnostic settings > Add diagnostic setting.
Enable RouteDiagnosticLog and IKEDiagnosticLog.
Send logs to Log Analytics.
Query BGP events:

AzureDiagnostics
| where Category == "RouteDiagnosticLog"
| where OperationName == "BgpConnectedEvent" or OperationName == "BgpDisconnectedEvent"
| project TimeGenerated, OperationName, Message, Resource
| order by TimeGenerated desc

Interpretation:

If there are no BGP connect events, the on-premises or ISP device is typically not initiating toward the Azure APIPA address.
If BgpConnectedEvent appears and is quickly followed by BgpDisconnectedEvent, check ASN mismatch, TCP 179 filtering, or hold timer incompatibility.

About localAddress: 10.91.1.254 in list-bgp-peer-status: the available documentation confirms that when the local network gateway uses an APIPA BGP peer IP, Azure VPN Gateway chooses the custom APIPA address for that connection. The documentation provided does not describe CLI output behavior for list-bgp-peer-status, so the actionable path is to validate the configured APIPA values on the gateway and local network gateway, and then confirm that the external device is initiating to 169.254.21.2.