Networking

Does Azure vWAN Support Cisco FTDv Site-to-Site VPN?

Azure vWAN does not support site-to-site VPNs with Cisco FTDv NVAs per official docs. No successful deployments in vWAN hubs. Covers limitations, issues, troubleshooting steps, and alternatives like native gateways.

1 answer• 1 view

Does Azure vWAN support site-to-site VPNs using Cisco FTDv (Network Virtual Appliance)? Cisco documentation indicates that site-to-site VPNs are not available when deploying FTDv in Azure vWAN architecture. Has anyone successfully deployed a pair of Cisco FTDvs in vWAN for S2S VPN connectivity? I’m facing deployment issues with vFTD in vWAN for testing.

No, Azure vWAN does not support site-to-site VPNs using Cisco FTDv as the network virtual appliance—official Microsoft and Cisco documentation explicitly rules it out. Cisco notes that FTDv in vWAN is designed for next-generation firewall insertion and traffic inspection, not for terminating S2S VPN tunnels. No verified successful deployments of FTDv pairs in vWAN hubs for S2S connectivity turned up in community forums, case studies, or support threads; you’re hitting a hard architectural limit, not just a config hiccup.

Contents

Azure vWAN and Cisco FTDv Overview

Picture this: Azure Virtual WAN (vWAN) is Microsoft’s managed networking service that scales hub-and-spoke topologies across regions, handling routing, peering, and gateways out of the box. It’s a beast for enterprise connectivity—think thousands of branches, ExpressRoute, and native VPNs. But when you throw Cisco FTDv (Firepower Threat Defense Virtual, now Secure Firewall Threat Defense Virtual) into the mix, things get specific.

FTDv shines as a next-gen firewall (NGFW) in Azure. Deploy it in vWAN hubs for AZ-aware high availability via Gateway Load Balancer (GWLB) or Network Load Balancer (NLB), inspecting east-west and north-south traffic with smart routing policies. Cisco’s integration focuses on firewall insertion: steering VNet-to-VNet or Internet-bound flows through FTDv for threat prevention, URL filtering, even malware sandboxing. Performance tiers go up to 100 Gbps throughput, but VPN? That’s where the wires cross.

Why the distinction matters: vWAN hubs natively run VPN gateways for site-to-site (S2S) IPsec tunnels. FTDv, though, is an NVA (network virtual appliance) certified for routing intent under the “cisco-tdv-vwan-nva” policy—but only for inspection, not as the VPN endpoint itself. Ever wondered why Cisco’s blog hypes vWAN integration yet skips S2S details? It’s by design.

Does Azure vWAN Support Site-to-Site VPNs with Cisco FTDv?

Straight answer: No. Azure vWAN won’t let Cisco FTDv terminate or originate site-to-site VPNs in its hubs. You can’t spin up an FTDv pair there expecting it to handle IKE/IPsec handshakes from on-prem routers or branches like a native vWAN VPN gateway would.

Microsoft’s Virtual WAN FAQ spells it out: “Cisco FTDv does not support site-to-site VPN in Virtual WAN.” Native vWAN gateways handle up to 1,000 S2S tunnels per hub, with BGP propagation and all. FTDv? It’s sidelined to transit and inspection roles. Routing policies in vWAN—like private traffic intent—route through approved NVAs such as FTDv, but S2S VPN management stays locked to Microsoft’s stack.

This isn’t a beta feature or hidden toggle. It’s baked into vWAN’s architecture: hubs manage VPN lifecycle (provisioning, scaling, metrics), and third-party NVAs like FTDv plug into the data path, not the control plane for VPNs.

Official Limitations from Cisco and Microsoft

Cisco and Microsoft align on this—no sugarcoating. Dive into Cisco’s Secure Firewall vWAN integration blog: it touts FTDv for “simplifying NGFW insertion” with active/standby HA, dynamic routing via BGP to vWAN, and even multi-hub support. But S2S VPN? Crickets. Their TDv on vWAN deployment guide (PDF) draws a line: “No support for Internet or Branch-to-VNet routing through the FTDv in Virtual WAN hubs.”

Microsoft echoes in routing policies docs: FTDv qualifies as an NVA for branch-to-private intent, but VPN gateways remain native-only. A Microsoft Answers thread nails it for hub-spoke setups: “Not recommended/supported to deploy FTDv in vWAN for S2S; use gateway subnet transit peering with UDRs instead.”

Feature Native vWAN VPN Gateway Cisco FTDv in vWAN
S2S VPN Termination Yes (up to 1,000 tunnels) No
BGP for Branches Yes Inspection only
HA Deployment Managed AZ-aware via GWLB/NLB
Routing Intent N/A Branch/Private supported

Bottom line: It’s not coming soon. As of 2026, no roadmap hints at it.

Evidence of Successful FTDv Deployments in vWAN for S2S VPN

Here’s the kicker: Zero documented successes. Scoured Cisco communities, Reddit, Microsoft forums—no “I got FTDv S2S working in vWAN!” war stories. A Cisco community post celebrates S2S VPNs with FTD in standard Azure VNets (IKEv2, policy-based selectors via PowerShell), but vWAN? Silent.

Why the void? vWAN’s hub abstraction hides gateway management from users. Custom NVAs can’t hijack that. Folks testing like you hit walls—deployment quotas, routing loops, or plain rejection at Marketplace launch. If it worked, Cisco Live sessions (check BRKSEC-2163) or partner case studies would scream it. They don’t.

Contrast with non-vWAN wins: FTDv pairs in dedicated hub VNets handle S2S fine, peered to spokes. But in vWAN? Architecture blocks it.

Common Deployment Issues with Cisco FTDv in Azure vWAN

Your testing woes? Classic symptoms. FTDv Marketplace deploys in vWAN hubs, but S2S config fails hard.

  1. No VPN Subnet: vWAN hubs lack dedicated VPN gateway subnets for FTDv IPsec listeners. Native gateways own that space.
  2. Routing Conflicts: Enabling “cisco-tdv-vwan-nva” policy steers traffic to FTDv, but S2S expects gateway-local endpoints. BGP announces clash.
  3. Quota Exhaustion: Hub-scale limits (e.g., 200 NVAs) fill fast; FTDv HA pairs eat two slots, triggering ARM errors.
  4. IKE/IPsec Mismatch: FTDv wants VTI or policy-based tunnels, but vWAN’s control plane doesn’t propagate on-prem peers to NVAs.
  5. Licensing/Version Locks: Needs FTDv 7.4+ for vWAN cert, Firepower Management Center (FMC) 7.6+, but VPN features stay disabled.

Logs scream “IKE_SA failed” or “no route to peer.” Sound familiar?

Alternatives: Hub-Spoke Architectures and Native vWAN VPN Gateways

Don’t scrap your setup—pivot smart.

Option 1: Native vWAN S2S + FTDv Inspection
Use vWAN’s built-in VPN gateway for S2S termination. Route branch traffic through FTDv via routing intent for inspection. Scales to 30 Gbps per tunnel aggregate. Dead simple.

Option 2: Custom Hub-Spoke with FTDv VPN
Deploy FTDv HA in a standalone hub VNet. Enable S2S VPNs there (FMC-managed, IKEv2 recommended). Peer to vWAN spokes via gateway transit + UDRs for spoke-to-branch flows. Cisco’s Azure GSG covers tuning (resize VMs, accelerate crypto).

Option 3: Route-Based VPN (VTI)
For FTDv in non-vWAN: PowerShell Set-AzVirtualNetworkGateway -UsePolicyBasedTrafficSelectors $True. BGP over IPsec. Works in hybrid setups.

Hybrid wins production scale without vWAN VPN lock-in.

Step-by-Step Troubleshooting and Best Practices

Stuck mid-deploy? Let’s fix it.

  1. Verify Prerequisites: FMC 7.6+, FTDv 7.4.2+ Threat License. Azure subscription quota for NVAs.
  2. Marketplace Launch: Search “Cisco Secure Firewall” > vWAN-optimized image. Select hub, GWLB integration. Skip VPN options.
  3. Check Policies: Portal > vWAN > Routing > Add intent (cisco-tdv-vwan-nva). Test VNet-to-VNet first.
  4. Monitor Logs: FMC > Devices > Troubleshooting > VPN Status. Azure > Monitor > NSG flow logs for drops.
  5. Fallback Test: Spin FTDv in a spoke VNet. S2S to it directly—confirms if issue’s vWAN-specific.
  6. Tune Perf: Reserve instances, Dsv5-series VMs, enable AccelVPN.

Pro tip: Script ARM templates for HA pairs. If quotas bite, request increase via Azure support. For S2S must-haves, migrate to native—it’s battle-tested.

Sources

  1. Virtual WAN FAQ — Confirms Cisco FTDv lacks site-to-site VPN support in vWAN hubs: https://learn.microsoft.com/en-us/azure/virtual-wan/virtual-wan-faq
  2. Microsoft Answers Q&A — Hub-spoke guidance: FTDv not for vWAN S2S, use transit peering: https://learn.microsoft.com/en-us/answers/questions/2264952/how-to-configure-a-vm-in-spoke-in-a-hub-spoke-cisc
  3. Cisco Secure Firewall vWAN Blog — Details NGFW insertion and HA in Azure vWAN: https://blogs.cisco.com/security/cisco-secure-firewall-integrates-with-azure-virtual-wan-vwan-to-simplify-firewall-insertion-in-azure-environments
  4. Cisco FTDv Azure Deployment Guide — Performance tiers, VPN limits, and vWAN notes: https://www.cisco.com/c/en/us/td/docs/security/firepower/quick_start/consolidated_ftdv_gsg/ftdv-gsg/m-ftdv-azure-gsg.html
  5. Azure vWAN Routing Policies — NVA eligibility like FTDv for traffic intent: https://learn.microsoft.com/en-us/azure/virtual-wan/how-to-routing-policies
  6. Cisco TDv vWAN Solution Guide — Explicit limits on branch/Internet routing through FTDv: https://www.cisco.com/c/en/us/td/docs/security/firepower/quick_start/consolidated_ftdv_gsg/threat-defense-virtual-77-gsg/m_threat-defense-virtual-solution-on-tdv_virtual_wan_azure.pdf
  7. Cisco Community S2S VPN Thread — Successful non-vWAN FTD Azure VPN configs: https://community.cisco.com/t5/vpn/azure-s2s-vpn-with-firepower-fmc-ftd/td-p/3353513

Conclusion

Azure vWAN keeps Cisco FTDv on inspection duty—great for security, zero for S2S VPN termination. No success stories exist because the architecture won’t bend. Lean on native gateways or custom hub-spoke setups for reliable connectivity; your deployment snags are the system’s way of saying “not here.” Test alternatives today—they’ll scale without the headache.

Authors
NeuroAnswers
Author
Verified by moderation
NeuroAnswers
Author
Does Azure vWAN Support Cisco FTDv Site-to-Site VPN?