We’ve hit an odd snag with our Palo Alto PA-820 firewall, which serves as the core of our IPsec VPN setup connecting multiple branch offices. It’s been humming along, linking our sites—some with just a handful of devices, others packed with access points (APs), PDAs, and PCs. But recently, we’ve noticed a problem that’s got us scratching our heads: when one VPN tunnel’s bandwidth usage climbs past 14MB, not only does that tunnel get shaky, but it drags down the others too. Here’s what we’ve seen and what we’re doing about it.
Scenario
Our PA-820 (11.1.4-h7) sits at the core of our network, running site-to-site IPsec VPN tunnels to various branch offices. Some of these remote sites are busier than others—think lots of wireless APs, handheld PDAs, and PCs churning through data. Normally, this works fine, keeping everything connected and secure. But trouble brews when the bandwidth on any single tunnel spikes.
The Problem
Here’s the kicker: if one tunnel’s usage exceeds around 14 Mbps, it doesn’t just struggle on its own—it disturb the other vpn tunnel. The affected tunnel becomes unreliable, with latency spikes or dropped connections, and then the other tunnels start feeling the pain too. It’s like one overworked runner tripping up the whole relay team. Sites with more devices seem to hit this threshold faster, but the ripple effect hits everyone.
What We’ve Observed
- Trigger Point: The instability kicks in when a tunnel’s bandwidth tops 14MB. Below that, things run smoothly.
- Cross-Tunnel Impact: Even tunnels with low usage get jittery when one goes over the limit—suggesting a shared resource bottleneck.
- Hardware or Firmware? We’re not sure yet if this is a hardware limitation on the PA-820 or a firmware glitch. The PA-820 is rated for 1.2 Gbps of IPsec VPN throughput, so 14MB shouldn’t be a ceiling—or so we’d think.
Workaround: QoS to the Rescue
To keep things stable for now, we’ve customized Quality of Service (QoS) on the PA-820. We’ve capped the total bandwidth per tunnel at 14 Mbps (megabits this time, not megabytes—about 1.75 MB), with traffic type classification to prioritize critical flows. This stops any tunnel from crossing the 14MB threshold and dragging the others down. It’s not perfect—some sites might feel the squeeze—but it’s holding the line while we figure this out.
Root Cause: Still Digging
We don’t know the root cause yet—is it hardware choking under load or a firmware quirk? We’re opening a TAC case with Palo Alto to investigate. Meanwhile, we’re zeroing in on a few suspects:
Encryption Algorithm Choice: Are we hitting a processing limit with our current cipher setup? These could tie into how the PA-820 handles multiple tunnels under stress. We’ll test adjustments and share what we find.
MTU and MSS: Could packet fragmentation or size mismatches be clogging things up?
Next Steps
We’re opening a TAC case with Palo Alto to dig deeper. Is this a hardware constraint, maybe tied to how the PA-820 processes multiple tunnels? Or could it be a firmware bug messing with resource allocation? We’ll share updates once we hear back. For now, we’re keeping an eye on bandwidth, tweaking where we can, and hoping for a fix—because no one likes a VPN domino effect.
Stay with us, if we have got any latest update will share here.