A slow session in WatchGuard Mobile VPN with SSL is a symptom with at least five distinct families of cause: the remote network you sit on, the encryption overhead of the tunnel itself, packet size problems that throttle every large transfer, capacity limits on the Firebox or the office line, and routing choices that send traffic on a longer journey than it needs. Each family has a different fix, and each produces a slightly different pattern of slowness, which is why measurement comes before tuning.
Start by separating expectations from measurements. "It feels slow" cannot be diagnosed; "a 200 MB file takes four minutes and the same file takes twelve seconds on the office LAN" can be. Gather one clean number before touching anything: how long does a representative transfer actually take, on the network you actually use?
Establish a baseline on both sides of the tunnel
Run a speed test on the remote network with the tunnel disconnected, note the result, then connect and run a transfer to an internal resource. If the raw remote connection is already poor, the VPN is a passenger, not the culprit — no client setting will manufacture bandwidth that the hotel Wi-Fi does not have. If the raw connection is healthy but tunnelled transfer collapses, the loss happens inside the tunnel, and that is a much more specific problem.
Compare an upload against a download as well. Asymmetric home lines are common, and a session that feels fine for reading email can be genuinely unusable for sending large files, because the upstream that must carry your encrypted traffic is a fraction of the downstream. Knowing which direction is slow points at a line characteristic rather than a configuration error.
Account for encryption overhead honestly
A TLS-based tunnel wraps every packet in additional headers and performs cryptographic work on both ends. Some loss relative to the raw line is inherent and healthy — it is the price of the protection. Expect a well-functioning tunnel to achieve somewhat less than the raw connection, not equal to it, and treat a modest reduction as normal rather than as a fault to be eliminated.
The encryption work itself is cheap on modern CPUs, but on very old hardware — an ageing laptop or an underpowered router doing its own heavy work — it is not free. If throughput improves dramatically when tested from a newer machine on the same network, the bottleneck was the device's processor, and no tunnel setting will change that.
Investigate MTU and fragmented packets
The classic hidden cause of "fine for small files, hopeless for large ones" is a packet size problem. Tunnel headers enlarge every packet, and if the effective maximum transmission unit along the path is exceeded, packets get fragmented or dropped. Some networks block fragmentation outright, and the result is a transfer that starts well and then stalls, or consistently crawls at a fraction of capacity.
Indicators of an MTU problem include large downloads that stall at a consistent point, file transfers that succeed over one network and fail over another, and connections that are stable but bandwidth-poor everywhere. The fix is administrative: the tunnel's MTU must fit within the path's real capacity, and that is decided in the Firebox policy, not by a setting you can safely change on your own machine.
Consider the gateway and the office line
Every tunnelled session shares the Firebox, its inspection load, and the office internet connection. When twenty colleagues connect at nine in the morning, per-user throughput drops — not because anything is broken, but because the same pipe now serves twenty encrypted streams. Slowness that correlates with office hours and vanishes at night is a capacity question, and capacity questions are solved with licences, hardware, or bandwidth, not with client settings.
The nature of the traffic matters too. Transfers to a heavily used file server compete with everyone else's transfers to the same server, and an internal system that is slow for office staff is slow through the tunnel for the same reason. Test against two different internal resources before concluding that the tunnel itself is at fault.
Revisit routing and split tunneling
Where traffic travels is as important as how fast it travels. If the policy routes all traffic through the tunnel, your personal video call and your internal file transfer share one path, and each suffers for the other's presence. If the policy is split-tunnel, only office-bound traffic takes the tunnel, and general internet speed should be identical with and without a connection — if it is not, a routing rule is capturing more than it should.
A quick check: run a speed test against a public server while connected. If the result matches your raw line, routing is behaving as a split-tunnel design intends, and slowness to internal hosts alone points at the path to the office. If public speed collapses while connected, the policy is routing everything through the gateway — worth knowing before anyone blames the client. For a deeper walk through routing behaviour, see our guide on split tunneling, and for the product overview itself, start from the WatchGuard Mobile VPN with SSL description on our home page.
A short order of operations
Measure the raw line. Measure the tunnelled transfer in both directions. Compare against another internal resource. Check whether slowness correlates with office hours, with large transfers specifically, or with one location. Only then change anything — and only with your administrator's involvement for anything on the gateway side. Tuning in the wrong family of causes does not just fail; it usually makes the eventual diagnosis harder by adding changes that must be undone first.