VPN on a router for a TV with no VPN app
Put a TV with no VPN app behind a router VPN: choose it by hardware address, check that it alone is in the tunnel, and see what happens when the tunnel drops.
Key takeaways
- 2 clients on one OpenWrt router, the TV stand-in and a Direct client, gave 2 different answers to the same address lookup in our run: the tunnel's address and the router's own.
- The router chooses by hardware address, never by app or website, so a TV that changes its hardware address drops out of the tunnel in the mode where you tick devices.
- Every device except is the OpenWrt mode that kept a re-addressed TV in the tunnel, and it also put a re-addressed Direct client into the tunnel.
- In our lab run on 2026-10-16, when the client could not start, 49 of 49 probes from the TV stand-in failed under the Strict kill switch level, while under Standard 48 of 49 answered direct.
On this page (9)
- Which route fits a TV: an app on the box or a router VPN?
- How did we test one TV and one Direct client?
- How do I choose the TV on an OpenWrt router?
- How do I check that only the TV is in the tunnel?
- What happens when the TV changes its hardware address?
- What happens to the TV if the tunnel goes down?
- Can a MikroTik router put a TV behind the VPN?
- Which router do I need?
- Does a router VPN protect the TV when it leaves home?
A TV with no VPN app is not a dead end. It never has to run anything. The router can run the VPN and decide, device by device, whose traffic enters the tunnel.
Which route fits a TV: an app on the box or a router VPN?
If the TV has an app, use the app; if it has none, run the VPN on the router. Which one you need depends on the TV, and the table lists the routes our other pages cover.
| Your TV | Route | Where to read it |
|---|---|---|
| Apple TV | The Apple TV app on the box itself | Apple TV download page |
| Android TV or Google TV with Google Play | The Android app, driven by the remote; read the Working verdict, the one that says data flows both ways, on its details screen | VPN on Android TV |
| A TV where no app is listed, such as Samsung Tizen or LG webOS, or a TV with an app you would rather leave alone | Nothing on the TV; the router runs the VPN and the TV is ticked in its device list | This page |
The cost of the router route is plain: everything you tick shares one tunnel and one location, and the router protects nothing once a device leaves your home. If you are still weighing OpenWrt against MikroTik, the comparison sets them side by side, and the OpenWrt overview covers the three ways to run a VPN on one.
How did we test one TV and one Direct client?
We ran an OpenWrt router and two clients in containers on one Mac, and recorded which address each client saw. Read this box before the results, because it limits what they mean.
How this was tested
- Product
- ForestVPN OpenWrt adapter (device modes, Direct switch, kill switch), shell files from fvpn commit f9613d17e8
- Version
- not a built package; the fv daemon did not run
- System
- OpenWrt 25.12.5 r33051 rootfs container (armsr-armv8-25.12.5), fw4, in a virtual machine on a Mac
- Checked
- Runs
- 1
Not tested
A single run on 2026-10-16, 09:36 to 09:50 UTC, inside private lab networks. No real ForestVPN account and no real exit took part.
The router here is a container: it has no Wi-Fi, no flash and no sysupgrade, and nobody drove a LuCI session. The TV is also a container, given a fixed hardware address.
Our tunnel is a stand-in, an IPIP link to a second container that does the masquerading. It is not the Noise_IKpsk2 tunnel, not the fv program and not a real exit. The harness played the daemon's part by sending the router the signal the client sends when its state changes, the way fv does.
Address lookups came from a small echo server that returns the address a request came from. An answer of "stand-in exit" means the request went through the tunnel, and "router" means it left the router directly.
Not tested: Wi-Fi against Ethernet, IPv6, real devices on a household router, router speed, and the tunnel's name resolver (lookups were by address). This OpenWrt is 25.12.5; the help page's lab leak suite ran on 21.02.7 and 24.10.8, and we do not transfer one to the other. In this run, under this configuration, on this date.
Treat the results below as a description of the router's choosing logic and its blocking, with nothing said about throughput or a real TV.
How do I choose the TV on an OpenWrt router?
Open Services > ForestVPN > Devices, pick a mode, tick the TV and press Save. ForestVPN's help page on device modes carries the steps, and its own status line says the setup is not yet verified on hardware as a whole: the lab leak suite passed on two older OpenWrt releases, and nobody has yet followed the steps on a household router full of real devices.
What you need first is an OpenWrt router with ForestVPN installed and linked (first run covers that), plus the TV connected once so it appears in the list.
- In LuCI, OpenWrt's web interface (the router's web page), open Services > ForestVPN > Devices. Devices appear once they connect, so switch the TV on and join the network first.
- Choose the mode Only the devices I choose.
- Tick the TV. Leave the other devices unticked; they stay on Direct. A TV with a fixed IP address does not appear in the list: add it by its hardware address instead.
- Press Save. The change applies within a few seconds, with no reboot.
- Read back the mode if you have a shell:
uci -q get forestvpn.main.modeprintschosen.
The router picks by device, which means by the hardware (MAC) address, which looks like aa:bb:cc:dd:ee:ff. It never picks by app or website. If you want site-based rules, the client can hand routing to passwall2, podkop or pbr; the coexistence page says which pairs were tried.
One plan covers every device behind the router, and on the Free plan that is one allowance for the whole home, so tick the TV and a few others rather than everything.
| Plan | Price | Billed |
|---|---|---|
| Free | – | 2 GB per connection, 5 connections a day |
| Monthly | $7.99 | per month |
| Yearly | $49.99 | per year |
How do I check that only the TV is in the tunnel?
On the TV, open a what-is-my-address page and on a second device, and compare the two answers. The TV should show the tunnel's address and the second device your home address.
The lab run did exactly this, with a lookup server in place of a public page. Here is the table, five lookups per client per round, three rounds.
| Mode | TV stand-in answered with | Direct client answered with | Lookups |
|---|---|---|---|
| Protection off (control) | the router's own address | the router's own address | 5 of 5 each |
| Only the devices I choose, TV ticked | the stand-in exit | the router's own address | 15 of 15 each, no exception |
| Every device except, Direct client listed | the stand-in exit | the router's own address | 15 of 15 each, no exception |
| Every device | the stand-in exit | the stand-in exit | 5 of 5 each, one round |
With the mode set to Only the devices I choose, the router held one rule, from the TV's IP address into its own routing table, and nothing else; it turns the ticked hardware address into that rule. One device, one rule, one table whose only way out is the tunnel: that is the whole mechanism. A device set to Direct is the per-device switch that keeps a console or a server out of it.
What happens when the TV changes its hardware address?
In the mode where you tick devices, a TV that re-addresses drops to Direct with no sign on the screen. The router identifies a device by its hardware address, and a private or random Wi-Fi address makes the same TV look like a new device.
The run gave the TV a new hardware address and resynced the router, as a lease event would. The result differs by mode.
| Mode | What changed | TV | Direct client |
|---|---|---|---|
| Only the devices I choose | TV re-addressed | answered with the router's address, no rule for it | unchanged, Direct |
| Only the devices I choose | TV set back | in the tunnel again | unchanged |
| Every device except | TV re-addressed (unlisted) | still in the tunnel | unchanged, Direct |
| Every device except | Direct client re-addressed | unchanged | answered with the stand-in exit, protected |
| Every device except | Direct client set back | unchanged | direct again |
It cuts both ways, and that is the awkward part. Except mode protects a new device by default, so a re-addressed TV stays covered. The same default catches a Direct client whose address no longer matches its entry: it goes into the tunnel, which is the safe failure and still a surprise if the client was a server you meant to reach from outside.
What to do about it is on the help page. Turn off the private Wi-Fi address for your home network on the device if it has the setting, or use Every device except the ones I choose, and if the router asks whether a new device is the same as an old one, answer yes to copy the setting. The run did not put a DHCP server in the loop, so the real sequence on a household network remains untested.
What happens to the TV if the tunnel goes down?
With the kill switch on, a protected TV loses its internet when the tunnel is lost and does not fall back to the home connection. A release is different: under the Standard level the TV goes back to the home connection in several cases, such as when the client cannot start, and only Strict keeps it blocked. The kill switch is never absolute, and the router's own traffic and any device on Direct sit outside it.
The kill switch help page names two levels, Standard and Strict. We removed the tunnel interface and probed both clients every 100 ms, for 15 to 30 seconds per run (levels).
| Run | Level | Event | TV stand-in probes | Direct client probes |
|---|---|---|---|---|
| Chosen mode | Standard | Tunnel lost | 97 of 97 failed, none answered direct | 97 of 97 answered direct |
| Every device except | Standard | Tunnel lost | 97 of 97 failed, none answered direct | 97 of 97 answered direct |
| Chosen mode | Strict | Tunnel lost | 49 of 49 failed, none answered direct | all direct |
| Chosen mode | Standard | Client cannot start | 48 of 49 answered direct | all direct |
| Chosen mode | Strict | Client cannot start | 49 of 49 failed, none answered direct | all direct |
When the tunnel returned, 92 of 93 TV probes in the first Standard run answered through it, and one probe failed. One router-address answer appeared in the Standard cannot-start run after the tunnel came back and before the router was told the state had changed.
If you want a TV that never uses your home connection, choose Strict. Standard releases protected devices in these cases (the kill switch help page lists them):
- you pause or sign out
- your plan's limit is reached
- this version is no longer accepted
- the client cannot start
- a firmware upgrade has run and ForestVPN is not installed again yet
A release shows nothing on the TV; a banner on the router's status page does. Tell whoever else watches the TV.
Run the ForestVPN client on your OpenWrt or MikroTik router, so a TV with no VPN app sits behind it.
Can a MikroTik router put a TV behind the VPN?
The MikroTik route exists, but we did not run it for a TV, and the traffic-choosing half is not recorded as verified on hardware. A MikroTik RouterOS 7 box runs the ForestVPN image as a container, with the same unmodified Noise_IKpsk2 handshake as the other clients; the WireGuard comparison says how it relates to WireGuard.
On the install page, the container is recorded as verified on real hardware: a cAP ax (arm64, RouterOS 7.24.1), which registered and connected.
The choose-traffic recipes, the optional part that decides which LAN traffic enters the tunnel, carry no verified-on-hardware status of their own, and the kill switch page opens with "Not yet verified on hardware as a whole. The three rules in steps 1 to 3 were each run on RouterOS 7.24.1; the stop-and-test in "Check it worked" has not been run on a router."
Two facts decide whether it works for a TV:
- The rules go on the box that routes your LAN. On an access point behind another gateway they do nothing.
- RouterOS recipes select by source address, not hardware address, so a TV needs a fixed address from a DHCP reservation.
Our reading is that you would narrow the routing-mark rule to that one address. We have not run that.
Which router do I need?
A router that runs OpenWrt, or a MikroTik. The minimum for MikroTik is RouterOS 7.21 or later with the container package (MikroTik download page).
On the OpenWrt download page each build is marked as tried on real hardware every release, built and tried in a lab, or built but not tried on that kind of hardware; read that mark first. OpenWrt 25.12 and newer is listed, but the page offers no install file for it yet, so check the page before you plan around a router on that release.
Without either, you have no managed route here. Use the Apple TV or Android TV row of the table above, with the app on the box.
Does a router VPN protect the TV when it leaves home?
No. A router protects only what sits behind it. A phone leaving the house needs its own app, and a travelling TV needs the box route in the first table. If a tunnel stalls with no internet, our guide to a VPN that is connected but has none takes the messages in turn, and net.degraded covers slow traffic through a live tunnel.
Questions and answers
Can I run a VPN on a TV that has no VPN app?
Yes, by running it on the router instead. The router sends the TV's traffic into the tunnel, so nothing is installed on the TV. The router must run a VPN client, and a TV on the same network can then be ticked in the router's device list.
How do I send only the TV through the router VPN and leave other devices direct?
On an OpenWrt router with the ForestVPN client, open Services > ForestVPN > Devices, choose the mode Only the devices I choose, and tick the TV. Everything you leave unticked stays on the home connection.
How do I check that the TV, and only the TV, is going through the tunnel?
On the TV, open a what-is-my-address page and on another device. The TV should show the tunnel's address and the other device your home address. If both show the same one, the choice did not take.
Does a router VPN work for a TV on Wi-Fi and on Ethernet?
Yes, but the router picks a device by its hardware address, and a TV's Wi-Fi and Ethernet adapters can have different ones, so moving it from Wi-Fi to a cable can be the same re-address trap: you may need to tick the TV once per link. Our run did not compare Wi-Fi with Ethernet: both clients sat on the router container's LAN bridge, so that question is open.
What happens to the TV if the tunnel goes down?
With the kill switch on, a protected TV loses its internet instead of falling back to your home connection. In our run that held when the tunnel was lost. The kill switch is not absolute, and under the Standard level the TV is released when the client cannot start, among other cases.
Which router do I need?
One that runs OpenWrt 21.02 or newer, or a MikroTik with RouterOS 7.21 or later and the container package. The OpenWrt download page lists each build and marks how far it has been tried; OpenWrt 25.12 and newer has no install file there yet.
Does the router protect devices that leave home?
No. A router VPN covers only devices on that router's network. A phone you take out of the house needs its own app.
How this was made
Drafted with AI assistance from a lab run on an OpenWrt router container and ForestVPN's router help pages, checked by automated gates and an editor; the method and its limits are in the Method box.