Protocols

WireGuard, ChaCha20-Poly1305 and the kill switch: how PryVPN moves your traffic

What happens to a packet between your device and the exit node — and why a dropped tunnel means silence instead of leaks.

14 July 2026 · 6 min read · Updated 2 September 2026

The short version. PryVPN runs kernel WireGuard end to end. Every packet is sealed with ChaCha20-Poly1305 before it leaves your device, sized to a 1420-byte MTU so nothing fragments, and routed so that a dead tunnel has nowhere to send anything. Your provider sees one encrypted UDP flow to one address — never the sites, the searches or the DNS.

Why WireGuard, and why in the kernel

Older VPN protocols grew organically for decades: negotiation ciphersuites, fallback modes, compatibility shims. Every option is a corner where a bug or a downgrade attack can hide. WireGuard took the opposite route — one handshake, one cipher suite, a few thousand lines of code. Less code means less room for mistakes, and it shows: the Linux implementation lives in the kernel, so packets move between the network stack and the cipher without crossing into userspace and back.

That is the datapath PryVPN uses on every node: kernel WireGuard, no userspace relay in the middle, no protocol fallback. If a client cannot speak WireGuard, it does not connect at all. There is deliberately no “compatibility mode” to be downgraded into.

ChaCha20-Poly1305: one cipher, no negotiation

Because there is no cipher negotiation, there is nothing weak to negotiate down to. ChaCha20 encrypts the packet; Poly1305 authenticates it, so any bit flipped in transit fails closed instead of decrypting to garbage. The combination was designed to be fast even on CPUs without dedicated AES instructions — which is exactly the hardware in most phones and routers.

Keys never travel inside the tunnel setup you can inspect: each session gets a fresh keypair, the server keeps only the public half, and the private half is shown to you exactly once, inside the profile the console generates. Delete the session and that key is useless. There is no password to phish and no certificate to expire mid-trip.

MTU 1420: the number that avoids fragmentation

Encryption adds overhead to every packet — headers the outer network must carry. If the inner packet plus that overhead exceeds what the path accepts, something has to fragment it, and fragmentation costs CPU twice (split, then reassemble) while giving middleboxes two chances to mishandle it.

PryVPN sets the tunnel MTU to 1420 bytes: full-size traffic from your device is clamped before encryption so the encrypted packet still fits a standard 1500-byte path. The practical effect is fewer retransmits and steadier throughput on mediocre hotel and airport networks — the places a VPN matters most. If your connection ever feels “sticky” on public Wi-Fi with another provider, mismatched MTU is one of the first suspects; here the number is fixed and public.

The kill switch is routing, not a feature flag

Most “kill switches” are watchdogs: an app notices the tunnel died and hurries to block traffic. Between dying and noticing, packets can leave. PryVPN does it one layer lower. The tunnel profile claims the entire IPv4 space as two halves — 0.0.0.0/1 plus 128.0.0.0/1 — which outranks any leftover default route. While the tunnel is up, everything matches those routes and enters it. The moment the tunnel interface is gone, those routes are gone too, and there is simply no route left for the packets to take.

Nothing has to notice, react, or win a race. Silence is the default state, connectivity the exception — which is the correct polarity for a privacy tool.

What your provider actually sees

With the tunnel up, everyone between you and the exit node — the café Wi-Fi, the ISP, anyone with access to their records — sees exactly three facts:

UDP packets flowing to a single node address on one port,
how many bytes, and when,
that the payload is opaque.

The hostname, the DNS lookup, the page, the video, the timing inside the flow: all inside the encrypted payload. They can tell you used the internet. They cannot tell what for. And on our side the mirror rule holds — the never-logged list (browsing, DNS, destinations, SNI, payloads, your tunnel source address) is published on the privacy page and served by the API itself, so it is a checkable promise rather than a slogan.

No fallback protocol, on purpose

Every “if WireGuard fails, try something older” path is a downgrade attack waiting for an excuse — a hostile network just has to break the modern handshake and wait for the client to volunteer something weaker. So there is no such path. One protocol, one cipher, one MTU. The setups that cannot do that do not connect, loudly, instead of connecting weakly and quietly. When a privacy tool fails, the only acceptable failure is the obvious one.

Questions we hear

Is WireGuard faster than OpenVPN?

Usually, measurably so — mostly because it does far less per packet: no TLS handshake machinery, no userspace round-trips on Linux, one modern cipher instead of a negotiated menu. That said, the last mile (your Wi-Fi, the café uplink) decides most real-world speed tests. Our network page publishes live medians measured by real clients, which is the only speed number we will put our name on.

Does the kill switch slow down my connection?

No. Routes are looked up per packet either way; two extra route entries cost nothing measurable. A watchdog-style kill switch can add latency while it reacts, but a routing-based one like ours adds zero — it only ever takes traffic away, never forwards it.

Why 1420 bytes and not 1500?

Because the encryption envelope needs room. A 1500-byte inner packet plus WireGuard overhead would exceed the standard 1500-byte path and fragment. 1420 leaves headroom so the sealed packet still fits, which means fewer retransmits, especially on constrained networks.

Can my ISP tell I am using a VPN?

They can tell you are sending encrypted UDP to one address — the shape is recognizable. What they cannot see is anything inside: no hostnames, no DNS, no pages, no timing of individual requests. Hiding the fact of VPN use entirely (obfuscation) is a different, much costlier problem that we do not claim to solve.

Mara VidalNetwork Engineer

Mara runs the PryVPN exit network: WireGuard datapaths, node capacity, and the beacons that feed the live status page.

Reviewed by Jonas Keller · Updated 2 September 2026