Build a Raspberry Pi Split-Tunnel Travel Gateway with WireGuard

Expected Outcome

A client behind the Pi reaches defined home-lab subnets through WireGuard while ordinary internet traffic follows the travel WAN path; routing, DNS behavior, and rollback are observable.

Assumptions

• Raspberry Pi with two distinct network roles/interfaces (travel WAN and client LAN/AP/ethernet)

• A reachable home WireGuard endpoint with DDNS/static address if required

• A non-overlapping travel-client subnet and home-lab subnet

• Control of forwarding/firewall/NAT on the Pi and return routing/NAT at home

• An external network for validation; do not test only from the home LAN

Bill of Materials

• Raspberry Pi OS installed on the microSD card

• WireGuard software

• SSH client (e.g., PuTTY or Terminal)

Build Steps

1. Draw the two-interface routing topology

   Document WAN interface/address source, client-facing interface/subnet, Pi client gateway address, WireGuard tunnel subnet, home endpoint, and home networks to route. This lab uses split tunneling; internet traffic is not sent through home unless intentionally changed later.

2. Build the client-side gateway first

   Configure the Pi to provide or use a stable client-side subnet, enable forwarding, and prove a connected client can reach ordinary internet through the travel WAN before WireGuard is introduced.

3. Configure WireGuard using literal config values

   Generate unique keys and create server/client peer configuration with explicit Endpoint, tunnel addresses, and AllowedIPs for the home-lab subnet only. Do not put shell command substitution inside wg0.conf examples.

4. Add the minimum forwarding/NAT/return path

   Permit client-subnet traffic to the home-lab subnet through wg0. Use either proper return routes or scoped NAT according to the lab design and document which one is used.

5. Define DNS behavior

   If internal home names are required, send only the relevant suffix/queries to the home resolver or configure the travel client accordingly. Keep public DNS behavior explicit so a DNS problem cannot be mistaken for a tunnel failure.

6. Validate from an external network

   From a client behind the Pi on a network outside the home, verify public internet egress uses the travel connection while a route lookup and TCP test to a home-lab service use the WireGuard path. Query one internal name if configured.

7. Run failure and rollback tests

   Bring down wg0 and confirm only home-lab reachability disappears while ordinary internet remains. Restore it, retest, then document how to disable forwarding/rules and return the Pi to ordinary client mode.

Validation

• Client reaches internet before and after WireGuard through the intended travel WAN

• WireGuard handshake occurs from an external network

• Route lookup for the home subnet points to the WireGuard path

• A real TCP/HTTP request to a home test service succeeds

• Internal DNS works only if explicitly configured

• Disabling wg0 removes home reachability without breaking normal internet

Troubleshooting

• Handshake absent: endpoint/DDNS/UDP/firewall/key issue

• Handshake present but no home path: forwarding, AllowedIPs, return route/NAT, or home firewall

• IP works but name fails: split-DNS/resolver issue

• Avoid 0.0.0.0/0 until the split-tunnel design is fully proven

Cleanup or Rollback

• Remove lab client routes/NAT/firewall rules and disposable peers if dismantling

• Revoke/delete travel-gateway keys that will no longer be used

Next Improvements

• Secure your Raspberry Pi with additional firewall rules.

• Explore advanced WireGuard configurations for multiple clients.