Putting a VPN on an OpenWrt router can send selected devices through a tunnel while leaving other devices on their normal internet connection. The key is to treat this as a routing and firewall project, not simply an installation: the router must establish the tunnel, assign the right traffic to it, and handle DNS consistently. Because OpenWrt versions, router hardware, and VPN providers differ, package names and interface labels may not match exactly. Use the steps below as a workflow, and check the documentation for your particular firmware and client configuration before changing network settings.
A router-level setup can be useful for devices that do not offer a compatible VPN app, or when you want one policy to cover a group of home devices. It also affects everyone assigned to that policy, so start with one test device rather than moving the entire household at once. Keep a copy of your current configuration and make sure you can still reach the router over a wired LAN connection before you begin.
Plan the Router VPN Before Installing Packages
First identify what you want to protect and how the VPN service supplies connection details. OpenWrt is a Linux-based router operating system, but it does not automatically understand every commercial VPN subscription link or proxy format. A provider may supply WireGuard or OpenVPN configuration files, or it may offer a subscription designed for a separate client. A configuration intended for a desktop app cannot necessarily be pasted into OpenWrt: the router needs a compatible package and correctly formatted credentials and server settings.
Check the router model, available storage, memory, CPU capacity, OpenWrt release, and the VPN client’s requirements. Encryption and packet handling use router resources, and performance depends on the hardware, firmware, connection, and selected protocol. Do not assume a router can sustain the same throughput as a computer, or that a faster advertised internet plan will translate into faster tunneled traffic. If the device is already close to its resource limits, adding a VPN service may make ordinary routing less responsive.
Choose a routing policy before configuring the tunnel. Common approaches include sending all household traffic through the VPN, routing only selected devices through it, or routing only specified destinations through it. The second approach is often the most manageable for a mixed-use home network: a TV or test laptop can use the tunnel, while printers, local media devices, and other household traffic continue to use the regular WAN connection. The exact policy-routing method depends on the OpenWrt release and installed packages.
- ✅ Confirm that the provider offers configuration compatible with a router-side client.
- ✅ Save a router configuration backup and note how to restore it.
- ✅ Decide whether your policy applies to devices, destinations, or the whole network.
- ❌ Do not assume that a node list or subscription URL is directly importable into OpenWrt.
- ❌ Do not remove or replace the normal WAN route before confirming the VPN works.
Choose a Client and a Routing Method
Use the protocol and client combination documented for your router firmware. WireGuard and OpenVPN are common examples of VPN technologies that can be configured on routers, but their availability, setup steps, and provider support are not universal. A client such as sing-box or another proxy-capable program is a different category: it needs compatible packages and configuration, and it should not be treated as a built-in OpenWrt VPN feature. Shadowsocks, VMess, Trojan, and Hysteria2 also require a client that explicitly supports the relevant protocol and configuration format. Check both the provider’s instructions and the client’s own documentation rather than converting credentials by guesswork.
There are two broad ways to decide which traffic uses a tunnel. A whole-router default route sends most eligible traffic through the VPN interface, subject to firewall and routing rules. Policy-based routing instead selects traffic according to rules, such as a device address, source network, or destination. The latter is more flexible, but it adds another layer to troubleshoot. A device may be associated with the correct policy and still fail if the rule is inactive, the tunnel interface is down, or firewall forwarding is missing.
Keep the LAN, WAN, and VPN interface roles clear. The LAN is where household devices connect; WAN is the ordinary upstream connection; the VPN is an additional interface with its own route and firewall treatment. In many setups, LAN traffic must be allowed to forward to the VPN zone, while the VPN interface must be allowed to pass traffic outward. Exact zone names and settings vary. Do not copy a firewall recipe from a different firmware release without checking what each rule permits.
DNS needs a deliberate policy too. If a device’s web traffic uses the VPN but its DNS requests go to a resolver through the normal WAN, the result can reveal a different network path or produce inconsistent location-dependent behavior. Decide whether DNS should follow the VPN policy, use a resolver reachable through that interface, or remain direct for a specific local reason. Preserve local name resolution where needed, and test both public domain lookup and access to local devices after applying changes.
Configure the Tunnel and Test One Device
Work in small, reversible steps. Interface labels differ between LuCI releases and installed packages, so use the names shown by your own router rather than assuming every menu is identical. If you use the command line, review a command before running it and avoid pasting configuration that changes firewall defaults or removes access to the management interface.
- Back up the working router. Export the current configuration from the router’s administration interface and keep a copy somewhere reachable without relying on the router. If possible, confirm you have a wired connection and know the router’s local management address. Record the existing WAN and LAN settings so you can compare them if access is lost.
- Install a compatible client. Use the package source and instructions appropriate to the installed OpenWrt release. Check available storage and dependencies before installation. If the provider gives a configuration file, protect it as you would a password: it may contain private keys, tokens, or server credentials. Do not publish it in a screenshot or paste it into a public support post.
- Create the VPN interface. Add the client configuration using the provider’s required fields, then bring the interface up without changing the household’s default route. Confirm that the client reports a connection and that the router has the expected VPN-side address or route. A connected status alone does not prove that client traffic is being forwarded correctly.
- Set the firewall relationship. Allow only the forwarding needed for the intended policy. Keep the router’s administrative access on the local network, and avoid opening the router’s management service to the public WAN. If the interface fails, make sure the intended fallback behavior is understood: traffic might be blocked, use WAN, or behave differently according to the firewall and policy-routing configuration.
- Apply a narrow routing rule. Assign one test device or a clearly identified test address to the VPN policy. If you use a device address, make it stable through a DHCP reservation or an equivalent method, so the rule does not accidentally move to another device after a lease change. Leave other household devices on their existing route for now.
- Test the result from the device. Check an external IP information page or another trusted diagnostic, then test the real apps and websites you intend to use. Also test a local printer, router administration page, and any household service that should remain reachable. A successful tunnel handshake is only one part of the test; the policy, DNS, and firewall path all matter.
- Expand only after verification. Add more devices or destination rules gradually. After each change, confirm that the intended devices use the intended route and that direct devices still work normally. Keep notes about the rule and interface changes so the configuration can be maintained later.
For general guidance about choosing a cross-border connection service, VPNGF Best VPN for China is the relevant starting point; router compatibility still depends on the configuration format and client you select. A service description should not be read as confirmation that a particular OpenWrt package is supported. Verify the exact protocol, authentication fields, and update procedure before relying on it.
Check DNS, IPv6, and Failure Behavior
DNS problems can look like a failed VPN even when the tunnel is connected. A device might resolve a hostname using a resolver that is unreachable under the selected policy, or it may continue using a previously cached result. Compare behavior with a fresh lookup and with a direct IP connection where appropriate, while remembering that many services depend on hostnames and cannot be fully tested by IP address alone. Check router-level DNS settings and client-level settings; one can override or bypass the other.
IPv6 requires its own attention. Some VPN configurations carry IPv4 traffic but do not provide an IPv6 tunnel. If the home network advertises IPv6, a device may send IPv6 traffic outside the VPN even while its IPv4 traffic follows the tunnel. The correct solution depends on the provider and router design: configure supported IPv6 tunneling, apply an appropriate policy, or disable IPv6 for the affected path only if that is suitable for the network. Afterward, test both address families rather than inferring IPv6 behavior from an IPv4 check.
Decide what should happen when the tunnel disconnects. A fail-closed policy blocks the selected traffic from falling back to WAN, which can reduce unintended direct routing but may interrupt internet access until the tunnel returns. A fail-open policy allows normal WAN access as a fallback, which is convenient but does not keep traffic on the VPN during an outage. Neither choice is universally right; select according to the device’s purpose and make the behavior understandable to other people using the network.
- ✅ Test DNS resolution and ordinary browsing separately.
- ✅ Verify IPv4 and IPv6 behavior when the LAN provides both.
- ✅ Confirm what happens to selected traffic if the VPN interface goes down.
- ✅ Check that local devices remain reachable under the chosen rules.
- ❌ Treat a connected indicator as proof that every packet uses the intended route.
Troubleshooting and Frequently Asked Questions
The tunnel does not connect. What should I check?
Start with the configuration rather than changing several firewall rules at once. Confirm that the server address, port, keys or credentials, and protocol match the provider’s current instructions. Check the router’s system log and the client log for a specific error, then verify that the WAN connection itself works. If the configuration was imported from another client, confirm that it is a format OpenWrt’s installed client accepts. A client can reject a file even when the file works in a different app.
Why does a selected device still use the direct connection?
Check whether the device still has the address used by the routing rule, whether the policy-routing service is active, and whether the rule points to the VPN table or interface that is actually up. Then verify LAN-to-VPN forwarding and DNS behavior. Renewing the device’s network lease or reconnecting Wi-Fi may help after an address or policy change, but it will not correct a missing route or firewall permission.
Why do some apps fail even though websites load?
Different apps can use different protocols, address families, DNS behavior, or destination servers. A browser test does not establish that voice calls, games, streaming apps, or background synchronization use the same path. Check the app’s connection diagnostics where available, test the affected device against the intended policy, and review whether IPv6 or a destination-specific rule bypasses the tunnel. Avoid assuming that a regional node label guarantees access to a particular service.
Should I use a router VPN instead of an app on each device?
A router setup centralizes routing and can cover devices that cannot run a suitable client, but it also makes the router a shared point of configuration and troubleshooting. Per-device apps can provide more precise controls and may be easier to update independently. A mixed approach is possible, but avoid running multiple VPN or proxy clients on the same device without understanding how their routes and DNS settings interact.
OpenWrt can provide flexible, device-aware routing, but flexibility comes with responsibility: you must maintain the client, firewall rules, DNS path, and failure policy. Keep the initial configuration narrow, document changes, and retest after firmware or package updates. If a change cuts off access, restore the saved configuration or use the router’s documented recovery procedure rather than making increasingly broad firewall edits.