Hotspot Clients on a Pi Can't Reach the Home LAN Over a TUN VPN

Local Wi-Fi and Ethernet clients attach to the Pi's hotspot, pull an address from its DHCP scope, and load internet pages without complaint. The same clients then time out when they open a file share or a web UI on the home LAN, while the Pi itself reaches that LAN over the tunnel. Nothing in the wireless layer is broken. What is missing is a routed contract: the hotspot prefix has to be carried into the TUN interface, and something on the home side has to know how to send replies back to it. Both halves must exist before a single packet can finish the round trip.

Three attachments with three different jobs

A Linux Ethernet bridge forwards frames by destination MAC address. OpenVPN in TUN mode carries IP packets and has no MAC layer at all, so adding a local bridge never enrolls the tunnel as a port. The kernel TUN/TAP documentation spells out that split: a TAP device looks like an Ethernet interface, a TUN device does not. A design that bridges two local ports and then routes is a router, whatever the interface names say.

That distinction settles ownership. The clients' subnet, their default gateway and the DHCP authority for that scope belong to the Pi's local plan. Home DHCP broadcasts do not cross a routed tunnel, and no bridge setting changes it; pointing the clients at a home DHCP server is a separate, deliberate relay design with its own failure modes.

Keep the modem outside the client bridge too. A PPP attachment is not an Ethernet device wearing a different label, and pppd's documented default-route logic runs after IPCP negotiation and withdraws its route when that link drops. Copying a DHCP template and renaming every usb0 to ppp0 proves nothing about gateway, metric or lifecycle.

Choose the prefixes before you edit any config

Overlapping prefixes waste more evenings than firewall rules do, because an overlap sends the route lookup to the wrong interface even when the tunnel is healthy. Start by listing what already exists on the Pi, then read the result as four separate pools.

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

The first pool is the underlay address the carrier handed to the modem; it must stay out of every client-facing plan. The second is the tunnel subnet the server chose, often a private /24 of its own. The third is the hotspot bridge, and the fourth is the home prefix you intend to reach. In this walkthrough the hotspot gets 172.28.90.0/24 with the bridge at 172.28.90.1, and the home service LAN keeps 192.168.77.0/24, which dodges the 192.168.1.0/24 and 10.0.0.0/24 defaults that consumer routers ship with and the 100.64.0.0/10 carrier range.

Advertise the bridge address as gateway in the hotspot's DHCP scope and nothing else. Never hand hotspot clients a home address as gateway; they have no link-layer path to that segment.

Route each direction on the side that owns it

The Pi needs a route for the home prefix through the tunnel. Servers in server mode normally push that route, so first confirm forwarding is on and that the kernel resolves a home address out of tun0.

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

If ip route get still reports the underlay interface, stop there; nothing further down the path can repair a wrong lookup.

Home devices have no route to 172.28.90.0/24, so their replies follow the default gateway and die at the router. Two supported repairs exist. Either add a static route on the home router that points the hotspot prefix at the VPN server's LAN address, or, when the server is itself the gateway, register the client prefix in the server's own routing table. In OpenVPN's multi-client mode the client-specific directory carries that association: a file named after the client's certificate common name, holding iroute 172.28.90.0 255.255.255.0 plus the matching route line that installs it in the server kernel. A guessed kernel route on the server is not the same statement as telling the server which client owns the prefix.

Do not move the home network's DHCP service onto the VPN server to make this work. Replacing the default gateway for an entire house is a far larger change than adding one private return route, and it drags DNS, address reservations and every device that ignores the new lease into the failure.

Open forwarding without guessing at the firewall

Forwarding being enabled does not mean the packet is allowed through. Traffic from the bridge to the tunnel still hits the filter rules, and a default-drop forward policy drops hotspot traffic while the Pi's own traffic keeps working, which produces exactly the split symptom above.

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

Look for an accept rule from br0 to tun0 and the matching reply direction, and for a postrouting rule that may rewrite the source. If the chain policy is drop and no rule matches, add the narrow accepts and re-test rather than flipping the policy to accept.

Translation is a policy choice rather than a requirement. Source NAT toward the home LAN makes every hotspot client look like the Pi's tunnel address, which loses per-client attribution in home logs and breaks services that expect the original source. Routing without NAT keeps client addresses visible but depends on the return route above. Pick one and handle DNS and IPv6 the same way, because a working IPv4 path beside a broken IPv6 path still reads as half-broken in a browser.

Verify the round trip, then break it on purpose

Test from a hotspot client, never from the Pi, because the Pi's own traffic bypasses both the forward and the return path. Watch both interfaces while one client tries to reach a home service.

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

Read the two captures together. Requests on br0 that never appear on tun0 mean the Pi is not forwarding or the route points elsewhere. Requests on tun0 with no replies mean the home side has no return route or the server filtered the packet. Replies on tun0 that never reappear on br0 mean the reverse filter rule is missing, where the tunnel looks perfect and the client still sees nothing.

Then break the path deliberately. Bring the modem connection down and back up and re-run the route and capture checks; a route that survives the tunnel but vanishes on reconnect belongs in the connection profile, not in a one-off command. Confirm the tunnel's transport still leaves through the underlay and not through itself, the classic loop when a pushed default route is accepted without a host route to the peer.

Accept the design only when a hotspot client can resolve a home name, open a TCP service, and keep a session alive across one modem reconnect. If an application genuinely requires Ethernet-level discovery on the home segment, choose a supported Layer 2 design rather than describing the local bridge as bridged and waiting for broadcast to appear.