Hand LAN Hosts a VPN Return Route With DHCP Option 121

Remote VPN clients connect, the LAN server answers, and the reply leaves through the ordinary internet router and dies there. One server can be fixed with a static route, but a whole subnet of them is better handled where they already get their network configuration. DHCPv4 option 121 distributes exactly that kind of destination route, and it is the part people usually get wrong the moment they forget the default. The symptom is one-way traffic: requests arrive and replies vanish.

Name the three addresses first

Take a concrete LAN: 192.168.50.0/24 with the normal default router at 192.168.50.1 and a separate VPN gateway at 192.168.50.2. Authenticated remote clients occupy 10.90.0.0/24.

The route every participating host needs is 10.90.0.0/24 via 192.168.50.2. The destination is the client pool, and the next hop is the gateway's LAN address rather than its tunnel address.

Encode it as a classless static route

Option 121 carries prefix and next-hop pairs, and RFC 3442 defines both the encoding and the client behaviour that follows. For an existing dnsmasq instance serving only this illustrative LAN, the configuration shape is:

dhcp-option=121,10.90.0.0/24,192.168.50.2,0.0.0.0/0,192.168.50.1

That is a fragment, not a new DHCP service. On a server handling several segments, scope the option with the tags or network policy you already use. Keep the previous configuration to hand, because rolling this back means another lease renewal, not a reboot.

Do not lose the default route

This is the trap. A client that receives option 121 must ignore the ordinary Router option, so advertising only the VPN pool route can leave that host with no default route at all. The machine still looks configured and quietly loses the internet. Users describe that as the network being down while every interface is up.

Include the intended default in the same list, as the fragment above does. Keep the ordinary Router option in place as well, for clients that do not implement classless routes; the server's own option handling decides what is sent to whom.

Check what the client will accept

A manually addressed host never picks this up, because it is not asking for a lease. Client support also varies, so test on the operating system you actually run rather than assuming every device honours option 121. Confirm with whoever owns those servers which ones are statically addressed. Those hosts need their own route entries or they simply will not participate.

Managed DHCP services are another limit. Some cloud networks will not let administrators publish arbitrary options, and a competing DHCP server on the same segment is worse than no option at all.

Verify the lease, then the lookup

Have the DHCP owner apply the change, then renew the lease on a client. Existing leases keep the old configuration until they renew, so immediate results are not guaranteed.

On a Linux client, read the actual routes and confirm both entries:

ip -4 route
ip -4 route get 10.90.0.23

The contextual lookup should show the pool route through 192.168.50.2 and the default through 192.168.50.1. If the default is missing, you have reproduced the trap above.

Then test the real exchange

Route distribution is not the whole path. The separate gateway still needs forwarding, remote peer ownership and an access policy that permits the server, and DHCP authenticates nobody.

Finally, keep a removal plan. A learned static route does not withdraw itself when the VPN goes down, so a stale next hop can black-hole that prefix long after the tunnel is gone.