How to Set Up a Tunneled Wi-Fi Hotspot on Raspberry Pi OS Bookworm with WireGuard and NetworkManager

This guide updates our earlier tutorial for Debian 12 Bookworm on Raspberry Pi. In this architecture, the Raspberry Pi connects to upstream internet via Ethernet (eth0), establishes an encrypted WireGuard VPN tunnel (wg0), and broadcasts a secure Wi-Fi access point on wlan0. All client traffic connected to the hotspot is policy-routed strictly through the WireGuard tunnel.

Modern Bookworm Architecture: NetworkManager replaces dhcpcd and leverages the built-in dnsmasq-base plugin for DHCP and DNS caching, eliminating the need for standalone services like isc-dhcp-server.

1. Create the Wi-Fi Hotspot Profile in NetworkManager

Create a hotspot connection in the Raspberry Pi desktop Network GUI or via nmcli. Set the hotspot subnet to 10.0.1.1/24, enable auto-connect, and set MTU to 1420.

To enforce robust WPA2-only (RSN/AES) authentication and disable legacy WPA1:

nmcli con modify "Wi-Fi Hot" 802-11-wireless-security.proto rsn

2. Configure Policy Routing Table

Create a dedicated routing table for hotspot clients (subnet 10.0.1.0/24):

echo "200 INET2" | sudo tee -a /etc/iproute2/rt_tables

3. WireGuard Configuration (/etc/wireguard/wg0.conf)

Configure WireGuard with policy rules and MSS clamping to ensure seamless MTU handling through the tunnel:

[Interface]
PrivateKey = YOUR_PRIVATE_KEY
Address = 10.10.0.6/24
PostUp = iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE; ip rule add from 10.0.1.0/24 table INET2 priority 100; ip route add default dev wg0 table INET2; ip route add 8.8.8.8/32 dev wg0; ip route add 8.8.4.4/32 dev wg0; iptables -t mangle -A FORWARD -o wg0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu; iptables -t mangle -A FORWARD -i wg0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu; ip route flush cache
PreDown = iptables -t nat -D POSTROUTING -o wg0 -j MASQUERADE; ip rule del from 10.0.1.0/24 table INET2 priority 100; ip route del default dev wg0 table INET2; ip route del 8.8.8.8/32 dev wg0; ip route del 8.8.4.4/32 dev wg0; iptables -t mangle -D FORWARD -o wg0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu; iptables -t mangle -D FORWARD -i wg0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu; ip route flush cache
Table = off
MTU = 1280

[Peer]
PublicKey = SERVER_PUBLIC_KEY
AllowedIPs = 0.0.0.0/0
Endpoint = YOUR_VPN_SERVER_IP:PORT
PersistentKeepalive = 25

4. Enable Kernel IPv4 Forwarding

Enable packet forwarding in /etc/sysctl.conf:

sudo sysctl -w net.ipv4.ip_forward=1
echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.conf

5. DNS Configuration for DHCP Clients

Configure NetworkManager's shared dnsmasq instance to supply public DNS servers to hotspot clients:

sudo mkdir -p /etc/NetworkManager/dnsmasq-shared.d/
echo "dhcp-option=option:dns-server,8.8.8.8,8.8.4.4" | sudo tee /etc/NetworkManager/dnsmasq-shared.d/dns.conf

6. Monitoring and Verification

Check active DHCP leases granted to Wi-Fi clients:

cat /var/lib/NetworkManager/dnsmasq-wlan0.leases

Verify dnsmasq runtime process parameters:

ps aux | grep dnsmasq

How to Forward Public IP Traffic to a WireGuard Client Behind NAT While Preserving Client IPs

When exposing a local server located behind a residential CGNAT (Carrier-Grade NAT) to the public internet using a cloud VPS as a front-end gateway, standard DNAT/MASQUERADE setups rewrite incoming packets with the WireGuard gateway's internal IP. This destroys client IP visibility, making rate-limiting, geo-blocking, and security auditing impossible. Here is how to configure policy-based routing and iptables PREROUTING to preserve the original client IP all the way to your backend application.

Architecture: Public Client (IP: X) → Cloud VPS (Public IP: Y) → WireGuard Tunnel → Home Server Behind NAT (Sees Real Client IP: X)

1. Cloud VPS Gateway Configuration

On the cloud VPS, forward external ports directly through the WireGuard interface (wg0) without applying SNAT/MASQUERADE to the incoming packets:

# Enable IP forwarding
sysctl -w net.ipv4.ip_forward=1

# Forward HTTP port 80 to WireGuard client (10.200.200.2)
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 10.200.200.2:80
iptables -A FORWARD -p tcp -d 10.200.200.2 --dport 80 -j ACCEPT

2. Home Server Policy Routing (The Secret to Preserving IPs)

Because the incoming packet preserves the public client IP, the home server's reply would normally route through its default residential gateway rather than returning via the WireGuard tunnel (causing asymmetric routing drop). Resolve this using Linux policy routing:

# 1. Create a custom routing table
echo "200 custom_vpn" >> /etc/iproute2/rt_tables

# 2. Route responses to traffic arriving on wg0 back through wg0
ip rule add from 10.200.200.2 table custom_vpn
ip route add default via 10.200.200.1 dev wg0 table custom_vpn

Now your backend web application logs the true public client IP address for every visitor!

How to Build a Dedicated WireGuard VPN Wi-Fi Gateway and LAN Router

Rather than manually configuring WireGuard client software on every smartphone, laptop, and smart TV in your home, you can configure a dedicated Linux machine (such as a Raspberry Pi, Orange Pi, or spare PC) as a standalone VPN Wi-Fi Gateway. Any device connecting to the designated Wi-Fi access point or Ethernet LAN automatically has all its traffic encrypted and tunneled through your remote WireGuard VPS.

Topology: Wi-Fi Clients → Access Point Router → Linux Gateway (dnsmasq + NAT) → Encrypted WireGuard Tunnel (wg0) → Cloud VPS Gateway

1. Cloud Server Configuration (/etc/wireguard/wg0.conf)

[Interface]
Address = 10.200.200.1/24
ListenPort = 51820
PrivateKey = SERVER_PRIVATE_KEY
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = GATEWAY_PUBLIC_KEY
AllowedIPs = 10.200.200.2/32

2. Linux Gateway Router Setup (wg0.conf)

[Interface]
Address = 10.200.200.2/24
PrivateKey = GATEWAY_PRIVATE_KEY
DNS = 1.1.1.1

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = VPS_PUBLIC_IP:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

3. Routing and NAT Masquerading

Enable IPv4 packet forwarding and route traffic arriving on your local LAN NIC (e.g. eth1) through the WireGuard interface (wg0):

echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
sysctl -p

iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
iptables -A FORWARD -i eth1 -o wg0 -j ACCEPT
iptables -A FORWARD -i wg0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT

Setting Up an IKEv2 VPN with StrongSwan Between a NATed Linux Client and Server

Configuring a secure, roadwarrior-style IKEv2 IPsec VPN using StrongSwan allows a client behind a residential NAT router (such as a standard home DSL/Cable modem) to establish an encrypted tunnel to a remote dedicated server.

Topology: Client: Ubuntu (behind NAT) • Server: CentOS with StrongSwan 4.6.x (Public IP) • Protocol: IKEv2 with X.509 certificates

1. Server Configuration (/etc/ipsec.conf)

Define the IKEv2 connection on the server. The server listens on its public IP, provisions virtual IPs to clients from 10.10.3.0/24, and routes default internet traffic:

conn win7
    left=SERVER.IP.ADD.RESS
    leftcert=server.cert
    leftid=@server.domain.com
    leftsubnet=0.0.0.0/0
    right=%any
    rightsourceip=10.10.3.0/24
    keyexchange=ikev2
    auto=add
    leftfirewall=yes

2. Client Configuration (/etc/ipsec.conf)

On the client machine behind NAT, set left=%defaultroute and request an IP dynamically from the server via leftsourceip=%config:

conn ike
    left=%defaultroute
    leftsourceip=%config
    leftcert=client.cert
    leftid=@client.domain.com
    leftfirewall=yes
    right=SERVER.IP.ADD.RESS
    rightsubnet=0.0.0.0/0
    rightid=@server.domain.com
    auto=add

3. Initiating the Connection

Start the IPsec tunnel from the client:

ipsec up ike

Check the status to verify security associations (SAs):

ipsec statusall