OpenWrt VPN Router Setup Guide for Whole-Home Traffic Rules

Plan the router design before changing settings

An OpenWrt router can send selected home-network traffic through a VPN while leaving other traffic on the normal internet connection. The router, rather than each phone or computer, establishes the tunnel. You can then make routing decisions based on a device’s address, a destination, or another rule supported by your configuration. This can simplify management across a household, but it also means a router-level mistake may affect several devices at once.

Start by deciding what you want the rules to do. A simple arrangement sends every device through the VPN. A selective arrangement sends only chosen devices through it, or sends particular destinations through it while keeping the rest direct. Write down the intended behavior before installing packages: which devices should use the tunnel, which should remain direct, and what should happen if the tunnel disconnects. A clear plan makes it easier to test and to undo a rule that has an unexpected effect.

OpenWrt installations and package availability vary by release, device architecture, and enabled software feeds. Check your router model, current OpenWrt release, available storage, and the package documentation for that release before proceeding. Some routers have limited flash or memory, and installing packages that do not match the device or release can cause problems. Keep a wired computer available if possible; troubleshooting a broken wireless configuration over the connection you are changing is needlessly difficult.

Also confirm that your VPN provider supplies a configuration format your router can use. OpenWrt can be configured for protocols such as WireGuard or OpenVPN when the appropriate packages and compatible profile are available. A subscription URL intended for a particular desktop or mobile client is not automatically a router configuration file. Do not paste a subscription link into an arbitrary LuCI field: first verify the provider’s documented router setup method, supported protocol, authentication requirements, and any certificate or key files.

The platform figure describes VPN61 client availability, not router compatibility. Router use depends on obtaining a configuration that OpenWrt supports and setting it up correctly. Likewise, having a VPN connected does not by itself confirm that every device, DNS request, or IPv6 connection is using the intended path.

Prepare OpenWrt and the VPN profile

Before making changes, record how to reach the router’s administration interface and save a configuration backup. In LuCI, use the backup or archive option under the system settings; from a shell, OpenWrt commonly provides a backup command such as sysupgrade -b /tmp/openwrt-backup.tar.gz. Check the command and backup procedure for your installed release, and copy the resulting file off the router. A backup stored only in temporary router storage may be lost after a reboot or reset.

Review the current network configuration as well. Note the LAN address range, DHCP settings, wireless network names, firewall zones, and any existing VLANs or access-point arrangements. If you have already configured custom DNS, a guest network, or port forwarding, record those settings too. The VPN should be introduced as a separate interface and firewall path where possible, rather than by replacing unrelated LAN settings.

Choose a compatible tunnel

For WireGuard, the router needs the appropriate kernel support and user-space tools, plus a peer configuration containing the required keys, endpoint, allowed IP ranges, and any provider-specified keepalive or DNS details. For OpenVPN, it needs the matching client package and the provider’s configuration, certificates, and credentials if required. Package names and installation methods can differ between OpenWrt releases; follow the official OpenWrt instructions for your release instead of copying package commands from an unrelated guide.

Do not assume that protocol labels are interchangeable. Shadowsocks, VMess, Trojan, and Hysteria2 are proxy protocols or transports, not drop-in replacements for a WireGuard or OpenVPN tunnel interface. They may require a compatible client application or service and a separate routing design. If the provider only supplies a profile for a third-party desktop client, ask whether it offers a supported router-compatible configuration before trying to convert it.

Create and test the tunnel interface

Install only the packages required by the chosen protocol and routing approach. Add the tunnel as a named network interface in LuCI or the supported configuration files, then associate it with a suitable firewall zone. The exact options depend on the protocol and profile. Avoid copying private keys, account credentials, or full configuration files into public forums or screenshots.

Bring up the tunnel before adding policy rules. Check the interface status, handshake or connection state, and router reachability. From a client on the LAN, confirm that basic browsing still works and compare the visible egress address with the expected route. A browser-based IP check can confirm the browser’s path, but it does not prove that DNS, every application, IPv6, or every device uses the same path.

Add device and destination rules

OpenWrt’s policy-based routing tools can direct selected traffic through a chosen interface, provided the tunnel and firewall are configured correctly. The pbr package and its LuCI interface are commonly used for this purpose, but verify package support and configuration syntax for your OpenWrt release. Policy-based routing is different from multi-WAN failover: a policy selects a path for matching traffic, while a multi-WAN tool is generally concerned with selecting or failing over between internet connections.

For device-based rules, give the relevant device a stable LAN address, usually by creating a DHCP reservation. Then create a policy that matches that source address and selects the VPN interface. A reserved address makes the rule easier to understand and prevents it from silently applying to a different device after lease changes. For destination-based rules, match the domain or address only if the routing tool supports that type of match and the rule is maintained correctly as destination addresses change.

Consider what should happen when the tunnel is unavailable. A strict policy or kill-switch behavior may prevent matching traffic from falling back to the regular WAN. That can reduce accidental direct connections, but it also means the affected device may appear offline whenever the tunnel fails. A permissive policy may allow direct fallback, which improves continuity but changes the privacy and routing behavior you intended. Choose deliberately, and test the failure case rather than assuming the setting does what its label suggests.

When you are also comparing a provider for travel use, the VPN61 VPN for China Travel overview is a separate starting point; for router use, verify that the configuration format and protocol you need are actually available.

• ✅ Reserve a stable LAN address before making a device-specific policy.
• ✅ Use a rule for a specific device or destination when only part of the network needs the tunnel.
• ✅ Decide whether a tunnel failure should block matching traffic or allow a direct fallback.
• ❌ Do not assume that a device rule also covers every other device or all router-originated traffic.
• ❌ Do not treat a domain match as permanent if the destination uses changing addresses or the rule tool cannot resolve it reliably.

Apply one rule at a time and test from the device it is meant to affect. Keep a second device on the ordinary route for comparison. If you use a guest network, VLAN, or separate IoT network, confirm whether the routing policy and firewall zone include that network; a LAN rule may not automatically cover traffic from every network segment.

Check DNS, IPv6, and the real traffic path

DNS can follow a different path from the application traffic it helps direct. A router may send client DNS requests to its local resolver, while that resolver forwards queries using an upstream server that does not follow the VPN route. Alternatively, a device may use a manually configured DNS service or encrypted DNS setting that bypasses the router’s expected policy. Decide which resolver should handle client queries, configure it consistently, and verify the behavior from a client rather than relying only on the router’s interface status.

Do not solve a DNS mismatch by indiscriminately blocking DNS traffic. First identify whether clients query the router, a public resolver, or an encrypted DNS endpoint, and determine which requests are covered by the routing policy. If the provider supplies DNS settings for its profile, check whether those settings are intended for the router, the tunnel interface, or individual clients. Keep in mind that a DNS result can be cached, so a test immediately after changing resolver settings may not reflect the new path.

IPv6 needs its own review. If the VPN profile and policy do not carry IPv6, a client with working IPv6 connectivity might still reach destinations directly over the normal WAN even when its IPv4 traffic uses the tunnel. Decide whether your setup supports IPv6 through the VPN. If it does, configure and test that path. If it does not, use a deliberate IPv6 strategy supported by your network design rather than assuming that an IPv4 policy protects both address families.

Test the router and clients separately. From a client, check a public IP address, resolve a domain, open a site, and try a representative application. Repeat the checks from a device intended to remain direct. If you have a terminal, compare the route and DNS behavior there with the browser, since applications can use different proxy or DNS settings. Testing a single website is not enough to establish that every destination follows the same rule.

For a useful test record, note the client’s reserved address, the policy that should match, the selected interface, the visible egress, and whether IPv6 is enabled. Test both normal operation and the behavior after temporarily disabling the tunnel. If you cannot reach the router after applying a rule, use the wired recovery connection and restore the last known-good configuration rather than adding several more changes at once.

Rollback, troubleshooting, and FAQ

If a rule interrupts normal connectivity, start with the smallest reversible change. Disable the most recently added policy, confirm whether the device can reach the router and WAN, and inspect the tunnel and firewall status. If LuCI is unavailable over Wi-Fi, connect over Ethernet and use the documented recovery method for your router. Restore the backup if the network configuration has become difficult to diagnose. After recovery, reintroduce the tunnel first, then its firewall association, then one policy at a time.

Common symptoms point to different causes. A connected tunnel with no browsing may indicate a missing route, firewall forwarding problem, DNS issue, or incompatible profile. A browser showing the direct egress while the router reports a tunnel may mean the client traffic does not match the policy, IPv6 is taking another path, or the browser uses its own proxy or encrypted DNS. A single device losing connectivity may have a changed address or a rule that matches the wrong source. Check the corresponding layer instead of repeatedly reinstalling packages.

• ✅ Keep a copy of the last known-good configuration off the router.
• ✅ Use a wired connection for recovery when changing LAN, wireless, or routing settings.
• ✅ Review logs and interface status before changing firewall or DNS settings.
• ❌ Avoid changing tunnel, DNS, firewall, and DHCP settings simultaneously; it makes the cause harder to isolate.

Frequently asked questions

Can I import any VPN subscription link into OpenWrt?
No. A subscription link may be intended for a specific client and may not contain a profile that OpenWrt can use directly. Check for a documented router-compatible configuration and supported protocol before importing anything.

Does a router-level VPN automatically cover every device?
Not necessarily. Coverage depends on the default route, policy rules, network segments, DNS behavior, IPv6 configuration, and any device-level proxy settings. Verify each intended device and each route separately.

Should I route all home traffic through the tunnel?
That depends on your use case. A default tunnel is simpler to reason about but may affect local services and destinations that should remain direct. Selective routing gives more control but requires clear rules and ongoing checks. Choose the design that matches your household’s needs and test it before relying on it.

What is the safest way to undo a failed change?
Disable the last policy or restore the saved configuration using the router’s documented recovery procedure. Keep LAN access available during setup, and avoid making several unrelated changes before confirming the previous step works.