After a six-month evaluation and a three-month phased rollout, we have successfully migrated our primary corporate and development VPN/secure access infrastructure to Barracuda CloudGen WAN. The deployment now serves approximately 300 concurrent users across three geographic regions. While the platform delivers on its core promise of a unified SD-WAN and firewall fabric, several production pitfalls emerged that were not apparent during the limited-scale proof of concept. These issues primarily reside in the intersection of configuration granularity, operational visibility, and unexpected latency profiles.
The most significant challenge was the nuanced behavior of the "Secure Access" client under specific, but common, network transition scenarios. The documentation suggests seamless handover between networks, but we observed consistent session drops when users migrated from a wired corporate network (with an on-premise firewall path) to a home Wi-Fi network (taking a direct cloud path). The session re-establishment delay averaged 8-12 seconds, which was disruptive for persistent SSH and database connections.
* **The root cause** was not the path switch itself, but the firewall's state table management and the client's delayed dead peer detection. The default timeouts were not aligned with rapid network mobility.
* **Our mitigation** involved adjusting the IKE and IPSec SA lifetimes and enabling `Aggressive Dead Peer Detection` on the client profile. Crucially, this change had to be propagated not just to the firewall objects, but to the Centralized Management template, which then required a non-disruptive, but staged, push to all connected gateways.
```yaml
# Snippet from the modified Secure Access Client Profile template
vpn_client_profile {
ike_lifetime_seconds = 3600
ipsec_lifetime_seconds = 2800
dpd_interval = 5
dpd_retries = 3
# The 'aggressive' mode is enabled via the CLI, not this UI template.
}
```
A second, more insidious, pitfall was the performance of the cloud-delivered Threat Prevention and Intrusion Prevention features when enabled in "Inline" mode for all traffic. While the security posture was excellent, we saw a 40-70ms additive latency penalty for east-west traffic between our own regional hubs, which was unacceptable for our internal API calls. The latency was not in the packet processing, but in the logging and reporting pipeline, which appeared to be serialized in a way that blocked the fast-path until certain analytics events were queued.
* **We resolved this** by creating a more refined security policy. We applied full IPS/AV scanning only to traffic destined for the internet or unknown internal segments. For trusted inter-hub traffic (defined by specific CIDR ranges), we created a separate rule with only basic firewall checks, effectively bypassing the deep inspection stack. This required meticulous address object management.
From a monitoring standpoint, the built-in Barracuda CloudGen Portal provides high-level health but lacks the granular, exportable metrics needed for our existing Grafana dashboards. For example, extracting per-rule hit counts or detailed tunnel latency percentiles over API was not straightforward. We had to deploy custom collectors that parsed the firewall's local SNMP MIBs directly, bypassing the cloud portal for these specific datasets.
In summary, the platform is stable at scale, but its true operational cost lies in the need for hyper-specific policy tuning to match real-world user mobility and internal traffic patterns. The "set and forget" model promised for SD-WAN does not fully extend to the Secure Access use case without significant configuration depth. I am interested to hear if others have encountered similar issues with session persistence or inspection latency, and what specific tuning parameters you found most effective.
brianh