VPN clients and the LAN: when to use a separate zone

Putting the tunnel interface in the LAN zone is the shortest path to a working VPN, and it is usually the wrong default. It grants the remote client the same trust the wired LAN has, which is rarely what the task requires. A separate zone costs a few rules and makes the boundary visible. The decision is not whether zones are better; it is which three conditions apply to your network.

The zone name does not encrypt anything or authenticate a user. It only groups interfaces for the firewall's policy model.

What zone membership actually controls

A zone groups interfaces or traffic under the firewall's model. Its input, output and forwarding settings then govern different roles. Input is traffic to the router itself; forwarding is traffic through it to another host. OpenWrt's zone documentation treats input, output and forwarding as separate settings for exactly this reason.

An allowance from the VPN zone to the LAN zone is not automatically a reverse allowance. Forwarding rules are directional, and a rule that permits client-to-server traffic does not permit server-to-client sessions. A client that can open a connection to a server is not a client the server can open a connection back to.

That distinction is the reason a separate zone is useful: you can state each direction and each role explicitly. Write the direction next to every rule.

Decision one: input, forward, or both

If remote clients need DNS from the router, allow input for that service only. If they need to reach a file server, allow forwarding to that destination. Most VPN designs need both, but for different services.

Broad input access to every local service is almost never required. Treat router management as a separate decision from application access. If the router only needs to answer DNS, write that single allowance and leave the rest closed.

Decision two: which resources remote clients need

List the client ranges, the destinations and the services the VPN should provide before writing rules. A destination list is more useful than a trust label, because it survives a firewall migration.

Keep management interfaces separate from ordinary application access. A remote client that can reach a wiki does not thereby need the router's admin page or the hypervisor console.

If a permitted destination can relay onward, the zone boundary stops at the firewall, not at what the destination does next.

Decision three: how you will prove the boundary

Test an allowed flow and a deliberately denied one after every change. Proving that one website loads does not reveal an unintended broad grant. Test from the VPN client's address range, not from the LAN, and include the direction you expect to fail. Record both results next to the rule.

Preserve the gateway's recovery access before you modify remote zone policy. Use the persistent managed configuration rather than runtime edits, or the next reboot will restore the old trust. A copy of the previous configuration, stored off the device, is the cheapest rollback you will ever have.

When the network grows, document membership and rule purpose. A newly attached interface should not inherit privileges just because someone gave it a convenient zone name.