Forum Widgets
Latest Discussions
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.
Azure VM Persistent Route Setup
Hi I hope to get some advice on a routing issue from Azure to an on-premises system. A little background first, please bear with me: We have an on-premises VM that connects to an isolated Thirdparty network via an On-Prem Cisco ASA FW specifically for this purpose. ------------------------------------------------------------------------------- OnPrem VM's IP: 10.100.10.23/24 OnPrem dedicated FW - Local Inside Interface IP: 10.100.10.190 -------------------------------------------------------------------------------- OnPrem dedicated FW - 3rdParty Interface IP: 10.110.255.137 Thirdparty router IP: 10.110.255.138 - This routes to aditional devices on 10.10.227.10 and 20.10.227.10. -------------------------------------------------------------------------------- There are static routes configured for 3rd party FW interface using: 3rdParty Interface - 10.10.227.10 255.255.255.255 - 10.110.255.138 (Gateway IP) 3rdParty Interface - 20.10.227.10 255.255.255.255 - 10.110.255.138 (Gateway IP) -------------------------------------------------------------------------------- The on-premises VM (10.100.10.23) has persistent routes added to allow connectivity: Network Address Netmask Gateway Address Metric 10.10.227.10 255.255.255.255 10.100.10.190 1 20.10.227.10 255.255.255.255 10.100.10.190 1 10.110.255.136 255.255.255.252 10.100.10.190 1 --------------------------------------------------------------------------------- The above works fine on-prem but I now need to migrate the On-Prem VM service into Azure. Azure Side I have created a test Azure VM with a static IP in an isolated subnet (no other devices using it) in the Production subscription of our LZ (Hub and Spoke topology). We have a site-to-site VPN connected to our on-premises FW using a VPN Gateway configured in the Connectivity subscription of our LZ (as expected). We have defined subnets for on-premises address spaces in the Local Network Gateway: 10.100.10.0/24, 10.100.11.0/24, 10.100.13.0/24, 10.100.14.0/24 (Local Subnets) and 172.16.50.0 (VPN client Subnet) --------------------------------------------------------------------------------------- Main Problem that I'm requesting advice for: When I add the defined persistent routes on the Azure VM (IP address: 10.150.1.10/24) as is on the On-Prem VM Network Address Netmask Gateway Address Metric 10.10.227.10 255.255.255.255 10.100.10.190 1 20.10.227.10 255.255.255.255 10.100.10.190 1 10.110.255.136 255.255.255.252 10.100.10.190 1 I'm unable to ping the 10.10.227.10 and 20.10.227.10 addresses, even though the routes have been added by the 3rd party on their network side. All Network Objects, static routes, groups and rules are duplicated on the ASA FW for the Azure VM as is for the On-Prem VM and I can access/ping the ASA FW inside interface no problem . Is there a specific way I need to route the persistent routes from Azure side, have I missed something in the configuration above to get the connectivity I require? Please all advice is welcomed! Thank you NitroxHelp! - 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.
Help ! - Hub Spoke Architecture and Routing via NVA
I have a classic example of routing. I want to force all traffic via Fortigate firewalls. EastWest and NorthSouth. However when large Supernet of Azure Vnet is used to route and force the traffic via UDR at gateway subnet, its not working. Because Routes learned at Hub Vnet via Vnet peering is taking precedence. To isolate, i have created multiple small subnet routes for Gateway subnet. Each pointing to spoke vnet and next hop as Fortigate firewall. However this is working, i want to make solution solid. Means if someone creates new vnet in future and peer with Hub, it should not get direct traffic. Is that possible? Or this is typical shortcoming of Azure where routing works with preference to vnet peeering.? Below is architecture -docker - Azure Container Instance - how to make my container accesable and recognized from outside?
I have windows container which should access to external VM database (that is not in container, lets say VM1) so I would define for them l2bridge network driver in order to use the same Virtual Network. docker network create -d "l2bridge" --subnet 10.244.0.0/24 --gateway 10.244.0.1 -o com.docker.network.windowsshim.vlanid=7 -o com.docker.network.windowsshim.dnsservers="10.244.0.7" my_transparent So I suppose we need to stick on this definitely. But now as well I need to make my container accessible from outside, on port 9000, from other containers as well as from other VMs. I suppose this has to be done based on its name (host name) since IP will be changed after the each restart. How I should make my container accessible from some other VM2 virtual machine - Should I do any modifications within the network configuration? Or I just to make sure they are both using the same DNS server? Of course I will do the expose of the port, but should I do any kind of additional network configuration in order to allow traffic on that specific port? I've read that by default network traffic is not allowed and that Windows may block some thing. I will appreciate help on this. Thanks
IKEv2 and Windows 10/11 drops connectivity but stays connected in Windows
I’ve seen this with 2 different customers using IKEv2 User VPNs (virtual wan) and Point to Site gateways in hub and spoke whereby using the VPN in a Always On configuration (device and user tunnel) that after a specific amount of time (56 minutes) the IKEv2 connection will drop the tunnel but stay connected in Windows. To restore the connection, you just reconnect. has anyone else had a similar experience? I’ve seen the issue with ExpressRoute and with/without Azure firewalls in the topology too.
How can I convert an website on Microsoft to IOS?
Hello everyone, Hope you all are doing good, I am Jeck. I have a website which I design and developed on my apple machine and basically made on IOS. Now, I want to change my website to Microsoft, my website is on https://www.bestelectricsmoker2021.com/ Can you guide me porperly or suggest me anyone who can work for me and extend my bussiness on Micosoft. Thank you Have a good day!Office-js addin with webapi in Api management. Failed to fetch
Hello. My application contains one office-js addin (typescript) project + one Webapi core (c#) project, both communicating through a fetch function when cors is enabled.It works together properly on my local computer. I published : - the webapi on azure api management (https://docs.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-rest-api). Test gaves a 200 OK. - the Office addin on azure. It works properly (as long the fetch function is not involved). However when used, fetch function raises errors (message = "failed to fetch").The issue may be about proper ssl certificates as described in : https://docs.microsoft.com/en-us/office/dev/add-ins/concepts/requirements-for-running-office-add-ins. Is it a possible solution ? I tried with self signed certificate with no success so far. Is there any tutorial explaining how to implement it ? Any help would be appreciated
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?
