VPNSmith
self-host-vpnINFO

WireGuard and IPv6: what /64 versus /128 actually changes on your VPS (2026)

Host comparisons list '/64 IPv6' or 'single /128' as if it were a detail. For a self-hosted WireGuard server it decides whether your peers can have IPv6 at all. What the prefix means, and how AllowedIPs handles both stacks.

By Eric Gerard · Founder · VPNSmith - Self-host VPN & GDPR VPS specialist3 min readPhoto via Pexels

Every VPS comparison on this site lists it: "single /128 IPv6 by default", "/64 IPv6", "no IPv6 on the base plan". It reads like a spec-sheet detail. For a self-hosted WireGuard server it is not - it decides whether your peers can have IPv6 at all.

WireGuard does not care which stack you use

Start with the easy part. The WireGuard documentation is explicit: "Any combination of IPv4 and IPv6 can be used, for any of the fields."

The endpoint can be IPv4 while the tunnel carries IPv6, or the reverse. There is no separate IPv6 mode to enable and no second daemon to run. A dual-stack tunnel is just two addresses on the same interface.

What /64 and /128 actually mean for you

This is where the host's spec sheet starts to matter.

A /128 is one single address. It is your server's own IPv6 and nothing more. You can give the server IPv6 connectivity, but you have no addresses left to hand out - your peers cannot each have one.

A /64 is a block. It is the standard allocation size for a single network segment, and it leaves you free to assign an address to every peer from inside it.

So a host advertising "IPv6 included" with a single /128 is telling the truth and still not giving you what a VPN server needs. That is the line worth reading twice in a comparison table, ours included.

AllowedIPs does two different jobs

This is the part people get wrong, and it is documented plainly. The same field behaves differently depending on direction:

"when sending packets, the list of allowed IPs behaves as a sort of routing table"

"when receiving packets, the list of allowed IPs behaves as a sort of access control list"

WireGuard calls the whole arrangement a Cryptokey Routing Table - "the simple association of public keys and allowed IPs".

The consequence for IPv6 is direct: if you want a peer's IPv6 traffic to go through the tunnel, ::/0 has to be in its AllowedIPs. Setting 0.0.0.0/0 alone routes IPv4 only, and the peer's IPv6 traffic leaves through its normal connection - outside the tunnel, with its real address.

That is a leak, and it is not a WireGuard bug. It is the access control list doing exactly what it was told.

The configuration in practice

On the server, give the interface both an IPv4 and an IPv6 address from your allocation. On each peer, list both stacks in AllowedIPs. If you want everything tunnelled, that is 0.0.0.0/0, ::/0; if you want a split, list the specific prefixes for each stack.

Two things to keep in mind. Forwarding has to be enabled for both families, not just IPv4 - they are separate sysctl settings, and enabling one does nothing for the other. And your firewall rules exist twice as well: iptables and ip6tables are different tables, so a masquerade or a kill switch written only for IPv4 leaves IPv6 unprotected.

Verify rather than assume

After setting it up, check from the client that your public IPv6 is the server's and not your own. A tunnel that carries IPv4 correctly while leaking IPv6 looks perfectly healthy from the inside - the handshake succeeds, traffic flows, and nothing in the logs complains.

If your host only gives you a /128, the honest options are to run IPv4-only in the tunnel and block IPv6 on the peers so it cannot leak, or to change host. Half-configured dual stack is worse than no IPv6 at all.

A person in a high-visibility vest holding a clipboard with a printed inspection checklist and a pen
A person in a high-visibility vest holding a clipboard with a printed inspection checklist and a pen
An inspector holding a printed checklist. This is the second, less obvious role of AllowedIPs: on incoming packets it is not a route at all, it is the list that decides what is allowed through.

★ Nuremberg GDPR datacenter · ✓ Dedicated IPv4 included · 200+ Mbps guaranteed

Self-host your VPN on your own VPS → ContaboFull root access · public IPv4 · pick your region→

Frequently asked questions

Does WireGuard support IPv6?
Yes, natively and without a separate mode. The documentation states that any combination of IPv4 and IPv6 can be used for any of the fields, so the endpoint can be IPv4 while the tunnel carries IPv6 or the reverse. A dual-stack tunnel is simply two addresses on the same interface.
What is the difference between a /64 and a /128 IPv6 on a VPS?
A /128 is one single address - your server's own, with nothing left to hand out, so peers cannot each have an IPv6. A /64 is a block, the standard allocation for a network segment, from which you can assign an address to every peer. A host advertising 'IPv6 included' with a single /128 is being truthful while still not providing what a VPN server needs.
Why does my IPv6 leak even though the WireGuard tunnel works?
Almost always because AllowedIPs lists 0.0.0.0/0 but not ::/0. AllowedIPs acts as a routing table on outgoing packets, so IPv4 goes through the tunnel while IPv6 traffic leaves via the normal connection with your real address. It is not a bug; it is the configuration doing what it was told.
What does AllowedIPs actually do?
Two different jobs depending on direction. On sending, it behaves as a sort of routing table, deciding which peer a packet goes to. On receiving, it behaves as a sort of access control list, deciding what is accepted from that peer. WireGuard calls the whole arrangement a Cryptokey Routing Table: the association of public keys and allowed IPs.
Do I need separate firewall rules for IPv6?
Yes. iptables and ip6tables are different tables, and IP forwarding is enabled per family through separate settings. A masquerade rule or a kill switch written only for IPv4 leaves IPv6 entirely unprotected, which is how a tunnel that looks healthy ends up leaking.
Related articles

Read next