WraithGate

WraithGate is the fleet of VPN servers that terminate WireGuard tunnels from the WraithVPN app and the Enclave tier. Each node does three jobs: it accepts customer WireGuard peers, it egresses their traffic to the internet, and it runs Haven DNS on the wire-level interface so DNS queries made through the tunnel stay inside the tunnel.

Regions

WraithGate operates a global exit-node network with presence across Europe, the Americas, and Asia-Pacific. Capacity in each region is sized to demand and expands as demand grows; the app selects a region on your behalf or lets you pick one. We use multiple underlying providers within each region for resilience.

Each node has a public address assigned by its underlying provider and a private address on our mesh. Customer WireGuard traffic hits the public address; the mesh address is not reachable from your client.

Protocol

WireGuard, standard upstream kernel module where available, AmneziaWG (a WireGuard fork with obfuscated handshakes) on nodes in regions where traffic shaping against WireGuard has been observed. Same cryptographic primitives either way: Curve25519 key exchange, ChaCha20-Poly1305 payload cipher, BLAKE2s hashing. No TLS layer, no fallback ciphers.

Each node assigns your device a stable internal address from a per-node client subnet (IPv4 with matching IPv6 ULA). The assignment is stable for the lifetime of the peer record; rotating servers rotates the address.

What happens on the node

Inbound: your device sends a WireGuard packet to the node's public address. The kernel decrypts it using the static public key you registered at provision time. The plaintext IP packet is handed to the kernel's routing table, which NATs it to the node's public address and forwards it to the internet.

Outbound: return traffic hits the public address, gets NATted back to your WireGuard subnet address, encrypted with your session key, and sent back to your device.

DNS queries inside the tunnel go to the node's internal Haven resolver on UDP 53. They do not leave the node in cleartext; they are forwarded upstream via DNS-over-HTTPS to Quad9 and Cloudflare. See the Haven page for details.

What Katafract can see

• Your connection's existence — the node sees a WireGuard handshake from your current IP address when you connect. This is true of every VPN ever built.
• Aggregate bandwidth per peer — WireGuard exposes transfer counters. We use these for fleet capacity planning. They are not tied to destinations.
• Peer provisioning metadata — which node you were assigned to, the WireGuard public key, the allocated internal address, when the peer was created and last rotated. This lives in our control-plane database.

What Katafract cannot see

• Packet contents beyond what NAT requires — we do not run deep packet inspection, flow collectors, or traffic capture on WraithGate nodes.
• Which sites you visited — we do not log destination IPs, DNS queries, SNI, or HTTP Host headers. The NAT connection-tracking table is ephemeral and not written to disk.
• Peer-to-peer visibility between customers — iptables drops traffic from one customer subnet to another on the same node.

Rotations and failure

Nodes are rebuilt from bootstrap scripts on a staggered schedule for security updates. Peer records are preserved across reboots. If a node becomes unreachable for more than a few minutes, the app is expected to switch to another node in the same region — the client holds the credentials, we re-provision on request.

What this means for you

The node sees your current IP when you connect, because it has to. It does not see where your traffic goes after it leaves. That is the honest floor of what any VPN can offer. The rest — the nodes logging as little as possible, the tunnels being cryptographically isolated from our internal systems, the DNS staying inside the tunnel — is architecture meant to keep that floor intact under pressure.

Back to all modules.