RTFM · Networking
Remote-access and management VPNs
Give a laptop access to the networks it needs without publishing management services to the whole Internet.

Road-warrior design
A laptop is a roaming peer. Give it a VPN address, a peer key, routes for the management and service prefixes, and DNS that can resolve internal names. Use split tunnel when only company networks should traverse the VPN; use full tunnel when policy requires Internet traffic to leave through the Saphira edge.
Laptop 10.99.0.10
│ encrypted VPN
▼
Saphira VPN 10.99.0.1
├── management 192.168.30.0/24
├── MailDragon 192.168.20.25
└── webDragon 192.168.20.30Install WireGuard and make keys safely
Saphira packages wireguard-tools, which supplies wg and wg-quick. The kernel supplies the WireGuard interface support. Generate private keys on the machine that owns them, protect the directory, and exchange only public keys. A private key in a ticket, shell history, public repository, or chat is a compromised key.
apk update
apk add wireguard-tools nftables
command -v wg wg-quick nft
install -d -m 700 /etc/wireguard
umask 077
wg genkey | tee /etc/wireguard/server.key | wg pubkey > /etc/wireguard/server.pub
wg genkey | tee /etc/wireguard/laptop.key | wg pubkey > /etc/wireguard/laptop.pub
chmod 600 /etc/wireguard/*.key
cat /etc/wireguard/server.pub
cat /etc/wireguard/laptop.pubThe public keys may be copied into peer configurations. The .key files must not. The example tunnel addresses and endpoint below are documentation values; choose non-overlapping values from your own address plan.
A complete split-tunnel remote-access configuration
This design gives the laptop a tunnel address and routes only management and server networks through Saphira. Internet browsing remains local to the laptop: that is split tunnelling. It is the clearest first deployment because a bad VPN route cannot accidentally send all client Internet traffic through an unfinished gateway.
# /etc/wireguard/wg0.conf on the Saphira VPN edge
[Interface]
Address = 10.66.0.1/24, fd42:66::1/64
ListenPort = 51820
PrivateKey = <contents of /etc/wireguard/server.key>
[Peer]
# Laptop: one tunnel IPv4 and IPv6 address only.
PublicKey = <contents of /etc/wireguard/laptop.pub>
AllowedIPs = 10.66.0.2/32, fd42:66::2/128
# Laptop configuration
[Interface]
Address = 10.66.0.2/24, fd42:66::2/64
PrivateKey = <contents of /etc/wireguard/laptop.key>
DNS = 192.168.30.53
[Peer]
PublicKey = <contents of /etc/wireguard/server.pub>
Endpoint = vpn.example.test:51820
AllowedIPs = 10.66.0.0/24, 192.168.20.0/24, 192.168.30.0/24, 2a02:8012:bc57:20::/64, 2a02:8012:bc57:30::/64
PersistentKeepalive = 25AllowedIPs has two important meanings. On the server it tells WireGuard which tunnel addresses belong to this peer; keep them exact so one peer cannot claim another peer's route. On a wg-quick client it also selects routes that should enter the tunnel. 0.0.0.0/0 and ::/0 deliberately make a full tunnel; do not add them until the gateway, DNS, NAT or routed return path, and firewall policy are designed.
Bring up the tunnel under your chosen service manager
wg-quick up wg0 and wg-quick down wg0 are the portable first controls and are the right way to prove a new configuration. The current Saphira wireguard-tools package does not install systemd units for you, so do not assume wg-quick@.service exists. If you want boot-time ownership, create and review one explicit service definition for the init system you selected.
# First proof, from a console or separate management path.
wg-quick up wg0
wg show wg0
ip addr show dev wg0
ip route
ip -6 route
# /etc/init.d/wg0 for OpenRC
#!/sbin/openrc-run
name="WireGuard wg0"
depend() { need net; }
start() { ebegin "Starting ${name}"; wg-quick up wg0; eend $?; }
stop() { ebegin "Stopping ${name}"; wg-quick down wg0; eend $?; }
chmod 755 /etc/init.d/wg0
rc-service wg0 start
rc-update add wg0 default# /etc/systemd/system/wg0.service on a Saphira systemd installation
[Unit]
Description=WireGuard wg0
After=network-online.target
Wants=network-online.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/wg-quick up wg0
ExecStop=/usr/bin/wg-quick down wg0
[Install]
WantedBy=multi-user.target
systemctl daemon-reload
systemctl enable --now wg0.service
systemctl status wg0.serviceForwarding and firewall
The VPN endpoint must listen on its chosen UDP port. The router or provider firewall must allow that port. Saphira must permit the VPN interface to reach only the intended LAN/VLAN destinations, and the LAN must have a return route to the VPN address pool. NAT may hide the pool, but routed VPNs are easier to reason about when every side has an explicit route.
ip route
ip -6 route
ss -lunp
sudo tcpdump -ni wg0
sudo tcpdump -ni eth0 host 10.99.0.10Avoid accidental exposure
Do not bind SSH, databases, or admin dashboards to the public interface merely because the VPN is not working yet. Fix the VPN route and firewall, or use a controlled recovery path. Do not use 0.0.0.0/0 in a peer's AllowedIPs without understanding whether it creates a full tunnel and where DNS will go.
MTU and address planning
A VPN adds headers. If packets become too large, web pages may partially load, SSH may connect but hang during output, or large pings and file transfers may fail. Use tracepath, inspect interface MTU, and adjust MTU or TCP MSS deliberately. Never overlap the VPN pool with a home Wi-Fi or office subnet.
ip link show wg0
tracepath 192.168.20.25
tracepath6 2001:db8:20::25
ping -M do -s 1300 192.168.20.25