I’ve spent a lot of years doing “traditional” networking. ASIC-based switches, hand-built BGP adjacencies, both sides of every connection configured and verified before I’d trust it. So when I recently went deep into deploying Cisco FTDv firewalls as Network Virtual Appliances (NVAs) into an Azure Virtual WAN vHub, I expected the usual: configure my side, configure Azure’s side, watch the neighbour come up.
That’s not what happened. And that gap between what I expected and what actually happens is, I think, the single most important thing to explain to any network person making this jump. So that’s where I’m going to start.
Azure Doesn’t Want You to Touch It, and That Feels Like a Trust Issue
Here’s the thing that will throw you off if you’ve done “real” networking for a while: in Azure Virtual WAN, you don’t configure the other side of the BGP relationship.
Enable Routing Intent on the Azure Portal, and Azure will start BGP peering with your NVA. You will never see a BGP neighbour listed in the portal for it. Not because something’s broken — because Azure never asked you to configure one. The Azure vHub router’s ASN isn’t something you set either; it’s Azure system-assigned the moment the hub gets created. Make sure you’re aware of these Azure ASN reservations so you don’t accidently use them (internet search “azure reserved asn numbers”).
With Routing Intent, there are no Azure route tables to babysit either. Routing Intent is a one and done affair.
If you’re coming from traditional networking, this is going to feel like a trust issue. You’re used to being able to see both sides of an adjacency. In Azure, half of it is invisible to you by design. My advice: don’t fight it. Follow the vendor’s Azure-specific onboarding document (in my case, Cisco’s FTDv guide) to the letter, and stay away from general Azure BGP documentation while you’re doing it. The general docs describe a different mental model and will just confuse you mid-deployment.
The IP Address That Isn’t “For Example”
Buried in the Cisco documentation is a line that says “For example: 168.63.129.16.” I want to flag this specifically because I think it’s a trap.
168.63.129.16 is not an example. Type that exact address. It’s Azure’s “magic” virtual IP — a fixed address, consistent in every single Azure region, that serves as the dedicated endpoint for DNS, DHCP, and health probes. If you read past that line assuming it’s a placeholder like most documentation examples are, your health probe will never work, and neither will your BGP pairing, because Azure won’t consider your NVA operational until that probe succeeds.
A few more things in this same neighbourhood that got flagged as “explain this clearly or someone will burn a day on it”:
- The internal load balancer’s health probe needs a static route configured on the NVA side, and the FTDv’s HTTP server needs to be enabled with an ACL letting that probe through on the internal interface.
- Your static routes to the Azure vHub gateway need to stay at metric 1. The NVA isn’t directly connected to the vHub router, so it has to reach it via static route — and if that route’s metric is higher than BGP’s default of 20, you’ll get route flapping.
- Under BGP advanced settings, check the box for “Disable Connection Verification.” Azure needs it checked.
- You do not need a user-defined route (a UDR, in Azure-speak) on the vHub side. If you’re hunting for where to add one, stop — there isn’t one. Again, Azure Routing Intent is one-and-done, there is nothing to do on the Azure side of things. Likely the issue is on the NVA side so go back to the vendor NVA documentation and triple check everything.
Sizing Your Hub: The Decision You Don’t Get a Second Chance At
This next part isn’t a “gotcha,” it’s just math that’s easy to skip past during initial design and painful to discover later. Making this error means standing up a new Data Centre or having multiple Data Centres. The networking world is working on 10-20 year cycles, not the faster server world cycles of 5-10 years. We want to make design decisions that last.
Every Azure Virtual WAN hub reserves a fixed pool of IP addresses for NVA subnets, and that pool size is locked in by the hub’s address space when it’s created. It doesn’t matter whether you’re using the capacity or not — it’s static, and changing it later means rebuilding.
Here’s how the address space choice plays out:
| vWAN Hub Address Space (for NVA vNet allocation) | IPs per NVA subnet | Max Scale units per NVA as dictated by Vendor (example Cisco with Cisco’s max throughput figures) | Max vHub theoretical limit with all 16 NVAs deployed |
|---|---|---|---|
| /23 or smaller | 11 | 40 | 288 Gbps |
| /22 | 27 | 80 | 480 Gbps |
| /21 | 59 | 80 | 480 Gbps |
| /20 or larger | 123 | 80 | 480 Gbps |
Pick a /23, and you’re capped at 288 Gbps hub-wide and 40 scale units per NVA. Go to /22 or bigger and both numbers jump — 480 Gbps and 80 scale units. My recommendation is at least a /22. Honestly, since most organizations aren’t using this private address space for anything else, I’d go as far as suggesting a /20 just to future-proof against whatever Azure changes down the road. It costs you nothing today. The maximum number of NVAs per hub is always 16, regardless of size — so this decision is really about how big each of those 16 can eventually get (Azure scaling with additional VMs), not how many you can deploy.
Flow Limits: The Outage Nobody Notices Coming
If you only budget for bandwidth, you’re going to get burned by this one.
Every VM, and therefore every NVA, has a maximum bidirectional flow limit — and for an NVA it is half of what the underlying VM’s rated connection capacity is — and this is a hard spike ceiling, not a long-term average. Blow past it, and connections get dropped. Not politely refused. Just dropped. The client machine keeps retrying a TCP handshake that will never finish, and to the end user, it looks like the app is frozen or spinning forever, with zero indication of why.
This always matters but it matters more if your NVA is doing double duty. An NVA handling both north/south and east/west traffic — which is a pretty normal pattern for an Azure landing zone — is eating into its flow budget from two directions at once, and needs to be sized accordingly from day one, not after the help desk tickets start rolling in. Be mindful of where the backups are going, that’s going to be the big flow generator if it goes via the firewall.
Should You Cluster the FTDvs? My Answer: Probably Not
Azure High Availability is not supported with clustering. That one line should stop you before you get excited about clustering as the “enterprise” answer. In Azure, the only reason to cluster is to auto scale and that introduces complexity most enterprise organizations don’t need.
Without clustering, Azure’s built-in internal load balancer already does most of what you’d want:
- Traffic is already load balanced to all the VM FTDv instances in the NVA by default.
- Want to pull a VM FTDv in the NVA out of service? Remove its health probe static route. Done — traffic stops immediately.
- Scale up and add a new VM FTDv instance? It comes up without an active health probe route, so it stays silent until you deliberately turn it on.
That’s a manual process, sure. But it’s predictable and low-drama, and it doesn’t drag in the cost and operational overhead of a full autoscaling pipeline — which for FTDv means standing up Azure Function Apps and Logic Apps and a whole different deployment process. For a shop that isn’t building toward serious autoscaling, that complexity isn’t buying you much.
Clustering on in Azure with Cisco FTDv also comes with a list of unsupported features so always be careful to read the caveats before implementing . What might not be supported? This is the list for Cisco: remote access VPN (SSL VPN and IPsec VPN, site-to-site VPN, Virtual Tunnel Interfaces (VTIs), High Availability, Integrated Routing and Bridging, to name a few — plus real operational care and feeding: disabling health checks around any topology change, never pulling more than one node out of a scale set at a time, disabling clustering on a node before removing it. None of that is a dealbreaker if you need clustering. It’s just a cost you should go in knowing about.
My take: clustering earns its complexity when you’re actually building toward autoscaling. If you’re not there yet, the built-in load balancer and manual scaling gets you the same outcome with a lot less to manage.
Where This Leaves You
If there’s one idea I want a traditional networking person to walk away with, it’s this: Azure Virtual WAN isn’t hiding half the configuration from you out of carelessness. It already did that half of the work before you logged in. The ASN you never set, the BGP neighbour you’ll never see in the portal, the route table you configure once and never touch again — none of it is missing. It’s just handled.
The engineers who get comfortable with this fastest are the ones who stop hunting for the configuration step that isn’t there, and start trusting the health probes and Routing Intent to do the job that “both sides configured” used to do by hand.
About the Author
Trevor Textor specializes in solving problems that have organizations stuck. That means he does pretty broad things from A-Z and somewhere in there yes, he helps out with networking. Sharing what he learns the hard way is a hallmark of Trevor’s work. Ask Trevor if he can help: anyskill.ca/afc-capability-matrix.