FRITZ!Box Static Route: Point It at the VPN Gateway LAN IP

Your home LAN has a FRITZ!Box as the default router and a small Linux box doing VPN duty next to it. The box can reach the office network, and the laptop behind the FRITZ!Box cannot. A static route fixes this in three fields, and the only real difficulty is refusing to put a tunnel address in the gateway field. The gateway is the next router on your own LAN, and it always was.

Write the three fields before opening the UI

Take a LAN of 192.168.50.0/24, a FRITZ!Box at 192.168.50.1, and a VPN box with a fixed address of 192.168.50.2 that already has a working protected path to 10.40.0.0/16. The route says: for that remote prefix, hand the packet to the device at the fixed LAN address. The remote VPN server's public endpoint and its inner tunnel address are both irrelevant here, because the FRITZ!Box never sends anything to them directly.

Reserve that LAN address outside the DHCP pool, or the gateway you configured will one day belong to a phone.

Where the FRITZ!Box keeps the route

FRITZ! opens the IPv4 route controls under Home Network, then Network, then Network Settings, with the exact label and nesting depending on the model and FRITZ!OS version. Enable the advanced view if the route table is hidden, add one entry with the values above, and apply. The guide for your specific model is worth a glance, since the same function has moved between releases more than once. Note the exact wording of the entry you save, because a table entry rarely tells you which screen produced it.

This is not the same feature as the FRITZ!Box terminating a VPN itself. A route points at another device; the built-in VPN is the device.

The gateway has to route, not just reach

A host that can reach the remote network is not automatically a router for the rest of the LAN. The VPN box needs IP forwarding enabled, a firewall policy that permits forwarding between the LAN interface and the tunnel, and a route that sends the reply back to the LAN rather than out of its own default path. Enabling forwarding and forgetting the firewall rule is the most common half-fix, and it looks like a routing failure from the client.

Check it from the FRITZ!Box side by pinging the VPN box's LAN address, then from a client by tracing to a remote address and confirming the second hop is that box.

Return path and overlapping ranges

The remote side needs a route for 192.168.50.0/24 back through the tunnel, unless you deliberately translate the source at the VPN box. Preserving and translating are different policies with different logs and different access rules, and the static route you just added does not choose between them. Overlapping ranges are a harder problem: if your LAN and the remote network share a prefix, a single host route cannot disambiguate them, and the address plan needs to change.

Adding a more specific route somewhere else on the LAN, or a second VPN client on the laptop, will quietly win over the FRITZ!Box entry.

Test from a normal client, then test the failure

Run the test from an ordinary authorised LAN machine, not from the VPN box, because the box was already working and proves nothing. Reach a remote service and check the reply, then confirm that unrelated internet destinations still take the default route and are not being dragged through the tunnel. Replacing the default route to reach one subnet is a much bigger change than the three-field entry you started with.

Finally, disconnect the VPN and see what happens. The static route stays in the table while its gateway has lost the protected path, so traffic fails at the box rather than falling back to the internet, and any requirement to block fallback traffic belongs in the box's own policy rather than in a saved route.