The most likely culprit sounds like something between the cable modem and the Firebox. Maybe it's an issue with the Firebox dealing with ICMP, or maybe it's a real problem.

It sounds like you're already pinging through the tunnel and around the tunnel (as outlined here: http://www.nessoft.com/kb/28).

I'd start out by trying to correlate the packet loss you see in PingPlotter with your VPN problems. If you're getting failure to connects at just the same time that PingPlotter is showing packet loss, but the VPN performance is OK when PingPlotter is showing no packet loss, then this would be a strong correlation, and you know it's not just an oddity with the way the Firebox is handling PingPlotter data.

VPNs are notoriously poor at passing PingPlotter data (and ICMP / traceroute data), so you really need to make sure the problem you're chasing is a real one, not just a red herring because of limitations in the VPN stack.

If you're having some problems correlating PingPlotter data with your user's problem, try to Ping the final destination only (in PingPlotter, View -> Ignore First Hops -> Ping Final Hop Only) because this can be more reliable with some VPNs.

Once you've correlated the PingPlotter data with the VPN problems, I'd get in touch with Watchguard and see if they have some idea of what's causing this problem. Maybe it's a configuration parameter where the bandwidth is being artificially constrained through the VPN, even though the bandwidth through the cable modem is not saturated, or maybe there is some packet priority setting that's causing packet loss.

Good luck!

- Pete