WireGuard handshake works but the office subnet does not answer

The handshake completes, wg show reports recent transfer, and the server's tunnel address answers a ping. A host on the server's LAN does not. Three conditions have to hold at once: the client must route the LAN prefix into the tunnel, the server must forward the packets, and the reply needs a path back. When one of the three is missing, the symptom is identical.

AllowedIPs is an access list and a routing table

On the client, the AllowedIPs list decides both what may be sent to that peer and which routes WireGuard installs. A peer entry that lists only the server's tunnel address installs one host route, so LAN destinations never enter the tunnel. Adding the LAN prefix is the first thing to verify, and it is also the change most likely to be missing after a copied configuration. A peer widened to a default route is a different design, and it will move the client's internet traffic as well.

Keep the host route and the LAN prefix as separate entries. If the office has two subnets, both belong in the list, and the missing second prefix produces a failure that looks selective rather than total.

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.66.0.1/32, 192.168.50.0/24

Forwarding and translation belong on the server

The server needs IP forwarding enabled, a forward rule that accepts traffic arriving from the tunnel, and a translation rule toward its LAN interface. The translation is what makes the design work without touching every host on the office network. Replies then return to the server rather than to an address the LAN has never heard of. Without it, each host needs a route for the tunnel subnet and a firewall rule that permits it, which is rarely acceptable on a network somebody else manages.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i wg0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Rules added by hand disappear at reboot, so tie them to the interface with the hook commands in the server configuration. A rule set that outlives its interface is how a machine ends up translating traffic for a tunnel that no longer exists.

When the LAN moved and the rule did not

A router replacement that renumbers the office subnet is the classic version of this failure. The tunnel stays up, the handshake stays fresh, and nothing behind the server answers, because the translation rule still names the old address. Installer scripts often bake the server's LAN address into a POSTROUTING rule, and after a renumber that address exists on no interface. Packets are then rewritten to a destination that cannot answer.

iptables -t nat -n -L POSTROUTING
ip -br addr show

Compare the two outputs. A translation target that does not appear in the interface list is the bug, and fixing it is a one-line change once you have seen it. The rule may live in a generated unit rather than in the WireGuard configuration, so reload that unit after editing and confirm the next boot does not rewrite your change.

Two sites behind NAT need somewhere to meet

When neither side accepts inbound connections, the practical answer is a small host with a public address and two WireGuard interfaces. Each site connects outward, the middle host lists each peer's LAN in its own AllowedIPs, and forwarding carries packets between the two tunnels. Nothing about either site's firewall has to change, which is why this design spreads easily.

Routing between the sites keeps the original source addresses and therefore keeps per-host logging meaningful. Translating at the middle host is simpler when the two LANs overlap, at the cost of losing the source identity in the logs. Decide which property matters before you pick.

Separate the layers with four checks

Run one check per layer rather than changing three things and hoping. The first shows handshake age and counters for each peer. The second shows whether the client actually routes that destination into the tunnel. The third and fourth tell you whether the request arrived and whether a policy dropped it after arrival.

wg show
ip route get 192.168.50.20
tcpdump -ni wg0 icmp
iptables -vnL FORWARD --line-numbers

A request that arrives and draws no reply points at the reply path or at the LAN host. A request that never arrives points at AllowedIPs or at the client's route. Those two outcomes need different fixes, and the capture is what tells them apart.