Raspberry Pi as a Hardened WireGuard VPN Gateway with Split-Tunneling

Architectural Overview: WireGuard Kernel Routing and Split-Tunneling

Traditional VPN protocols such as OpenVPN or IPsec rely on userspace context switching and complex cryptographic handshakes, which introduce substantial CPU overhead and latency on single-board ARM computers like the Raspberry Pi. WireGuard, by contrast, operates directly inside the Linux kernel space using state-of-the-art cryptography (ChaCha20, Poly1305, Curve25519), enabling throughput exceeding 800 Mbps on Gigabit Ethernet interfaces with minimal CPU load.

In a Split-Tunneling architecture, the Raspberry Pi functions as a hardened security gateway. Rather than routing all client internet traffic through the home network—which bottlenecks mobile data speeds—the tunnel selectively routes only specific destination subnets (e.g., local home lab resources under 192.168.10.0/24) through the encrypted WireGuard interface. Conversely, the gateway can also be configured to encrypt specific local LAN devices through an external privacy VPN provider while leaving general LAN traffic unaffected.

Step-by-Step Implementation Guide

Step 1: Enabling Linux Kernel IP Forwarding

To permit packet forwarding between the physical network interface (eth0) and the virtual WireGuard interface (wg0), IPv4 and IPv6 packet forwarding must be enabled permanently in the Linux kernel hierarchy:

# /etc/sysctl.d/99-wireguard-forwarding.conf
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

Apply the modified kernel parameters immediately without restarting the host:

sysctl --system

Step 2: Cryptographic Key Generation and Package Installation

Install the WireGuard kernel tools and generate public/private key pairs with restricted filesystem permissions:

apt update && apt install -y wireguard wireguard-tools nftables
mkdir -p /etc/wireguard && cd /etc/wireguard
chmod 700 /etc/wireguard
wg genkey | tee server_private.key | wg pubkey > server_public.key
chmod 600 server_private.key

Step 3: Configuring the Hardened Server Interface (wg0.conf)

The core configuration file defines the server listening port, subnet allocation, and integrated firewall routing rules. WireGuard’s default UDP port (51820) is configured alongside strict `nftables` masquerading rules:

# /etc/wireguard/wg0.conf
[Interface]
Address = 10.100.0.1/24
ListenPort = 51820
PrivateKey = <SERVER_PRIVATE_KEY>

# Automated firewall masquerading via nftables
PostUp = nft add table ip wireguard; nft add chain ip wireguard nat { type nat hook postrouting priority 100\; policy accept\; }; nft add rule ip wireguard nat oifname "eth0" masquerade
PostDown = nft delete table ip wireguard

# Example Split-Tunnel Client Peer Configuration
[Peer]
PublicKey = <CLIENT_PUBLIC_KEY>
AllowedIPs = 10.100.0.2/32

Step 4: Client Split-Tunnel Routing Configuration

On the remote client device, the AllowedIPs directive controls whether the connection functions as a full tunnel or a split tunnel. Setting AllowedIPs = 192.168.10.0/24, 10.100.0.0/24 forces only home network packets through the encrypted tunnel, while public web browsing continues directly over the client’s local internet connection:

# Client-Side Configuration (Split-Tunneling Mode)
[Interface]
PrivateKey = <CLIENT_PRIVATE_KEY>
Address = 10.100.0.2/24
DNS = 192.168.10.1

[Peer]
PublicKey = <SERVER_PUBLIC_KEY>
Endpoint = vpn.lukaswojcik.com:51820
AllowedIPs = 192.168.10.0/24, 10.100.0.0/24
PersistentKeepalive = 25

Step 5: Quality Assurance and Throughput Validation

After starting the systemd service via systemctl enable --now wg-quick@wg0, verification must be conducted across three diagnostic vectors:

1. Handshake and Key Exchange Audit: Execute wg show wg0 on the Raspberry Pi terminal to verify that active peers display recent cryptographic handshake timestamps and bidirectional transfer statistics.
2. Routing Table Verification: Inspect client routing tables (e.g., ip route show) to confirm that the default gateway remains unchanged while static routes for 192.168.10.0/24 point strictly to the wg0 interface.
3. Bandwidth and Latency Benchmark: Perform an internal iperf3 throughput test between the remote client and an internal home lab server to ensure transmission speeds achieve network saturation without packet fragmentation.

Summary and Measurable Added Value

What is achieved: Implementation of a hardened, kernel-space WireGuard VPN gateway on Raspberry Pi hardware configured with selective split-tunneling and automated firewall masquerading.

Resulting added value:

• Zero-Latency Remote Access: Internal home laboratory services, dashboards, and storage nodes become securely accessible from external networks without exposing internal ports to the public internet.
• Optimized Bandwidth Consumption: Split-tunneling prevents unnecessary routing of external streaming or web traffic through home upload connections, maintaining maximum client download speeds.
• Minimal Hardware Footprint: Kernel-level execution requires markedly less CPU time per transferred gigabyte than userspace protocols such as OpenVPN, leaving noticeably more system resources available for containerized services.