Ok, but, in this case its encrypted at the computer, not the router and what I experienced was a huge increase in bloat on the upload side vs no vpn...
Not questioning you .. just trying to understand. Yes I do know VPNs add and slow things down but in this case its not the router is what I am saying, its either the servers or the computer.
How to explain this without writing a novel....
OK, so, you remember how I first explained it to you, that the device doing NAT/PAT is typically, under high utilization, the limit in the rate at which packets are parsed and its handling of those packets is what imposes delay on the process (it's buffering) which is what this test measures?
OK, so with that in mind, that measure is based on the following sequence:
Browser -> TCP/IP Stack (and anything that plays in here like a SW firewall) -> Access Point (if Wireless) -> Switch -> GW/Router/Firewall -> Internet (routed) -> Test Server
You can reverse that sequence for download.
Now, with a VPN in play, that sequence looks like:
Browser -> TCP/IP Stack (and SW firewall if applicable) + VPN Client, encrypting traffic -> AP (if WiFi) -> Switch ->GW/Router/FW -> Internet (routed) -> VPN Host, decrypting traffic -> Internet (routed) -> Test Server
So, you've added significantly more hops and also the software-imposed delay at both the near and far ends in encrypting/decrypting all the traffic used for the test. This adds latency to the entire test, which then becomes the predominant factor which is why your upstream crapped the bed. It's one thing encrypting/decrypting a few ICMP packets to determine empty pipe latency and jitter. It's quite another to do that at a reasonable rate when the pipe is being highly utilized. The overhead of the VPN process becomes a significant player at that point and the overall driver of latency.
