Masquerade or policy routing: LAN traffic through a VPN gateway

Putting a whole LAN behind a VPN tunnel is the easy part; deciding how the far side sees those clients is not. Masquerading rewrites each LAN source to the gateway's tunnel address, so the remote end replies to one peer. Policy routing keeps the original addresses and requires the remote end to know how to reach them. Neither is a default; the choice follows from who owns the far side and whether per-device identity matters.

The two designs promise different things

Masquerade reduces the LAN to a single visible host: the gateway. The remote network answers that one address, and the gateway translates the replies back to the client that started the flow. No route to your private prefixes is needed on the far side, which is why this design survives a provider that refuses to carry them. The gateway also becomes the source of every connection, so the far side cannot tell two clients apart.

Policy routing keeps every client address intact. The remote network sees the actual source and can log it, apply a per-host rule or send the reply to that address directly. That visibility is the whole point, and it comes with an obligation: the far side must have a route for the LAN prefix that points back through the tunnel. Plan that route before you enable the rule, because the tunnel will come up either way and only the replies will be missing.

The failure modes differ as much as the promises. A missing masquerade rule produces packets that leave with private sources and never return. A missing return route produces the same symptom under policy routing, but the fix belongs on the remote router rather than on the gateway.

Masquerade: one peer on the far side

The masquerade path has an order that matters. Forwarding has to be enabled before any NAT rule does useful work, the filter table has to allow the transit in both directions, and only then does the translation apply on the tunnel interface.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Clients still need a path to the gateway. Either the gateway is their default router, or they carry a specific route for the remote prefix; if a separate router remains the default, that router needs a static route for the tunnel destinations, otherwise the packet goes to the wrong hop before the gateway sees it.

DNS is a separate decision. A resolver on the far side answers only if its reply can travel back to the client. Under masquerade the query appears to come from the gateway, so the resolver's return path is already satisfied; under policy routing the resolver needs the same route back as any other remote service.

Policy routing: keep the source, add a return path

Policy routing starts with a table and a rule that selects it. Traffic entering from the LAN interface is sent to a dedicated table, and that table carries a default route through the tunnel. The main table stays untouched, so traffic originated by the gateway itself can follow a different path.

ip rule add iif eth1 table vpn
ip route add default dev tun0 table vpn

The far side then has to route the LAN prefix back through the tunnel. That is a configuration on the remote router, not on this gateway. The gateway also has to accept replies that arrive on a different interface than the main table would predict; loose reverse-path filtering (rp_filter set to 2) is the usual adjustment when strict mode drops those packets.

When two tunnels are active, tag each flow as it enters and let the tag choose the table. A rule that looks only at the input interface sends both tunnels' traffic to the same table, so the second tunnel steals flows from the first. Test that tag with a connection that outlives a reconnect, which is when a mixed policy shows up.

Decide by ownership and by what the far side logs

If the tunnel ends at a provider, masquerade. That operator is not going to route your private LAN ranges, and it has no reason to distinguish individual clients behind your gateway. One visible peer is the only model its policy supports, so give it that and keep the translation at your edge. The provider sees one peer, which is exactly what its policy expects, and your clients inherit that single identity.

If both ends are yours and the remote services act on source addresses, policy routing earns its extra route. Firewall rules, per-user access and audit logs can then distinguish clients. If the remote side only needs reachability, masquerade is simpler and removes a class of return-route mistakes.

Hybrid designs are normal: policy routing inside your own network, masquerade at the provider edge. What matters is writing down which hop translates and which hop routes, because an accidental NAT rule added for one client hides the source for every client in the same chain.

Verify from a client, then from a second client

Run the test where the traffic starts. Check the route the host uses, watch the packet appear on the tunnel interface, and inspect conntrack for the translation. That sequence proves the packet took the intended path rather than merely arriving somewhere.

Repeat the test after a reconnect. A masquerade rule that names the interface survives a new tunnel address; a rule that names the old address does not. Then test a second LAN host, because a design that works on one machine often depends on that machine's own route rather than on the gateway policy.

Write the chosen model, the translated or preserved source, and the return-route owner into the gateway notes. The next person to add a client or a tunnel will otherwise guess, and a guess is how a working LAN-to-VPN setup becomes a partial one.