An OpenWrt router can send all home traffic through a VPN, but that is not the only option. With policy-based routing, you can select which devices use a tunnel and leave other devices on the normal internet connection. The reliable approach is to establish and verify the VPN connection first, then add device rules, check DNS and firewall behavior, and test what happens when the tunnel is unavailable. OpenWrt versions, installed packages, and VPN providers differ, so treat menu names and configuration fields as version-dependent rather than assuming every router has the same controls.

Understand router VPN routing before you change settings

A VPN client on a laptop or phone normally controls traffic from that device. A VPN client on an OpenWrt router operates at the network gateway, so it can carry traffic from multiple devices on the home LAN. That makes router-level routing useful for devices that cannot run a compatible VPN application, but it also means a mistaken interface, firewall, or DNS change can affect more than one device.

There are two separate decisions. The first is whether the router can establish a tunnel to the provider. The second is which traffic should use that tunnel. A working tunnel does not automatically mean that every LAN device uses it; equally, a routing policy cannot make a tunnel work if its credentials, endpoint, or protocol settings are wrong. Verify these layers independently.

OpenWrt can be configured with different VPN technologies, commonly WireGuard or OpenVPN, when the firmware build, installed packages, and provider configuration support them. WireGuard uses a peer configuration with keys and allowed IP ranges; OpenVPN uses a profile and related authentication or certificate settings. These are not interchangeable formats. A subscription URL intended for a desktop client such as Clash Verge, sing-box, or Shadowrocket is not necessarily a router-ready WireGuard or OpenVPN configuration. Do not paste a subscription link into an unrelated field and expect the router to convert it.

Policy-based routing is also distinct from selecting a VPN protocol. Depending on the OpenWrt release and installed software, a policy-routing package may offer rules by source device, address, network, or destination. Router interfaces and firewall zones determine whether packets can reach the tunnel at all. Read the documentation for the exact OpenWrt release and package version on your router before applying instructions written for a different release.

1

VPN tunnel to verify first

2

Routing layers: tunnel and policy

3

Checks: route, DNS, firewall

Choose a router-compatible configuration

Start by checking the provider’s supported protocols and whether it supplies a configuration suitable for a router. Ask specifically for a WireGuard peer configuration or an OpenVPN profile if that is what the installed OpenWrt client expects. Confirm whether the configuration requires a separate username and password, certificate files, a preshared key, or provider-specific DNS settings. Never assume that a client’s one-click subscription import can be reproduced directly in OpenWrt.

Also check the router’s storage and memory constraints, its CPU capability, and the firmware build’s available packages. Installing additional components consumes space and may require a firmware image that includes the right kernel modules. If you are not sure that the device can support the chosen client, consult its hardware documentation before changing the firmware. Avoid mixing instructions for a third-party firmware build with the stock OpenWrt package feeds.

For a provider that offers app-based subscriptions rather than router configuration files, use its official setup instructions or ask support whether router use is supported. A compatible client can retrieve and interpret a subscription on a supported desktop or mobile platform, but that capability does not establish that OpenWrt understands the same link or rule format. For service details and supported platforms, see VPNRS VPN for China Travel; verify router-specific compatibility before configuring a home gateway.

Prepare OpenWrt and install the client

Before installing packages, record the router model, OpenWrt version, and current network layout. In LuCI, review the system and network pages; in a shell, use the system’s own version and interface information rather than relying on a guide for another device. Confirm that you can reach the router over a local wired connection or a stable local Wi-Fi connection. A wired connection is preferable while changing firewall or LAN settings because a wireless interruption can make recovery harder.

Back up the existing configuration from the OpenWrt administration interface and save a copy away from the router. Note the LAN address, DHCP settings, WAN interface, and any existing VLAN or guest-network configuration. If your network already has custom firewall rules, mesh equipment, a second router, or a separate access point, document how traffic currently flows. This helps distinguish a VPN problem from an existing topology issue.

Use the OpenWrt software interface or the documented package method for your exact release to install the appropriate client and any required interface support. Package names can differ between releases and builds. Avoid copying commands from an unrelated version just because the package name looks familiar. If installing a package requires more free storage than the router has, stop and choose a supported firmware or hardware option instead of deleting unknown system files.

Import or enter the provider’s router-compatible profile using the method documented for the client. Check each field against the supplied configuration: endpoint, port, keys or certificates, authentication details, address assignment, and allowed routes. Keep the configuration’s intended routes intact unless you understand the effect of changing them. For example, a broad route can direct more traffic into the tunnel than intended, while a narrowly scoped route may carry only traffic addressed to a specific network.

Create a dedicated VPN interface or logical network interface where the OpenWrt client expects one. Give it a clear name so that it is easy to identify in the interface and firewall pages. Do not rename or repurpose the existing WAN interface as a shortcut. Save and apply the settings, then check the client status and system log for connection errors. A connected status is useful evidence that a handshake or session exists, but it does not prove that LAN devices are using the tunnel or that DNS follows the intended path.

Set up a firewall zone without weakening the LAN

OpenWrt firewall configuration controls which networks can send traffic to which other networks. The VPN interface generally needs a suitable firewall zone and a forwarding path from the selected LAN traffic to the VPN. The exact LuCI labels and recommended zone layout depend on the client instructions and OpenWrt firewall version. Follow the client’s documented setup rather than copying a generic rule that opens access from the internet to the router.

Do not disable the firewall to make a tunnel test pass. Do not add broad inbound WAN access, expose the router’s administration interface, or create unrestricted forwarding from the VPN zone back to the LAN unless you have a specific, understood requirement. For a basic client-routing setup, the important question is whether selected outbound traffic can be forwarded through the VPN and whether replies return through the appropriate path.

If you use IPv6, decide deliberately whether it should use the VPN, remain on the ordinary WAN, or be disabled for the selected policy. A VPN setup that only handles IPv4 may leave IPv6 traffic on a different route. Do not infer IPv6 protection from a successful IPv4 test. The behavior depends on the tunnel, provider, router configuration, and client policy, so test both address families when they are enabled on the LAN.

Configure device-based routing: a cautious working procedure

Once the tunnel is established and its firewall path is understood, configure policy-based routing using the package or interface recommended for your OpenWrt release. The following sequence is deliberately incremental. Menu labels vary, so look for the documented concepts—source device or address, target interface or policy, and fallback behavior—rather than expecting an identical screen.

  1. Choose one test device. Identify it by a stable DHCP reservation or another source identifier supported by your policy-routing tool. A reservation makes the device easier to recognize, but it does not by itself route the device through the VPN.
  2. Create a policy for that device. Set the policy’s intended route to the VPN interface. If the tool offers a choice between using the VPN, using the WAN, or blocking traffic when the selected route is unavailable, read the descriptions carefully and select the behavior that matches your needs.
  3. Check rule order and scope. A broad LAN rule may take precedence over a device-specific rule, or a destination exception may override the source-device policy. Review the generated policy and confirm that it covers only the intended device and traffic.
  4. Apply the change and test from the device. Reconnect the device to the network or renew its connection if necessary. Verify its public route using a reputable IP-checking method, then test normal browsing and any apps that rely on local-network devices.
  5. Add devices gradually. Once the first device behaves as intended, add another device or a clearly defined group and repeat the checks. Do not make every device part of the policy until you have confirmed that local services, DNS, and the fallback behavior work for your network.

Some policy-routing tools match source IP addresses, while others can use MAC addresses, interface groups, or named policies. These methods have different failure modes. A device using randomized MAC addressing may no longer match a MAC-based rule after changing that setting. A DHCP reservation can keep an IP assignment predictable, but a manual address conflict can still cause unexpected matching. Use one identification method consistently and document it.

Consider how the policy should behave if the VPN interface goes down. A fail-open policy may send the selected device through the ordinary WAN; a fail-closed policy may stop its internet access until the VPN returns. Neither behavior is universally correct. Choose based on the importance of uninterrupted access versus keeping that device off the direct route, and test the behavior intentionally while you still have local access to the router.

If the router hosts both a normal LAN and a guest network, decide explicitly whether either network should use the VPN. A policy attached to the main LAN may not include the guest interface, and a guest network may have isolation rules that prevent access to local devices. Make a separate, documented decision for each network instead of assuming that one policy automatically covers every SSID or VLAN.

Verify DNS, routing, and rollback behavior

Test from the client device, not only from the router itself. Router-originated traffic and forwarded LAN traffic can follow different paths. Use more than one kind of check: confirm the apparent public IP route, try a DNS leak or resolver check, load ordinary sites, and test applications that rely on local discovery or direct connections. A single website result cannot demonstrate that every protocol, address family, and application follows the same route.

DNS deserves a separate check because the device may use the router as its resolver while the router forwards queries to an upstream service. Depending on the DNS configuration, selected traffic may use the VPN while queries use a resolver reached over WAN, or vice versa. Review the router’s DNS forwarding and upstream settings, the policy-routing tool’s DNS options, and any encrypted DNS configuration on the test device. If results are inconsistent, temporarily use a controlled test device and change one setting at a time; avoid changing the entire household’s DNS configuration during diagnosis.

Check local access after enabling the policy. A phone or computer may need to reach a printer, network storage device, casting target, or router administration page through the local LAN even when its internet traffic uses the VPN. These local destinations are not necessarily supposed to go through the tunnel. If local access breaks, inspect route exceptions and firewall forwarding rather than weakening all firewall protections.

When something fails, determine which layer is responsible. If the VPN client reports a connection error, inspect credentials, endpoint reachability, time synchronization, and the client log. If the tunnel is established but the test device still uses WAN, inspect the policy match, rule order, and interface state. If the route is correct but names do not resolve, investigate DNS separately. If only some applications fail, consider IPv6 behavior, app-specific proxy settings, local-network access, or whether that application uses a connection method not covered by the policy.

Make a small change, apply it, and keep a short record of what changed and what test result followed. If LuCI becomes unreachable, try the router’s local address from a device connected directly to the LAN and use the recovery method documented for that router. Restore the saved configuration or revert the most recent firewall and routing change rather than factory-resetting immediately. A reset can remove working internet settings and create a second problem while the original one remains unexplained.

After the test passes, repeat the checks after a router reboot and after the VPN interface reconnects. Confirm that policy rules persist and that the selected device does not silently fall back to WAN unless that is the intended behavior. Keep firmware, packages, and client profiles updated according to their maintainers’ guidance, but make a fresh backup before updates that may change firewall or network behavior.

OpenWrt VPN router FAQ

Not necessarily. Subscription links are often designed for a particular desktop or mobile client, which may parse node formats and policy groups that OpenWrt’s VPN client does not recognize. Check whether your provider supplies a router-compatible WireGuard or OpenVPN configuration and follow the instructions for your installed client. Never assume that renaming a file or pasting a link into a profile field converts one format into another.

Can only selected devices use the VPN?

Usually, this is possible when your OpenWrt release and installed policy-routing software support rules for the device identifiers or source addresses you want to use. Create a narrow policy, test one device, and confirm that other devices remain on their intended route. DHCP reservations, randomized MAC addresses, VLANs, and rule priority can all affect whether the intended device matches the rule.

Why does the client say connected when a device still uses the normal route?

The client’s status describes the tunnel, not necessarily the routing policy for forwarded LAN traffic. The policy may target the wrong interface, fail to match the device, be overridden by another rule, or omit one address family. Check the device’s route, policy status, DNS behavior, and IPv4 and IPv6 results separately.

What happens if the VPN connection stops working?

It depends on the fallback policy. The selected device may move to WAN or lose internet access. Decide which outcome is appropriate before deployment, then test it with one device while keeping a local path to the router. Do not rely on a kill-switch label alone; verify the actual behavior when the tunnel is unavailable and after it reconnects.