WireGuard peer connects but cannot reach devices on remote LAN — TCP timeouts while ICMP sometimes passes

Environment

WireGuard server on Ubuntu 22.04 VPS (public IP), home gateway is Raspberry Pi 4 running WireGuard and hosting LAN 192.168.50.0/24; clients are laptops and phones. Server uses nftables for firewall, clients use wg-quick on Linux/macOS.

Symptoms

Peer status shows handshake and transfer bytes on both ends. From a laptop connected to WireGuard client, ping to VPS succeeds. Pinging devices on the remote LAN (192.168.50.10) intermittently works for short bursts of ICMP but prolonged pings often return 'Destination Host Unreachable' or TCP connections to e.g. HTTP 192.168.50.10:80 time out while traceroute shows packets reach server and then stop.

Observations

Server wg show shows AllowedIPs for client includes 192.168.50.0/24. Server's sysctl net.ipv4.ip_forward=1 is set. nftables rules include input/forward policy allow for wg0, but there is no explicit POSTROUTING NAT rule for traffic from wg0 going out to the internet or to the LAN interface. tcpdump on server shows incoming packets from client to target LAN hosts but no return packets arriving at the server interface when a TCP connection attempt is made. On the home gateway, there are no routes back to the client's virtual IP if traffic arrives from the VPS public IP (i.e., source IP is the client's WireGuard IP).

Already attempted

Verified AllowedIPs and peer keys, disabled firewalld/nftables temporarily on server to rule out blocking, added broad accept forwarding rules, confirmed ip_forward=1 on both sides, restarted WireGuard and network services. Attempted to add 0.0.0.0/0 to client AllowedIPs then revert — no change for LAN reachability. Rebooted home gateway and tested direct ping from VPS to LAN host (works when NAT/SNAT applied on server).

Question

What reversible changes allow WireGuard clients to access the remote LAN hosts reliably (both ICMP and TCP), and how to determine whether the server or home gateway must perform NAT or route updates?

Post timeline

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses

AI DIAGNOSTICS

Incident analysis

Updated 1w ago• Trouble ID

Most likely causes

Home gateway lacks route for the client's WireGuard subnet and sends replies to the wrong next-hop. 95%

Missing SNAT/MASQUERADE on WireGuard server, so remote LAN hosts send responses to the server public IP but firewall/NAT rules drop them. 85%

Reverse path filtering (rp_filter) or strict firewall rules on home gateway or VPS dropping asymmetric return packets. 40%

Summary

The packets from a remote client reach the WireGuard server and are forwarded toward the destination LAN, but return traffic from the LAN hosts is not being routed back to the original client IP because the LAN's gateway or the VPS lacks a route for the client's virtual subnet, or the return packets are sent to the server's public IP and blocked by stateful firewalls or reverse-path filtering. When NAT (MASQUERADE/SNAT) is applied on the server, return traffic gets translated to the server address and flows back, indicating lack of symmetric routing or missing route on the LAN side is the issue.

Suggested Fixes

Diagnostic step 1

On the VPS/server, add a reversible NAT rule to POSTROUTING that MASQUERADE traffic from the WireGuard subnet when going out to the destination interface, e.g., nftables: add rule ip nat POSTROUTING oifname "eth0" ip saddr <client-wg-subnet> counter masquerade. Test connectivity after adding and can remove rule to revert.

Diagnostic step 2

If you prefer no NAT, ensure the remote LAN's gateway (home gateway) has a static route back to the WireGuard subnet via the VPS's WireGuard endpoint IP. Add: ip route add <client-wg-subnet> via <server-wg-peer-ip> dev wg0 on the home gateway.

Diagnostic step 3

Check and temporarily disable reverse-path filtering on the home gateway and VPS (sysctl net.ipv4.conf.all.rp_filter=0) to test if rp_filter is dropping replies, then re-enable as appropriate and implement correct routing.