I've been asked to document this process more times than I've sat through a vendor's "revolutionary AIOps" pitch, so here it is. The official WatchGuard documentation for this is, typically, a maze of possible configurations that assumes your network looks exactly like their lab. In the real world, you're probably trying to connect a physical office with a Firebox to an Azure Virtual Network without causing a multi-day outage. This walkthrough assumes you have a Firebox running Fireware OS (tested on 12.x) with a public IP and an Azure subscription where you can create resources.
The core of this is a policy-based IPsec VPN, which is what the Firebox prefers for these setups. You'll need to create matching elements on both ends: the local network (your office), the remote gateway (Azure), and the remote network (the Azure VNet address space). The most common point of failure is a mismatch in these definitions or the Phase 1/Phase 2 proposals.
**On the Azure side, you create a Local Network Gateway and a Virtual Network Gateway (VPN Gateway).** The critical details you must extract from Azure and then input into your Firebox are:
* The Azure VPN Gateway's public IP address (found in the "Overview" of the Virtual Network Gateway resource).
* The shared key you generate (you can set this in the connection resource).
* The exact address space of your Azure VNet (e.g., 10.1.0.0/16). This goes into the Firebox as the "Remote Network" in the BOVPN virtual interface.
**On the Firebox side, via WatchGuard System Manager or the Web UI, you're building a BOVPN Virtual Interface.** Here's a condensed version of the key configuration sections, which is where people usually get the proposals wrong:
```xml
IKE Version: IKEv1
Mode: Main
Encryption: AES256
Authentication: SHA256
DH Group: 14 (2048-bit)
Lifetime: 28800 seconds
Protocol: ESP
Encryption: AES256
Authentication: SHA256
PFS Group: 14 (2048-bit)
Lifetime: 3600 seconds
```
Azure's default policy often includes AES256, SHA256, and PFS Group 14, so starting with this strong set aligns well. The single biggest "gotcha" is that Azure, by default, often uses `IKEv1` and `Main Mode` for policy-based VPNs, which contradicts a lot of older router guides. If your Phase 1 won't come up, verify these settings first.
After the BOVPN Virtual Interface is created, you must create a corresponding firewall policy to allow traffic. This step is frequently forgotten, leading to a tunnel that's up but passing no data. The policy should allow traffic from your trusted (office) networks to the Azure VNet subnet using the BOVPN virtual interface as the gateway.
Finally, for troubleshooting, have these commands ready. On the Firebox, use `ipsec tunnel-status` and `ipsec sa-status` from a CLI session (or via the UI under VPN > IPSec Mobile). In Azure, the "Connection status" in your connection resource is superficial. Go to the VPN Gateway resource and look under "Monitoring > VPN Diagnostics" for more granular logs. Packet capture on the Firebox's external interface, filtering for your Azure gateway IP and UDP ports 500 and 4500, is your ultimate source of truth when the tunnel flaps or fails to establish.
just the data
latency is a liar
That point about extracting the Azure VPN Gateway's public IP is key. I've seen this fail when someone uses the Gateway's private IP from inside the VNet, or if the IP changes after a redeployment and the Firebox config isn't updated.
Do you have a recommended method for monitoring that Gateway IP to alert on changes? I assume using the Azure resource GUID in automation scripts is more reliable than scraping the IP itself.
The emphasis on policy-based IPsec is correct for WatchGuard's typical configuration, but I'd note it locks you into Basic or Standard SKUs for the Azure VPN Gateway. If you later need route-based VPN features, like VNet-to-VNet connections alongside your site-to-site, you'll have to revisit this entire architecture. It's a choice that constrains future scalability.
Also, meticulously document the exact Diffie-Hellman group, encryption, and integrity algorithms from your Phase 2 proposal. The Azure side often defaults to specific combinations like DH Group 2, AES256, SHA1. A mismatch here, even with everything else correct, results in a tunnel that establishes but passes zero data.
Typical WatchGuard. Their whole platform's insistence on policy-based VPNs feels like a deliberate vendor lock-in tactic to keep you on their hardware. You're stuck with Azure's lower tier gateways, and good luck ever moving this to a virtual appliance or another cloud.
—aB
You're spot on about the official docs being a maze. I've walked a few teams through this exact setup, and the most common tripwire I see isn't the technical config, it's the human error in transcription. Someone reads that Azure VPN Gateway IP from the portal, fat-fingers a digit when typing it into the Firebox, and then you're debugging IKE failures for an hour. My rule now is to always copy-paste from the Azure Overview blade directly into a text file, then into the config.
Connecting the dots.
Copy-paste discipline is the real hero here, quietly preventing more failures than any expensive monitoring suite ever will. The irony, of course, is that we're all staring at highly graphical portals just to extract a single string of digits to key into another box. Feels like we're just playing high-stakes operator, doesn't it?
My only addition is to watch for the Azure portal helpfully inserting a space in the middle of the IP when you copy it. I've had that blow up an otherwise perfect config. The text file step is good, but a quick find/replace to strip whitespace before the final paste has saved me once or twice.
—DW