Learn PPTP - Performance & Benchmarking

#Introduction

When people ask why PPTP feels faster, the answer is often misunderstood. Episode 17 discusses PPTP performance technically: what makes it fast, what it actually sacrifices, and how to measure it correctly.

A benchmark is not just numbers — it is the basis for decisions. Understanding throughput, latency, and packet loss measurements lets you judge whether PPTP is worth keeping for a particular workload, or whether it is just one more reason to migrate.

#PPTP Performance Characteristics

#Relatively Small Overhead

On the encapsulation side, PPTP is quite lean. PPP, GRE, and IP header overhead ranges from 50-80 bytes — smaller than L2TP/IPsec, which wraps two layers of encapsulation. This is one reason PPTP feels responsive.

RC4-based MPPE encryption is also computationally light compared to modern ciphers. On small CPUs, RC4 is faster than AES without available hardware acceleration. But this speed buys security that is far below standard.

#The Hidden Costs

There are costs not directly visible in speed numbers. The absence of an integrity check makes MPPE light, but it also removes integrity verification. Stateless GRE means no congestion detection — all responsibility rests on TCP.

#When Performance Degrades

PPTP performance drops drastically under certain conditions: networks with high packet loss (because stateless GRE does not recover packets), paths with small un-clamped MTUs, and many simultaneous sessions on a single-CPU server. In these cases, PPTP no longer feels fast.

It is also important to factor in CPU: RC4 uses few cycles, but encryption still runs in pppd's userspace. On a server running many other services, the bottleneck often appears on the encryption side, not the network.

#Benchmarking with iperf3

#Measuring Throughput Through the Tunnel

The standard tool for measuring throughput is iperf3. Run the server on the PPTP server side, then the client on the tunnel side:

iperf3 -s

iperf3 -c 192.168.1.10

iperf3 -c 192.168.1.10 sends traffic through the ppp0 interface and reports throughput. Compare the result with a direct measurement without the tunnel to learn how much overhead is lost.

#Determining Traffic Direction

Note that iperf3 results differ depending on direction. For a complete picture, measure both: upload and download. You can also use the -R mode on the client to reverse the direction automatically.

iperf3 -c 192.168.1.10 -R

iperf3 -c 192.168.1.10 -R runs the test in reverse so download results are also measured. Record both numbers to understand network asymmetry.

#Reading iperf3 Output

The iperf3 output shows throughput per interval and the overall average. Note the SUM line in the interval reports to see the combined transfer. Compare three numbers: without a tunnel, through the tunnel without MPPE, and through the tunnel with MPPE.

The difference between the first and last numbers is the real cost PPTP must account for. If the difference is small, encryption overhead is not a big problem; if it is large, consider whether the server hardware is still adequate for the workload.

#Latency and Packet Loss

#Measuring Latency

Latency is measured with a ping through the tunnel interface:

ping -c 20 -i 0.2 192.168.1.10

ping -c 20 -i 0.2 192.168.1.10 sends 20 packets every 200 milliseconds. Note the average and jitter. The PPTP tunnel adds latency because of the encapsulation layer, but usually within the millisecond range on a healthy network.

#Measuring Packet Loss

Watch the packet loss line in the ping output. Stateless GRE means packets lost in the tunnel are not recovered at this layer — TCP will handle it via retransmission, but real-time UDP will feel the impact.

#Interpreting Jitter

Besides average latency, watch jitter — the variation between measurements. High jitter indicates queuing or buffering on the path, and strongly affects real-time applications such as VoIP and video conferencing.

A PPTP tunnel over an already jittery connection makes things worse because each packet adds encapsulation overhead. For real-time workloads, VPNs with modern control and hardware offload support usually show more stable numbers.

#Comparison with Modern VPNs

#Reading the Numbers Critically

When comparing PPTP with OpenVPN or WireGuard, remember two things. First, PPTP can be faster in raw throughput on old hardware, but that is because its security is far weaker. Second, WireGuard and OpenVPN with AES-NI on modern hardware can match or even exceed PPTP while staying secure.

A healthy benchmark measures more than just throughput: it measures security per byte transferred. On that metric, PPTP loses decisively.

Also measure consistency: run the benchmark several times and note the variation between runs. Wildly swinging numbers indicate an unstable network, making a single number untrustworthy as a basis for decisions.

Record the environment conditions during the benchmark — time, server load, and firmware version — so the results can be reproduced. A benchmark that cannot be reproduced is worth almost as little as a guess.

#Closing

Episode 17 separated myth from fact about PPTP performance: small overhead, lightweight but fragile encryption, and how to measure throughput, latency, and packet loss with iperf3 and ping.

Key takeaways:

• PPTP encapsulation overhead is about 50-80 bytes, smaller than L2TP/IPsec.
• RC4-based MPPE is computationally light but cryptographically weak.
• iperf3 -c measures throughput; use -R for the reverse direction.
• Latency and packet loss are measured with ping through the tunnel interface.
• Stateless GRE leaves packet loss detection entirely to TCP.
• A fair comparison with modern VPNs must consider security per byte.

In the next episode, episode 18, we will discuss legacy system integration — PPTP configuration on Windows Server through RRAS, the role of NPS for authentication, PPTP support on Cisco and Juniper devices, and cross-vendor interoperability issues.