OpenWrt: VPN for chosen devices only

You can send one phone through a VPN on OpenWrt and leave the rest of the house alone. Two ways are compared here: pbr, OpenWrt's policy-based routing package, which chooses by where traffic comes from or goes to, and the ForestVPN client's device modes, which choose by device only.

A third way, a separate guest network or VLAN whose whole subnet is routed into the tunnel, is not covered. The two we compared fail in different places, so we ran both on the same two clients to see where.

How do I send only some devices through a VPN on OpenWrt?

Pick the devices by source address and send that address into a routing table whose way out is the tunnel. Strict enforcement or the kill switch is what keeps it there when the tunnel stops. That is the whole mechanism, and both tools build it.

pbr is third-party software in the OpenWrt package feeds. Its documentation says it routes by IP, MAC address, port, protocol or domain, and supports WireGuard and OpenVPN interfaces.

The ForestVPN client does the same job with a smaller menu, the ForestVPN device modes:

• all devices
• only the ones you tick
• all except the ones you list

If you came for a route by website, jump to the last table.

You will need:

• an OpenWrt router with a tunnel interface already up
• SSH or LuCI (OpenWrt's web interface) with uci, OpenWrt's command-line configuration tool
• the hardware addresses of the devices you want, which look like aa:bb:cc:dd:ee:ff

On OpenWrt 22.03 and later the firewall is fw4, and pbr builds nftables rules in it. Netifd, OpenWrt's network daemon, owns the tunnel interface it routes into.

How can you check which devices use the VPN on OpenWrt?

An echo server returns the address a request came from, so an answer with the tunnel's address means the tunnel and an answer with the router's address means direct. We ran two LAN clients behind an OpenWrt router container and asked such a server from each. Read the box first, because the limits matter more than the results.

Tip for your own test: a destination on the router's own connected network is routed by the main table before pbr's rules apply, so test against an address outside the LAN and WAN subnets. Every result below used such an address.

How does pbr pick a device: by IP or by MAC address?

pbr takes either one in the same field, so a policy can name an IP address or a colon-separated MAC address. The pbr documentation lists IP addresses, CIDRs, host names and MAC addresses as valid entries for the source field, and in our run each form became a different packet-matching rule.

Steps for the pbr arm, in the order we did them:

1. Install pbr from the OpenWrt feed. We used apk, which OpenWrt 25.12 ships in place of opkg.
2. Enable pbr: it ships disabled.
3. Add the tunnel interface to pbr's supported interfaces and put the tunnel device in a firewall zone. Only a hand-made tunnel needs a zone: the ForestVPN client already puts its forestvpn interface in its own forestvpn zone (see the coexistence page).
4. Add one policy per device.
5. Look up an address from the chosen client and from a client you left alone, and compare.

Here is the policy we ran, first keyed on the client's IP address. The network name forestvpn is the ForestVPN client's own interface; if you built the tunnel by hand, use your own interface name (for example wg0) in both blocks.

Adds a pbr policy that sends one LAN address into the tunnel interface

uci set pbr.config.enabled='1'
uci set pbr.config.supported_interface='forestvpn'
uci add pbr policy
uci set pbr.@policy[-1].name='tv_by_ip'
uci set pbr.@policy[-1].src_addr='192.168.1.101'
uci set pbr.@policy[-1].interface='forestvpn'
uci commit pbr
/etc/init.d/pbr restart

Our first attempt failed quietly. The policy and the routing rule were in place, and the packet mark pointed at a table whose default route was fvpn0. Yet all 5 of 5 lookups from the chosen client failed, because the tunnel device was in no firewall zone and the forward chain dropped it.

For a hand-made tunnel the zone is one more block of uci, shown below. The run itself put the device in the wan zone with masquerading, and this separate-zone block was not run. With the ForestVPN client installed, skip it, because the client already has its zone. Keep each network in one zone only.

After the zone was in place and pbr restarted, the chosen client answered "stand-in exit" and the other client "router", in 3 rounds of 5 lookups each, with no exception.

Adds a firewall zone for a hand-made tunnel device

uci add firewall zone
uci set firewall.@zone[-1].name='vpn'
uci set firewall.@zone[-1].network='forestvpn'
uci set firewall.@zone[-1].masq='1'
uci set firewall.@zone[-1].input='REJECT'
uci set firewall.@zone[-1].forward='REJECT'
uci set firewall.@zone[-1].output='ACCEPT'
uci add firewall forwarding
uci set firewall.@forwarding[-1].src='lan'
uci set firewall.@forwarding[-1].dest='vpn'
uci commit firewall
/etc/init.d/firewall restart

Swapping src_addr for aa:bb:cc:00:00:01 gave the same split. pbr rendered that policy as an nftables rule on the source hardware address, so the lease no longer mattered.

What happens when a phone changes its Wi-Fi address?

A policy keyed on a hardware address stops matching the moment the device presents a new one. The device modes page says a phone that uses a changing private Wi-Fi address looks like a new device each time, and the router then sees a device the policy never named.

We changed the chosen client's hardware address and lease together, as a rotation would, then each field alone. The first table covers pbr, the second the ForestVPN modes.

The failure is silent. Nothing on the phone changes; its traffic just takes the other road. The fix is the one the ForestVPN device modes page gives: turn the private address off for your home network on the phone, or choose by exclusion. Choose by exclusion is a ForestVPN mode, not a pbr option.

How do the ForestVPN device modes pick devices?

They pick by hardware address, in one of three modes, and the router turns the choice into routing rules for the chosen devices. The device modes page carries the steps.

It opens with a status line we quote as written: "Not yet verified on hardware as a whole. The three modes and the Direct switch passed the lab leak suite on OpenWrt 21.02.7 and 24.10.8. They have not yet been followed on a household router with a mix of real devices."

1. Open Services > ForestVPN > Devices and pick a mode: Every device, Only the devices I choose, or Every device except the ones I choose.
2. Tick the devices for the second mode, or list the exceptions for the third. Set a device that should stay direct to Direct.
3. Press Save. The change applies within a few seconds, with no reboot.
4. Read the mode back with uci -q get forestvpn.main.mode, which prints all, chosen or except.

In the run, the chosen mode behaved like the pbr policy: the ticked client answered "stand-in exit" and the other "router", 3 rounds of 5. Every device put both clients in the tunnel.

Of the two modes we re-addressed, except is the one that did not drop a device, and it cuts both ways. A re-addressed Direct client went into the tunnel, which is the safe failure and still a surprise if that client is a server you reach from outside.

One lab condition matters here. The run had no DHCP server, so the adapter fell back to the router's neighbour table. After repeated address changes it held two addresses for one hardware address and wrote a rule for each.

Shipped code takes a leased device's address from its lease only and uses the neighbour table only for devices without a lease. A device with a lease is therefore matched by its current lease. We did not test that path.

Every device behind the router shares one plan and one location. On the Free plan that is one allowance for the whole home, so tick a few devices rather than all of them.

What happens to VPN-routed devices on OpenWrt when the tunnel goes down?

With pbr's strict_enforcement at 1, or with ForestVPN's kill switch, none of the chosen client's probes went direct; with strict_enforcement at 0, 115 did. That one pbr setting is the difference between a block and a leak. We removed the tunnel for 12 seconds and probed both clients every 100 ms over 30 seconds, a variant of the stop-and-test idea on the kill switch page, which stops the ForestVPN program instead.

pbr's documentation describes strict_enforcement as: "Drops traffic matching a policy if the target interface is down, functioning as a kill switch to prevent data leaks via the default gateway." The default is 1. We ran it both ways.

With strict enforcement off, pbr let the chosen client fall back to the router's own connection while the tunnel was down: that is a leak by definition. With it on, the device waited.

The ForestVPN kill switch is never absolute. It covers the devices ForestVPN protects, not the router's own traffic and not a device on Direct, and under the Standard level the kill switch help page lists the cases that release protected devices, such as when you pause, when the client cannot start or after a firmware upgrade. Choose Strict if a protected device must never use your normal connection.

Can pbr and the ForestVPN client run together?

Yes for different devices; for the same one, we make no promise. In our run pbr sent one client into the tunnel by IP address while the ForestVPN chosen mode sent a second client there. Both answered "stand-in exit" while the Direct client answered "router".

The adapter's rule priority was 1901, ahead of pbr's policy rules at 29999 and 30000 and a main-table lookup at 29998; the coexistence page lists the numbers ForestVPN uses.

Overlapping devices, passwall2 and podkop were not tested.

For site-based choice the client can step back and let pbr route into fvpn0: press Let another app route. That button turns ForestVPN's protection and its kill switch off, and the coexistence page says "ForestVPN's kill switch does not cover traffic that pbr sends. pbr's own strict setting does that." It also says the pbr combination "has not been tested end to end". This run did not test it either: the pbr arm used a stand-in tunnel and the ForestVPN arm ran with protection on, in chosen mode.

See beside your other router software for the numbers each program uses and which pairs were tried.

Which should you pick: pbr, device modes or both?

Use the device modes when the question is which devices, and pbr when the question is which destinations. The table maps each need to the tool, with the source of each cell.

• A handful of fixed devices and a route by site for others: run both and keep their devices apart. pbr by site beside the client was not run here, and the coexistence page sends site routing through Let another app route.
• Every phone in the house protected without keeping lists: choose Every device except and set the few exceptions to Direct.

For a MikroTik router the same question has a different set of recipes, and the OpenWrt overview covers the three ways to run a tunnel on one. If the tunnel is up and nothing loads, start with the connected-but-no-internet guide.