Multi-router Pi VPN: put each route on the device that decides

Putting a Wi-Fi box behind the Pi turns one routing decision into four, and the plan breaks when all four are made on one device. The first question is not which route to add. It is whether the new box bridges or routes, because that answer decides how many subnets exist and which devices must learn about them. Choose the attachment model first; every route follows from it.

Bridged or routed: the choice that sets the count

A bridge puts the new clients on the same subnet the Pi already serves. One subnet, one DHCP authority, and no handoff to route. This is the simpler arrangement and the right one when a separate client network was never a requirement. A routed link is a different design: the box keeps its own subnet, and that prefix must be carried everywhere the traffic goes.

The rest of this plan keeps the downstream router and preserves client source addresses. The target is one private VPN network, not a full internet exit. Write the model down before the addresses, because the list below is only an example of a routed attachment.

client subnet       10.41.0.0/24
client gateway      10.41.0.1
router-to-Pi link   192.168.71.2
Pi on that link     192.168.71.1
private target      10.72.9.0/24

Who decides what

Each device makes one decision, and none can make another's for it. The Pi needs two entries, not one, and the return path is the one people forget. Forwarded traffic reaches the private network correctly and then dies on the way back, because the Pi has no idea where 10.41.0.0/24 lives. That looks like a firewall problem and is really a missing route.

The remote side needs its own route as well. If the service at the far end does not know that 10.41.0.0/24 is reachable through your tunnel, replies stop at the first hop that has no answer. Add both directions before reading packet filters.

Next hops come from the attachment

A next hop must be an address on a network the device can actually reach. The VPN peer's public address is not the next hop for a private subnet, and the distant service network is not a next hop at all. A route to an unreachable gateway looks correct in a listing and drops every packet. Check that the gateway answers before blaming the destination.

Keep the Pi's outer VPN peer reachable through its own underlay route. That entry is separate from the payload routes, and mixing them gives a tunnel that cannot re-establish after a path change.

The static route documentation makes the destination-versus-gateway distinction clear even though every platform labels its menus differently. Read the documentation for the device in front of you rather than copying another vendor's screen. The commands below show the shape of the entries on Linux.

# on the Pi
ip route add 10.41.0.0/24 via 192.168.71.2
ip route add 10.72.9.0/24 dev tun0
# on the downstream router
ip route add 10.72.9.0/24 via 192.168.71.1

What translation does to the source

If the downstream router already translates its clients to the transit address, the Pi sees one translated source instead of each client's own address. That is a different design from the source-preserving one above. It changes source-based policy, logging, and which side can initiate connections. Both designs work; they answer different questions.

When an upstream VPN service refuses to route the client prefix back, a narrow translation at the Pi's tunnel egress can be a legitimate workaround. It is not evidence that the missing route was unnecessary. Record which address the remote network actually sees and what return path results.

Route selection, forwarding permission and source translation remain three separate jobs. Flushing a shared NAT chain or allowing every interface because one wired client works is how a working test becomes an open forwarder.

Proving it from a client machine

Send a request from a machine on the downstream LAN, then follow its source out and back. A ping issued by the Pi never exercises the downstream return route, which is why a successful one proves less than it appears to. Add a second test from a wired client on the Pi's own LAN so the two paths can be compared. Repeat both after rebooting either device.

Routes added by hand and translations that were never persisted disappear together. The pair then looks like a new fault rather than an unfinished one.

Save the attachment model with the routes, the permitted private service and any translation in one note. That note is what stops the next person from treating wireless placement as a routing policy question.