Skip to content
Saphira Linux

VPN

Saphira Linux vpnDragon

Run WireGuard on infrastructure you control, connect your devices to it, and remove the unnecessary mystery from secure remote connectivity.

In testing, functionality present — helpers missing
Saphira Linux vpnDragon, the WireGuard VPN mascot

IPv6 without pretending NAT is security

Where you have a routed IPv6 prefix, a WireGuard client can receive globally routable IPv6 connectivity from address space you control. A phone away from home can then use an IPv6 address from your own routed prefix through the tunnel, where your addressing and routing design permits it. That is often cleaner and more capable than translating every client behind NAT.

GoodIPv6 removes the need for NAT. It does not remove the need for a firewall. A globally routable address still needs an explicit inbound and forwarding policy in nftables.

A tunnel prefix, then routed space

A simple dual-stack tunnel can use a dedicated /64, for example 2001:db8:1234:100::/64 in documentation. Give the server one address and each peer one address. The server's peer entry lists the client's /128 in AllowedIPs; the client lists the server and any networks it should reach. Route the tunnel /64 to the WireGuard server from your own network design.

[Interface]
# Server addition, using documentation addresses only
Address = 2001:db8:1234:100::1/64

[Peer]
# First client's public key
PublicKey = <client public key>
AllowedIPs = 10.66.0.2/32, 2001:db8:1234:100::2/128

With enough routed IPv6 space, a peer can receive more than one tunnel address: route a separate /64 behind a client, remote home or office. Add that routed /64 to the peer's AllowedIPs on the server, route it through the tunnel, and write nftables rules for exactly the traffic you want to allow. This is useful for a remote network that should use your own address space without hiding it behind NAT.

Go further carefully

AKADATA's existing WireGuard work demonstrates tunnel /64s, individual client addresses, dual-stack peer management, optional routed /64s, QR configuration and peer revocation. vpnDragon uses that work as background for the networking model, but does not claim the unpublished management tools as a current Saphira feature. Build and verify the first client first; introduce routed prefixes only once you understand the paths and firewall policy.