Hey folks! 👋 I've been deep in the trenches with our on-prem WatchGuard Firebox and needed to connect it securely to an Azure VNet for a hybrid setup. After some trial and error, I got a clean, working site-to-site tunnel going. Thought I'd share my notes in case anyone else is navigating this.
My setup was a Firebox M390 (running Fireware OS) talking to an Azure VPN Gateway (Route-Based, VpnGw1 SKU). The key pieces you'll need to align are:
* **Azure Side:** Virtual Network Gateway, Local Network Gateway (representing your on-prem setup), and the Connection resource.
* **Firebox Side:** A BOVPN virtual interface (I used route-based with IKEv2).
The trickiest part was getting the Phase 1 and Phase 2 (IPsec) proposals to match exactly. Azure can be a bit particular here. My working config used:
* **IKEv2:** SHA256 for integrity, DH Group 14 for PFS.
* **IPsec:** ESP with SHA256 and AES-256-GCM for encryption, PFS disabled (using "No-PFS" on Azure side, which maps to the Firebox's "none" setting for Perfect Forward Secrecy).
A couple of gotchas I ran into:
* Make sure your on-prem network IP range in the Azure Local Network Gateway is a **superset** of what you're actually routing. I had a typo in a subnet mask that caused hours of headache!
* Double-check that your Firebox's BOVPN interface has the correct Azure Gateway IP and that your policy allows the traffic.
* Use the Firebox's live log viewer during the connection attempt—it's way more helpful than the Azure logs for debugging the tunnel itself.
Once the tunnel was up, I just added static routes on the Firebox pointing my Azure VNet ranges to the BOVPN virtual interface. It's been rock solid for a few weeks now, handling our backup traffic beautifully.
Anyone else set this up recently? Found any alternative configurations that work better or have tips for automating the key rotation?
Happy hacking!
Happy hacking!
Your point about the Azure Local Network Gateway IP range needing to be a superset is critical. I've seen this cause asymmetric routing that's difficult to diagnose, where the tunnel establishes but specific subnets are unreachable.
A related caveat: while your cryptographic settings are correct for a standard tunnel, if you're routing any traffic that falls under regulatory compliance like PCI DSS, using "No-PFS" for Phase 2 can be a compliance failure. The VpnGw1 SKU supports DH Group 14 for IPsec PFS; it's worth the minor performance hit to enable it in those scenarios to avoid a costly audit finding.
Have you measured the tunnel's maximum throughput against the VpnGw1's published specs? In my tests, the real-world encrypted throughput often settles around 650 Mbps, not the advertised 1.25 Gbps, which becomes a capacity planning issue.
Trust but verify.