My First TechCommunity Post: Azure VPN Gateway BGP Timer Mismatches
This is my first post on the Microsoft TechCommunity. Today is my seven-year anniversary at Microsoft. In my current role as a Senior Cloud Solution Architect supporting Infrastructure in Cloud & AI Platforms, I want to start by sharing a real-world lesson learned from customer engagements rather than a purely theoretical walkthrough. This work and the update of the official documentation on Microsoft Learn is the culmination of nearly two years of support for a very large global SD-WAN deployment with hundreds of site-to-site VPN connections into Azure VPN Gateway. The topic is deceptively simple—BGP timers—but mismatched expectations can cause significant instability when connecting on‑premises environments to Azure. If you’ve ever seen seemingly random BGP session resets, intermittent route loss, or confusing failover behavior, there’s a good chance that a timer mismatch between Azure and your customer premises equipment (CPE) was a contributing factor. Customer Expectation: BGP Timer Negotiation Many enterprise routers and firewalls support aggressive BGP timers and expect them to be negotiated during session establishment. A common configuration I see in customer environments looks like: Keepalive: 10 seconds Hold time: 30 seconds This configuration is not inherently wrong. In fact, it is often used intentionally to speed up failure detection and convergence in conventional network environments. My past experience with short timers was in a national cellular network carrier between core switching routers in adjacent racks, but all other connections used the default timer values. The challenge appears when that expectation is carried into Azure VPN Gateway. Azure VPN Gateway Reality: Fixed BGP Timers Azure VPN Gateway supports BGP but uses fixed timers (60/180) and won’t negotiate down. The timers are documented: 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. This behavior is consistent across supported VPN Gateway SKUs that offer BGP support. Unlike some on‑premises devices, Azure will not adapt its timers downward during session establishment. What Happens During a Timer Mismatch When a CPE is configured with a 30‑second hold timer, it expects to receive BGP keepalives well within that window. Azure, however, sends BGP keepalives every 60 seconds. From the CPE’s point of view: No keepalive is received within 30 seconds The BGP hold timer expires The session is declared dead and torn down Azure may not declare the peer down on the same timeline as the CPE. This mismatch leads to repeated session flaps. The Hidden Side Effect: BGP State and Stability Controls During these rapid teardown and re‑establishment cycles, many CPE platforms rebuild their BGP tables and may increment internal routing metadata. When this occurs repeatedly: Azure observes unexpected and rapid route updates The BGP finite state machine is forced to continually reset and re‑converge BGP session stability is compromised CPE equipment logging may trigger alerts and internal support tickets. The resulting behavior is often described by customers as “Azure randomly drops routes” or “BGP is unstable”, when the instability originates from mismatched BGP timer expectations between the CPE and Azure VPN Gateway. Why This Is More Noticeable on VPN (Not ExpressRoute) This issue is far more common with VPN Gateway than with ExpressRoute. ExpressRoute supports BFD and allows faster failure detection without relying solely on aggressive BGP timers. VPN Gateway does not support BFD, so customers sometimes compensate by lowering BGP timers on the CPE—unintentionally creating this mismatch. The VPN path is Internet/WAN-like where delay/loss/jitter is normal, so conservative timer choices are stability-focused. Updated Azure Documentation The good news is that the official Azure documentation has been updated to clearly state the fixed BGP timer values for VPN Gateway: Keepalive: 60 seconds Hold time: 180 seconds Timer negotiation: Azure uses fixed timers Azure VPN Gateway FAQ | Microsoft Learn This clarification helps set the right expectations and prevents customers from assuming Azure behaves like conventional CPE routers. Practical Guidance If you are connecting a CPE to Azure VPN Gateway using BGP: Do not configure BGP timers lower than Azure’s defaults Align CPE timers to 60 / 180 or higher Avoid using aggressive timers as a substitute for BFD For further resilience: Consider Active‑Active VPN Gateways for better resiliency Use 4 Tunnels commonly implemented in a bowtie configuration for even better resiliency and traffic stability Closing Thoughts This is a great example of how cloud networking often behaves correctly, but differently than conventional on‑premises networking environments. Understanding those differences—and documenting them clearly—can save hours of troubleshooting and frustration. If this post helps even one engineer avoid a late‑night or multi-month BGP debugging session, then it has done its job. I did use AI (M365 Copilot) to aid in formatting and to validate technical accuracy. Otherwise, these are my thoughts. Thanks for reading my first TechCommunity post.
Help! - How is VNet traffic reaching vWAN/on‑prem when the VNet isn’t connected to the vWAN hub
Hello, I needed some clarity on how the following is working: Attached is a network diagram of our current setup. The function apps (in VNet-1) initiate a connection(s) to a specific IP:Port or FQDN:Port in the on-premises network(s). A Private DNS zone ensures that any FQDN is resolved to the correct internal IP address of the on-prem endpoint. In our setup, both the function app and the external firewall reside in the same VNet. This firewall is described as “Unattached” because it is not the built-in firewall of a secured vWAN hub, but rather an independent Azure Firewall deployed in that VNet. The VNet has a user-defined default route (0.0.0.0/0) directing all outbound traffic to the firewall’s IP. The firewall then filters the traffic, allowing only traffic destined to whitelisted on-premises IP: Port or FQDN: Port combinations (using IP Groups), and blocking everything else. The critical question and the part that I am unable to figure out is: Once the firewall permits a packet, how does Azure know to route it to the vWAN hub and on to the site-to-site VPN? Because VNet-1 truly has no connection at all to the vWAN hub (no direct attachment, no peering, no VPN from the NVA). But the traffic is still reaching the on-prem sites. Unable to figure out how this is happening. Am I missing something obvious? Any help on this would be appreciated. Thank you!
Traffic processing BGP Azure VPN gateway A/A
Hello, Can someone explain how Azure processes the traffic with implemented a VPN gateway in Active Active mode?. Azure firewall premium is also configured. BGP is without preferences. The user route definition is set up to the next hop Azure firewall . Is it possible in this scenario occurs the asymmetric routing with traffic drop by azure firewall ? In my understand is that, if we need to configure User route definition on Gateway subnet to inspect traffic to peering subnet, so the firewall don't see traffic passing through VPN gateway. Traffic going through ipsec tunnels can go different paths and firewall do not interfere because everything is routed to it by user route definition.
Networking out Private VNET in AZURE with a third party app such as payment gateway?
I need to do networking so that my VNET in Azure connects to third party applications such as payment gateways or messaging apps which are in Public internet. Please let me know the options and why we should prefer one over the other?
Spoke-Hub-Hub Traffic with VPN Gateway BGP and Firewall Issue
Hello, I’m facing a situation where I’m trying to have Azure Firewall Inspection on the VPN Gateway VNET-VNET Connectivity. It seems to work if I go from SpokeA-HubAFirewall-HubAVPN—HubBVPN-SpokeB but if I try to go from SpokeA-HubAFirewall-HubAVPN-HubBVM or Inbound Resolver it fails to route correctly according to Connectivity Troubleshooter it stops at HubAVPN with Local Error: RouteMissing but then reaches destination health so makes me believe it’s getting there but not following the route I want it to take which might be causing routing issues. What Am I missing here? This connectivity was working before introducing the Azure Firewall for Inspection with the UDR. Is what I’m trying to accomplish not possible? I’ve tried different types of UDR rules on the Gateway Subnet, and this is my most recent configuration. The reason I’m trying to accomplish this is because I’m seeing a similar error in our Hub-Spoke Hybrid environment and I’m trying to replicate the issue. Current Configuration 2x Hubs with Spoke networks attached so example Hub-Spoke-A Configuration: Hub-A Contains following subnets and Resources VPN Gateway - GateWaySubnet Azure Firewall - AzureFirewallSubnet Inbound Private Resolver - PrivateResolverSubnet Virtual Machine – VM Subnet Gateway Subnet has an attached UDR with the following routes Propagation - True Prefix Destination – Hub-B Next Hop Type – Virtual Appliance Next Hope IP – Hub-A Firewall Prefix Destination – Spoke-B Next Hop Type – Virtual Appliance Next Hope IP – Hub-A Firewall Hub-Spoke-B Configuration: Hub-B Contains following subnets and Resources VPN Gateway - GateWaySubnet Azure Firewall - AzureFirewallSubnet Inbound Private Resolver - PrivateResolverSubnet Virtual Machine – VM Subnet Gateway Subnet has an attached UDR with the following Routes Propagation - True Prefix Destination – Hub-A Next Hop Type – Virtual Appliance Next Hope IP – Hub-B Firewall Prefix Destination – Spoke-A Next Hop Type – Virtual Appliance Next Hope IP – Hub-B Firewall Spoke Subnets has an attached UDR with the following Routes Propagation - True Prefix Destination – 0.0.0.0/0 Next Hop Type – Virtual Appliance Next Hope IP – HubA/HubB Firewall (Depending on what hub its peered to) VPN Gateways HA VNET-VNET with BGP Enabled. I can see that it knows the routes and like I said this was working prior introducing the UDRs for force traffic through the azure firewall.
Can only remote into azure vm from DC
Hi all, I have set up a site to site connection from on prem to azure and I can remote in via the main dc on prem but not any other server or ping from any other server to the azure. Why can I only remote into the azure VM from the server that has Routing and remote access? Any ideas on how I can fix this?
Route-metrics in Azure P2S VPN
We have the following setup in our environment: Azure VPN Gateway S2S-VPN between gateway and our on-premise datacentre. P2S-VPN between gateway and clients. This P2S VPN is configured with AAD-authentication and the VPN profile is assigned to a client via Intune and XML-configuration. I have attached a stripped down version of our .xml with information that is not sensitive. (azurevpn.xml). It's in the zipped file. This setup is working overall fine, we add some routes to direct the traffic to the right place. We also have a management-VPN deployed that some of our employees use to get access to our network equipment and other administrative devices. This is a Cisco Anyconnect VPN. When connected to both this VPN-profile and the AzureVPN it let's them traverse both the management-net and the "customer"-net and let's them query DNS in both nets. The Anyconnect-VPN just as the AzureVPN has routes assigned to it, which when connected, one of the routes gets assigned a metric of 35. When then the P2S-VPN is connected it assigns the metric 311 on the same route. 311 seems to be the "default" metric on the routes specified in our .xml. This causes the issues in our case and we need to assign a metric lower then 35 to the P2S-route. Is there any way to assign a metric to a route that we push with the .xml? According to the Microsoft Docs here https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-profile-intune which links to this Docs https://docs.microsoft.com/en-us/windows/client-management/mdm/vpnv2-csp says you are able to do this. However if we try to add for example "<metric>25</metric> to the xml this gets ignored on the client. I have attached a section of the AzureVpnCxn.log which is stripped of sensitive information where this can be seen. Please advicePlease clarify for required certificates for P2S connection in Azure
Hi, For Point-to-Site connection in Azure, certificates of Windows are exported. Depending on Windows system, I have seen different situation in certmgr.msc as below 1st Windows system 2nd Windows system 3rd Windows system Please let me know Which certificates we need to export at certmgr.msc? If we need to export Personal certificate, what I need to do, if no certificates are showing or another certificates (like Adobe) are showing at Personal? Please clarify with additional required information. We’ll be thankful for your assistance. With Regards NndnG
