Second router as VPN gateway: what it does not solve

Putting a second router behind the main one is a clean way to give a few devices a different exit. It is also where people expect more isolation than the device delivers. The main network keeps its ordinary path, and the downstream network follows the second router's policy. What happens between them, and what happens when the tunnel fails, is the part worth planning.

The setup works. The myths are about what it protects. It is still a useful design; it is just not a security boundary by itself.

Myth: the second router isolates the tunnel completely

Devices behind the second gateway follow its policy. Devices on the main network do not inherit that tunnel, which is the point. But the second router still has an upstream path through the first, and that path is a relationship you have to manage.

The second router also needs a VPN client profile. A feature that only accepts incoming VPN connections does not create an outward tunnel to a provider. Check the firmware's client support before buying the hardware.

Give the downstream network a non-overlapping subnet. Copying a sample range without checking existing networks is a reliable way to create a routing puzzle.

Myth: double NAT is just the VPN encapsulation

Two routed gateways can create double NAT, and that is separate from the VPN's own encapsulation. Ordinary outgoing traffic usually works. Incoming service access needs a deliberate design, often a port forward on both devices or a different approach entirely.

The extra translation layer also makes logs harder to read. A source address in the main router's log may belong to the second router rather than the device you are debugging. That is worth knowing before you chase a phantom device.

Write the address plan down before you power anything on.

Myth: discovery crosses because both LANs browse fine

Both networks can browse the internet while discovery between them fails. A phone on the main Wi-Fi may not find a TV behind the VPN gateway, because multicast discovery does not cross a routed boundary by default. If that matters, you need a reflector or a different topology. Browsing success is not evidence of local discovery.

Keep the second router's management interface reachable from an authorized path without publishing it on the WAN. Save both gateways' configuration before you change routes.

Test DNS and IPv6 as well as the visible exit address. A tunnel that carries IPv4 only can leak the other family. Write both results into the change record.

What the second gateway does buy you

It makes scope visible. You can point at one device and say which network follows the tunnel, and the household keeps its ordinary path. That clarity is worth the extra hardware for many homes.

It is still another maintained device with credentials, firmware and a recovery process. Decide whether downstream devices should stop or fall back when the VPN fails, and test that behavior. The gateway does not remove the operational work; it concentrates it. The pfSense WireGuard client recipe covers the tunnel side on one common platform.