How Nullwire actually works
Most VPN providers say "no logs" and leave it at that. Here's the actual architecture underneath that claim — specific enough that you can judge for yourself whether it holds up.
Addressing: private ranges, leased not fixed
Every device that connects gets an internal tunnel address from a private range — never a real, publicly-routable address handed directly to your device. That address is also leased dynamically, not permanently tied to your device: it's assigned when you connect and released back to the pool when you disconnect, the same way a home router hands out addresses over DHCP rather than nailing one to a device forever. This matters for how the system is built, not just as a technical detail:
IPv4 — RFC 1918
Each node hands out addresses from its own private
10.x.0.0/16 range — the same private space used
inside any home or office network. These addresses are never
routable on the public internet. When your traffic needs to
actually reach a website, the node rewrites it to come from
the node's own public IP before it leaves — the same
NAT approach used in virtually every home router.
IPv6 — RFC 4193 (ULA)
On nodes that support IPv6, devices get an address from a Unique Local Address range — IPv6's equivalent of private IPv4 space. Cloud providers typically hand out only a handful of real public IPv6 addresses per server, nowhere near enough to give one to every connected device directly. Each node's ULA prefix is generated independently using a cryptographically random 40-bit identifier, per RFC 4193 — not a shared or guessable value.
DNS: we run our own resolver
Most VPN providers — even ones with a genuinely no-logs tunnel — quietly forward your DNS queries to a third party like Cloudflare or Google. That third party can technically see which domains you're resolving, even if your VPN provider itself keeps no logs at all.
We don't do that. Each Nullwire node runs its own recursive DNS resolver, reachable only through the VPN tunnel itself — not exposed to the public internet. It queries the internet's root and authoritative name servers directly, the same way any DNS resolver ultimately has to — but without ever handing your queries to a third-party resolver in the middle. No one outside our own infrastructure ever sees what you're looking up. And consistent with the rest of this system, the resolver itself keeps no query logs.
WireGuard: no persistent connection state
The tunnel itself runs on WireGuard, which by design keeps only live, in-memory state about currently active connections — nothing about a connection is ever written to disk. When a device disconnects (or simply goes quiet — we automatically clear out connections that stop responding, so nothing lingers indefinitely), its leased address is released back into the pool along with everything else, so there's nothing left behind to look up later.
Split tunneling: choosing what skips the tunnel
By default, every byte your device sends goes through the tunnel — full-tunnel, no exceptions. If you'd rather keep some traffic on your normal connection instead (a home printer, a local NAS, anything on your own network you still need to reach directly without it going through the VPN), you can create a tunnel profile in the desktop app and list the IP ranges to exclude.
Your WireGuard config's AllowedIPs field is where
this actually gets expressed, and it's worth understanding what it
means — the name is easy to misread. AllowedIPs isn't a
list of destinations you're "allowed" to reach; it's the list of
destinations WireGuard will actually route through the tunnel.
Anything NOT in that list is exempt from the tunnel entirely and
travels over your normal network connection instead. WireGuard has
no native "route everything except X" syntax, only a list of ranges
to explicitly include — so excluding a range means computing
everything else around it, which is why a profile with even one
exclusion produces a long, fragmented AllowedIPs list
instead of one tidy entry. It's still mathematically "route
everything except your exclusions" — WireGuard just has no shorthand
for that, so it has to be spelled out as dozens of smaller blocks.
One more detail worth knowing if you ever inspect your own config: whenever any exclusion is in play, we also always exclude the VPN node's own address, even if you didn't ask us to. Without that, the tunnel's own traffic to its own server can end up captured by its own exclusion-shaped route and never actually leave your device — WireGuard has a built-in safeguard against exactly this, but it only recognizes the literal, single-entry form of "route everything," not the fragmented version, so we handle that case explicitly ourselves rather than relying on it.
Kill switch: no quiet fallback to your normal connection
If the tunnel ever drops unexpectedly — a brief network hiccup, your laptop waking from sleep, a server-side restart — the obvious failure mode for a VPN is the quiet one: your device just falls back to your normal internet connection and keeps going, with nothing telling you that you're no longer protected. Nullwire doesn't do that. The moment a connection is established, the background helper puts a rule in place that blocks everything except the tunnel itself, your chosen split-tunnel exclusions, and the minimum needed to reconnect. If the tunnel then drops on its own, that block stays in effect — your other traffic is stopped rather than silently sent unprotected — until you reconnect.
Two things worth knowing about how it behaves: it's on automatically for every connection, nothing to turn on yourself, and it resets to normal internet access on a full restart of your computer rather than staying blocked indefinitely — we'd rather a forgotten VPN session never leave you stranded with no internet and no obvious cause than hold out for a theoretical edge case a restart already resolves on its own (reopening Nullwire and reconnecting).
Put together
Private internal addressing, NAT at the edge, our own DNS resolver, and a tunnel protocol with no persistent state — every layer of this system is built so there's genuinely nothing to log, not just a policy promising we won't. You can read more about what we do and don't collect in our Privacy Policy.