A home WireGuard tunnel needs a route back from the LAN

Home access is one private service, not a second internet exit. WireGuard terminates on a Linux box behind the router, the router keeps its existing job, and the laptop sends only the home prefix through the tunnel. Which device forwards and which one terminates is the decision every later rule follows from. Get that split wrong and you will debug NAT you never meant to add.

Decide who forwards and who terminates

The router owns the public entry: it accepts the UDP packet and passes it to the Linux host. That host owns the WireGuard listener and the forwarding decision into the LAN. In practice the mapping sends UDP 51820 to 192.168.50.10, and the application's own port stays closed. Keeping the roles separate keeps the firewall short.

Write the address plan before creating the interface. Router 192.168.50.1, gateway 192.168.50.10, service 192.168.50.20, tunnel 10.77.0.0/24 with gateway .1 and laptop .2. The tunnel range must not overlap a network the laptop already reaches, or destinations become ambiguous. Carrier-grade NAT or an upstream router can block incoming access, and no local port forward repairs that.

Exchange keys, then size the AllowedIPs

Create a separate key pair per endpoint and move only public keys through a verified channel. The gateway's peer entry allows the laptop's tunnel source alone, because the home LAN sits behind the gateway and not behind the laptop. Putting the LAN in that entry describes a topology you did not build.

[Interface]
Address = 10.77.0.2/32
PrivateKey = LAPTOP_PRIVATE_KEY_BASE64

[Peer]
PublicKey = HOME_PUBLIC_KEY_BASE64
Endpoint = home-vpn.example.com:51820
AllowedIPs = 192.168.50.0/24, 10.77.0.1/32

AllowedIPs is the home prefix plus the gateway's tunnel address, never 0.0.0.0/0, so ordinary browsing keeps its local path. Keep one configuration owner, and never attach the same interface to a second network manager.

The return route is the part people skip

This design keeps the laptop's 10.77.0.2 source instead of masquerading it as the gateway, so home devices must know how to answer it. Add a static route on the home router for 10.77.0.0/24 with 192.168.50.10 as next hop, and read what wg-quick derives from AllowedIPs in its reference. Without that route, a completed handshake coexists with application replies that never arrive.

If the router cannot carry that route, pick a documented return design. Quietly adding NAT instead changes the source model you just wrote down.

Permit one service, not the subnet

Enable IPv4 forwarding on the gateway and keep three firewall duties separate: admit the WireGuard listener, forward the laptop source to 192.168.50.20 only, and leave the rest of the home network closed to that peer. Integrate the rules with the firewall manager already in use instead of flushing it. A route for the whole home prefix is not permission to use every device inside it.

The application's own authentication and host firewall are a separate gate. Name the service the ruleset allows, so the next reviewer can check it against the intended task.

Test from outside, then retire cleanly

Bring the profiles up through their owner, confirm the handshake, then exercise the intended application from an approved outside network and check the reply. Attempt a home service that must stay denied, because a permissive rule is invisible until something uses it. For HTTPS, use the name on the certificate and let validation run; typing the raw address and clicking through the warning proves nothing about the path. PersistentKeepalive is optional: it helps a NAT-bound peer after idle time, but it is not a missing route or a permission fix.

A dynamic public address needs DNS updates, and the laptop needs to re-resolve its endpoint after a change; new DNS records do not move a configured endpoint. Retire the laptop by removing its peer from the stored and active configuration; deleting the laptop profile alone does not revoke the gateway's authorization.