Last updated on August 26th, 2026 at 11:48 am
The main lesson: a working WireGuard tunnel is not enough to reach a private LAN behind one VPN client. The network needs route ownership, IP forwarding, firewall permission, and a return path.
What I learned
WireGuard uses AllowedIPs for two jobs: it decides which traffic enters the tunnel, and it tells each peer which destinations belong behind another peer.
If one VPN client is also a gateway to a local network, the server must associate that local network with the gateway peer. The gateway must then forward packets between WireGuard and its LAN interface.
A practical routing plan
- Assign the LAN route to one peer. On the server, add
PRIVATE_LAN_CIDRto the gateway client’sAllowedIPs. - Enable IPv4 forwarding. Turn on forwarding on the gateway client so traffic can move between the WireGuard and LAN interfaces.
- Allow forwarded traffic. Add firewall rules for traffic from the tunnel to the private LAN and for established return traffic.
- Provide a return path. Add a route on the LAN router, or use source NAT on the gateway client when changing the LAN router is not practical.
- Route other VPN clients. Add
PRIVATE_LAN_CIDRto their WireGuard peer routes unless they already use a full-tunnel route.
Server peer example
[Peer]
PublicKey = GATEWAY_CLIENT_PUBLIC_KEY
AllowedIPs = GATEWAY_CLIENT_VPN_ADDRESS, PRIVATE_LAN_CIDR
This tells the server that both the gateway client’s tunnel address and the private LAN are reachable through that peer.
Gateway checks
On the gateway client, confirm forwarding is enabled and identify the real LAN interface before adding rules:
sysctl net.ipv4.ip_forward
ip route get PRIVATE_LAN_GATEWAY
If the LAN router has no route back to the VPN subnet, source NAT can provide the return path:
iptables -t nat -A POSTROUTING \
-s VPN_SUBNET -d PRIVATE_LAN_CIDR \
-o LAN_INTERFACE -j MASQUERADE
Common mistakes and fixes
- Cause: the server does not know which peer owns the LAN route. Fix: add the LAN CIDR to that peer’s
AllowedIPs. - Cause: the gateway receives packets but does not forward them. Fix: enable IP forwarding and allow forwarded traffic.
- Cause: requests reach the LAN but replies disappear. Fix: add a return route or use source NAT.
- Cause: a remote client is already attached to a LAN using the same address range. Fix: renumber one network to a non-overlapping private subnet.
Conclusion
Think of the WireGuard client as a small router: it must advertise the private LAN, forward packets, and return replies correctly. The concrete next action is to draw the VPN subnet, gateway peer, and private LAN before changing any configuration.