Does a VPN decrease internet speed, and why?

Usually yes, a little. A VPN adds a detour to the VPN server, encryption work on both ends and extra bytes on every packet. Often the loss is small. It becomes noticeable when the server is far away, overloaded, or the tunnel is misconfigured for packet size.

What causes the slowdown?

Distance. Your traffic goes to the VPN server first, then on to the destination. If the server is on another continent, round trip time grows by the extra distance. Latency matters for video calls and interactive work more than for downloads.

Encryption cost. Every packet is encrypted and decrypted. On modern devices with hardware support, this is cheap. On old routers or small embedded devices, the processor can become the limit.

Protocol overhead. The tunnel wraps each packet in extra headers. That leaves less room for data in each packet and costs a few percent of bandwidth.

Server load. A busy gateway shared by many users gives each less capacity.

Packet size problems. This is the one people miss. RFC 4459, which discusses MTU and fragmentation issues with in tunnel networks, explains that tunnels in the middle of a network raise questions about how large packets are handled: whether they are fragmented and reassembled, whether Path MTU Discovery is used, and how the scenario can be avoided. If the tunnel's maximum packet size is set wrongly, large packets get fragmented or dropped, and some sites load slowly or hang while small ones work.

Routing. Sometimes a VPN makes things faster, because the provider's path to a destination is better than your internet provider's route. It is not common, but it happens.

Does the protocol matter?

It can. The WireGuard project publishes performance notes. Its own page says its benchmarks are old and not super well conducted, and that WireGuard and IPsec have both gotten faster since, with WireGuard sometimes edging out IPsec thanks to multi threading, while the page describes OpenVPN as remaining much slower in those tests. Treat that as one project's view, run on specific older hardware. Your results depend on the devices, the settings and the network.

Constructed example: the slow file share

An employee on a home connection reports that opening large spreadsheets from a company file share is slow over the VPN, while email is fine. A speed test shows the connection is fine. The VPN gateway is in a distant region, and the file share protocol is chatty, with many back and forth requests. Each extra 80 milliseconds of delay is multiplied by hundreds of exchanges. Moving the employee to a nearer gateway cuts the load time by more than half. The fix was about distance and protocol behavior, not bandwidth.

How do you measure it?

Test with and without the VPN, at the same time of day, using the same server and test method. Record latency, download and upload speed, and test a few real tasks such as opening a file or joining a call. Repeat three or four times, since single tests vary. Then change one thing at a time: server location, protocol, packet size setting.

How to check or apply this

1. Run baseline speed and latency tests without the VPN, then with it, and compare.
2. Pick the nearest gateway region and retest.
3. If large transfers stall while small ones work, check MTU settings on the tunnel.
4. Try a different protocol or cipher setting if your gateway offers one, and measure again.
5. Check gateway CPU and session counts during busy hours.
6. Consider split tunneling for traffic that does not need to cross the company network, after weighing the security trade offs with your security team.

Quick check

Sources

• RFC 4459, MTU and Fragmentation Issues with In-the-Network Tunneling
• WireGuard performance notes
• NIST SP 800-77 Rev. 1, Guide to IPsec VPNs

Last reviewed: 18 October 2026.