{"id":533,"date":"2026-10-07T08:00:00","date_gmt":"2026-10-07T06:00:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/?page_id=533"},"modified":"2026-09-25T10:49:13","modified_gmt":"2026-09-25T08:49:13","slug":"raspberry-pi-as-a-hardened-wireguard-vpn-gateway-with-split-tunneling","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/raspberry-pi\/tutorials-en-raspberry-pi\/raspberry-pi-as-a-hardened-wireguard-vpn-gateway-with-split-tunneling\/","title":{"rendered":"Raspberry Pi as a Hardened WireGuard VPN Gateway with Split-Tunneling"},"content":{"rendered":"

Architectural Overview: WireGuard Kernel Routing and Split-Tunneling<\/h2>\n

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<\/strong>, 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.<\/p>\n

In a Split-Tunneling architecture<\/strong>, the Raspberry Pi functions as a hardened security gateway. Rather than routing all client internet traffic through the home network\u2014which bottlenecks mobile data speeds\u2014the tunnel selectively routes only specific destination subnets (e.g., local home lab resources under 192.168.10.0\/24<\/code>) 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.<\/p>\n

\n\"Split-tunnel
Split tunnelling in the routing table: only the two networks listed under AllowedIPs<\/code> travel through wg0<\/code>. The gateway forwards them at kernel level and masquerades them onto eth0<\/code>; all other traffic leaves the client directly.<\/figcaption><\/figure>\n

Step-by-Step Implementation Guide<\/h2>\n

Step 1: Enabling Linux Kernel IP Forwarding<\/h3>\n

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

# \/etc\/sysctl.d\/99-wireguard-forwarding.conf\nnet.ipv4.ip_forward = 1\nnet.ipv6.conf.all.forwarding = 1\nnet.ipv4.conf.all.rp_filter = 1\nnet.ipv4.conf.default.rp_filter = 1<\/code><\/pre>\n
Apply the modified kernel parameters immediately without restarting the host:<\/p>\n
sysctl --system<\/code><\/pre>\n
Step 2: Cryptographic Key Generation and Package Installation<\/h3>\n
Install the WireGuard kernel tools and generate public\/private key pairs with restricted filesystem permissions:<\/p>\n
apt update && apt install -y wireguard wireguard-tools nftables\nmkdir -p \/etc\/wireguard && cd \/etc\/wireguard\nchmod 700 \/etc\/wireguard\nwg genkey | tee server_private.key | wg pubkey > server_public.key\nchmod 600 server_private.key<\/code><\/pre>\n
Step 3: Configuring the Hardened Server Interface (wg0.conf)<\/h3>\n
The core configuration file defines the server listening port, subnet allocation, and integrated firewall routing rules. WireGuard\u2019s default UDP port (51820<\/code>) is configured alongside strict `nftables` masquerading rules:<\/p>\n
# \/etc\/wireguard\/wg0.conf\n[Interface]\nAddress = 10.100.0.1\/24\nListenPort = 51820\nPrivateKey = <SERVER_PRIVATE_KEY>\n\n# Automated firewall masquerading via nftables\nPostUp = 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\nPostDown = nft delete table ip wireguard\n\n# Example Split-Tunnel Client Peer Configuration\n[Peer]\nPublicKey = <CLIENT_PUBLIC_KEY>\nAllowedIPs = 10.100.0.2\/32<\/code><\/pre>\n
Step 4: Client Split-Tunnel Routing Configuration<\/h3>\n
On the remote client device, the AllowedIPs<\/code> 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<\/code> forces only home network packets through the encrypted tunnel, while public web browsing continues directly over the client’s local internet connection:<\/p>\n
# Client-Side Configuration (Split-Tunneling Mode)\n[Interface]\nPrivateKey = <CLIENT_PRIVATE_KEY>\nAddress = 10.100.0.2\/24\nDNS = 192.168.10.1\n\n[Peer]\nPublicKey = <SERVER_PUBLIC_KEY>\nEndpoint = vpn.lukaswojcik.com:51820\nAllowedIPs = 192.168.10.0\/24, 10.100.0.0\/24\nPersistentKeepalive = 25<\/code><\/pre>\n
Step 5: Quality Assurance and Throughput Validation<\/h3>\n
After starting the systemd service via systemctl enable --now wg-quick@wg0<\/code>, verification must be conducted across three diagnostic vectors:<\/p>\n
    \n
  1. Handshake and Key Exchange Audit:<\/strong> Execute wg show wg0<\/code> on the Raspberry Pi terminal to verify that active peers display recent cryptographic handshake timestamps and bidirectional transfer statistics.<\/li>\n
  2. Routing Table Verification:<\/strong> Inspect client routing tables (e.g., ip route show<\/code>) to confirm that the default gateway remains unchanged while static routes for 192.168.10.0\/24<\/code> point strictly to the wg0<\/code> interface.<\/li>\n
  3. Bandwidth and Latency Benchmark:<\/strong> Perform an internal iperf3<\/code> throughput test between the remote client and an internal home lab server to ensure transmission speeds achieve network saturation without packet fragmentation.<\/li>\n<\/ol>\n
    Summary and Measurable Added Value<\/h2>\n
    What is achieved:<\/strong> Implementation of a hardened, kernel-space WireGuard VPN gateway on Raspberry Pi hardware configured with selective split-tunneling and automated firewall masquerading.<\/p>\n
    Resulting added value:<\/strong><\/p>\n