Having recently completed a deployment of WatchGuard Firebox appliances (predominantly T35 and T55 models) across our distributed network to serve approximately 150 users, I believe a detailed, empirical post-mortem is in order. The transition was from a legacy, software-based firewall system, and the goal was to unify security policy, improve VPN performance, and gain better visibility into application-layer traffic. As is typical with any infrastructure shift of this scale, the outcome is a mixed bag of resounding successes and frustrating, time-consuming failures.
The following is a structured analysis of what broke (and why) versus what performed admirably. I will focus on concrete configuration challenges, performance observations, and specific feature interactions.
### What Broke & Configuration Pitfalls
* **SD-WAN Auto-Route Failover with Dual WISPs:** We configured two wireless ISP connections for several remote sites using the SD-WAN feature. While basic failover worked, the **auto-route metrics** were problematic. The default health-check sensitivity caused flapping during minor latency spikes. We had to implement more conservative, custom probes to specific reliable endpoints (e.g., a core DNS server) rather than generic `8.8.8.8`.
```bash
# Example of a more robust probe we deployed via CLI
configure
set sdwan probe "Google_DNS" type icmp host 8.8.8.8 interval 3 threshold 3
set sdwan probe "Internal_DNS" type icmp host 10.10.10.10 interval 5 threshold 5
set sdwan group "WAN_Group" probe "Internal_DNS" primary
```
* **Root Cause:** Default settings are optimized for stable, wired connections and do not account for the inherent volatility of consumer-grade wireless links.
* **Legacy Application Compatibility with Deep Packet Inspection:** Several internal, older applications (a proprietary FTP-based data sync tool and a SOAP API service) immediately failed. The issue was traced to **HTTP Server Validation** and **Intrusion Prevention** signatures within the "Reconnaissance" category that were enabled by default in our chosen "Strict" policy template. Creating application-specific exceptions was necessary, which somewhat eroded our "default deny" posture for those segments.
* **BOVPN (Branch Office VPN) Throughput Discrepancy:** The documented throughput for the T35 (450 Mbps) and T55 (900 Mbps) is for firewall traffic. **IPSec VPN throughput is significantly lower.** We saw real-world encrypted tunnel speeds of ~90 Mbps on the T35, which was adequate for most sites but required re-routing high-volume backup traffic to off-peak hours. This wasn't a "break," but a major planning miscalculation.
### What Worked Exceptionally Well
* **Unified Policy Management with WatchGuard Cloud:** The shift from device-by-device management to a single pane of glass for policy deployment and monitoring was the project's biggest win. Pushing a new rule blocking a malicious domain or adjusting a QoS policy across 15 devices took minutes. The logging and reporting pipeline into our SIEM (via the cloud's Syslog forwarding) was also seamless.
* **Key Feature:** The ability to stage a policy configuration and deploy it to a test group before global rollout prevented at least two major outages.
* **Client VPN (WatchGuard Mobile VPN with IKEv2):** The deployment of certificate-based IKEv2 VPN for remote users was flawless. Connection stability improved dramatically over our previous solution, and the integration with Azure AD for authentication streamlined user onboarding. The per-user bandwidth reporting was invaluable for diagnosing performance complaints.
* **Application Control & User Awareness:** The granularity of application identification allowed us to move from port-based rules to true application-aware policies. For example, we can now permit `MicrosoftTeams-Video` while restricting generic `STUN` traffic. Mapping policies to Active Directory users (rather than just IP addresses) has also significantly reduced our incident response time for compromised accounts.
In conclusion, the WatchGuard Firebox rollout was a net positive, but the devil is in the pre-deployment testing. The assumed throughput and the default security template behaviors were our primary points of failure. For organizations of similar size, I would strongly recommend a prolonged pilot phase that includes **real-world failover testing** and **a full inventory of legacy applications** to be whitelisted. The management and reporting capabilities, however, have provided a robust foundation for our next project: implementing Zero Trust Network Access modules.
Data is the source of truth.