OpenWrt VPN Router Setup Guide: Configure Split Tunneling

OpenWrt can turn a compatible router into a central VPN gateway for an entire home network. Instead of installing a separate client on every phone, computer, television, or game console, you can let the router apply routing policies before traffic leaves the local network. The useful part is not simply enabling a tunnel. A well-designed configuration keeps local devices and domestic services on a direct route while sending only selected domains, applications, or destination networks through the VPN.

This arrangement is commonly called split tunneling. It is useful when local access must remain fast and reliable, while selected international services need another route. It can also reduce unnecessary tunnel traffic, simplify device management, and prevent local printers, NAS devices, smart-home controllers, and regional websites from being sent through a remote gateway. The trade-off is that router-level configuration requires careful planning: the tunnel, DNS policy, firewall zones, routing rules, and failover behavior must all agree.

Understand the OpenWrt Split-Tunneling Model

In a typical home network, the OpenWrt router performs several jobs at the same time. Its LAN interface gives devices private addresses, its DHCP service tells clients which gateway and DNS resolver to use, and its firewall controls traffic between zones. The normal default route points toward the internet-facing WAN interface. When you add a VPN client, OpenWrt receives another virtual interface and another possible route. Split tunneling is the policy that decides which packets use the normal WAN path and which packets use the virtual VPN path.

There are several ways to express that policy. Domain-based rules are convenient for services whose destination addresses change frequently. IP-based rules are more predictable for fixed networks, but they require maintenance when address ranges change. Device-based rules are useful when a television, work computer, or guest device should always use a particular route. Port-based rules can help with a specific service, although modern applications may use multiple ports and connection methods, so ports alone are not always sufficient.

OpenWrt installations often use the pbr package, or a similar policy-routing approach, to connect these rules with firewall and routing tables. The exact package name and interface can vary with the OpenWrt release and installed repository, so read the package documentation that matches the firmware currently running on the router. Avoid copying commands from an older release without checking whether the firewall uses the current firewall4 and nftables stack or an older arrangement.

Choose a Tunnel Method

The router needs a client implementation that understands the format of the route you intend to use. WireGuard is often attractive on a router because its configuration is compact and its kernel integration can be efficient. OpenVPN is widely documented and supports many authentication arrangements, but encryption and packet processing may place a heavier load on modest hardware. Shadowsocks, VMess, Trojan, and Hysteria2 are not interchangeable with a standard WireGuard or OpenVPN profile; they require compatible software such as a suitable sing-box-based or other supported OpenWrt client.

A subscription link may contain multiple protocols and route definitions. A generic OpenWrt VPN package may accept only a particular profile format, while a desktop client such as Clash Verge, sing-box, or Shadowrocket may support a broader set of subscription entries. If your provider supplies a subscription rather than a standalone WireGuard or OpenVPN file, first confirm whether the router software can import that subscription directly. Otherwise, use a compatible client to retrieve and manage the supported profiles, or obtain a router-compatible configuration from the service.

• ✅ Confirm that the router client supports the protocol used by the selected route.
• ✅ Keep a copy of the original WAN and LAN settings before changing policy routing.
• ✅ Decide whether rules should match devices, domains, IP ranges, or a combination.
• ✅ Keep local services on the direct route unless there is a clear reason to proxy them.
• ❌ Do not assume that a subscription URL can be pasted into every OpenWrt VPN package.
• ❌ Do not install several routing managers that attempt to control the same firewall tables.

Prepare the Router Before Applying Rules

Use a wired connection to the router whenever possible. If a policy change interrupts Wi-Fi or restarts networking, a wired session makes recovery much easier. Record the router’s LAN address, the management address, the current WAN type, and the DHCP range. Export a backup from the OpenWrt administration interface and save it somewhere that is not dependent on the router itself. Also note the names of existing interfaces and firewall zones so that a new VPN interface does not accidentally replace the wrong object.

Check available storage and memory before installing additional packages. A router that already has very little free space may fail halfway through a package installation, leaving an incomplete service definition. Keep the firmware release and package feeds aligned; installing packages from a different release can create dependency or firewall compatibility problems. If the router vendor provides a supported hardware acceleration option, review it before enabling heavy encryption, but do not enable options that you cannot explain or test.

Set a clear naming convention for interfaces and policies. For example, a tunnel interface can have a name that identifies the protocol, while policies can describe their purpose, such as “selected domains through VPN” or “living-room device direct.” Descriptive names matter later when the router has several interfaces, because choosing the wrong firewall zone can make a working tunnel appear broken.

Install and Check the Client

Install only the components required for the chosen tunnel and policy manager. After installation, verify that the client creates the expected virtual interface and that the service starts without repeated errors. Check the system log for authentication failures, certificate problems, missing kernel modules, DNS startup errors, or a tunnel that connects and immediately closes. A green status indicator is useful, but the interface state and log entries provide more reliable evidence.

Import a router-compatible profile or subscription through the client’s documented method. Protect the subscription link as you would protect an account credential: do not place it in a public issue, share it in a screenshot, or submit it to an unknown conversion website. If the client exposes a refresh function, use that function when the provider changes route information instead of editing generated configuration files by hand.

Configure the VPN and Split-Tunnel Policies

Begin with the tunnel itself, not the domain list. Configure the remote endpoint, authentication material, DNS behavior, and keepalive options required by the selected protocol. For WireGuard, this usually means a private key, peer public key, allowed addresses, endpoint, and optional keepalive. For OpenVPN, it may include certificates, an authentication method, and transport settings. For sing-box-based protocols, the profile must preserve the correct transport, server identity, and security parameters. Never replace certificate or security fields with values copied from a different route.

After the tunnel connects, place its interface in the appropriate firewall zone. The zone should allow forwarding from the intended LAN clients to the tunnel while preventing unsolicited inbound access from the tunnel toward the LAN. Masquerading may be required when the remote side expects traffic to arrive from the router’s tunnel address. The exact firewall settings depend on the client implementation, so use the package’s guidance rather than blindly duplicating a WAN zone.

Next create the policy order. A practical order is to preserve local destinations first, define direct exceptions second, and send selected traffic through the VPN afterward. Some policy managers use a first-match model, while others compile multiple rules into nftables sets and routing tables. Read the matching behavior carefully. A broad “all destinations through VPN” policy placed above a local-network exception can make printers, router administration, and local media servers unreachable.

Handle DNS as Part of the Policy

DNS is one of the most common reasons a split-tunnel configuration behaves inconsistently. A domain rule can select the VPN route for the eventual connection while the initial DNS query still goes to the resolver supplied by the WAN. That may expose the query to a different network path, return a regional answer, or produce an address that does not match the policy’s expectations.

Choose a DNS design deliberately. The router can provide a local resolver that forwards requests according to domain rules, or selected clients can use a resolver associated with the VPN path. If encrypted DNS is enabled inside a browser or application, that application may bypass the router’s ordinary DNS policy. Browser secure DNS, hard-coded application resolvers, and cached records must therefore be included in testing.

Be cautious with domain rules that cover only one hostname. Modern services often use several related domains for authentication, static resources, APIs, telemetry, downloads, or content delivery. Sending the first page through the tunnel may not be enough if subsequent requests go direct. At the same time, adding an entire large domain family without understanding its purpose can route far more traffic than intended. Start narrowly, observe logs, and expand only when a legitimate dependency is identified.

Apply the Configuration and Verify It

Apply changes in small groups rather than changing the tunnel, firewall, DNS, and every policy at once. First verify that ordinary LAN access remains available. Then test the tunnel with one controlled client. Finally add the selected domain or device rule and compare the result with the direct baseline. This sequence gives each change a clear cause and makes rollback practical.

1. Connect a test device to the normal LAN and confirm that it can reach the router, local devices, and ordinary websites.
2. Enable the VPN client without applying a broad client policy, then confirm that the virtual interface receives the expected state and that the router log shows a stable session.
3. Check the public exit address from the test device using the site’s network test page. Compare the result with the disconnected baseline, and do not rely only on a country label.
4. Resolve a domain that should remain direct and another domain that should follow the VPN policy. Check whether the resolver and returned address are consistent with your design.
5. Apply the selected policy to one device or a narrow domain set. Test a real request in the relevant browser or application rather than testing only with a ping.
6. Confirm local services again, including router administration, printers, storage devices, and casting or discovery functions that your household uses.
7. Reconnect the test device, renew its DHCP lease if necessary, and repeat the checks after a router restart so that the configuration is tested beyond the current runtime state.

For a device-based policy, compare the exit address from two clients on the same LAN: one assigned to the VPN policy and one left direct. For a domain-based policy, inspect the client’s connection log and browser developer network panel if available. A successful page load alone is not conclusive because some resources may be cached. Use a fresh session, reload the page, and check several related requests.

• ✅ Test direct access, VPN access, DNS behavior, and local resources separately.
• ✅ Verify the rule on more than one network request from the actual application.
• ✅ Check both IPv4 and IPv6 behavior if IPv6 is enabled on the WAN and LAN.
• ✅ Keep a written note of the policy order and the expected path for each test device.
• ❌ Do not use an old browser tab as proof that a new route is active.
• ❌ Do not forget IPv6: a domain may bypass an IPv4-only tunnel through a direct IPv6 route.

IPv6 deserves special attention. If the VPN client handles only IPv4 but the home network advertises IPv6 connectivity, some applications may prefer IPv6 and bypass the intended policy. You can either configure an IPv6-capable tunnel and policy or make an informed decision about IPv6 handling on the LAN. The correct choice depends on your provider, router software, and network requirements; hiding the symptom without testing both address families can create an inconsistent result.

Improve Performance and Reliability

Router performance depends on encryption method, packet size, connection count, firmware support, and the hardware available for packet processing. If only selected traffic uses the tunnel, begin with a narrow policy and observe the router’s load during real use. Do not route every device merely because the tunnel is available. A smaller policy reduces processing work and makes it easier to identify which application is responsible for increased traffic.

Watch for MTU and fragmentation problems. A tunnel adds packet overhead, and some paths cannot carry the original packet size without fragmentation. Symptoms can include a page that starts loading but stalls, downloads that repeatedly restart, or certain sites working while others fail. Adjust the tunnel’s MTU only after testing, and document the original value so that you can revert the change. Avoid changing several transport parameters at the same time because that removes the ability to identify the useful adjustment.

Keep the subscription and route list current through the supported client workflow. If a route stops working, refresh the configuration and test another compatible route before rewriting firewall rules. A route-specific failure is different from a policy failure. Separating those possibilities prevents unnecessary changes to the LAN configuration.

Reliability also depends on the failure policy. Decide what should happen when the VPN is unavailable. A fail-open policy sends selected traffic directly when the tunnel fails, which preserves access but may not meet privacy expectations. A fail-closed policy blocks matching traffic until the tunnel returns, which is stricter but can look like an application outage. The choice should be explicit, especially for devices that automatically retry connections in the background.

Recover from a Failed Configuration

The safest recovery method is to change only the most recent policy or interface setting first. Disable the newest rule, restart the affected service, and test local access. If the problem remains, stop the VPN client and restore the previous firewall or network configuration from the backup. Rebooting repeatedly without reverting the cause can make troubleshooting harder because cached routes and temporary states disappear without explaining why the configuration failed.

If the router becomes unreachable, use a wired connection and try the known LAN management address. Check whether the client received a different address from DHCP. If the web interface is unavailable but SSH access remains available, use the documented OpenWrt recovery procedure and remove or disable the most recent policy configuration. Keep an offline copy of the backup and the exact package versions used. When ordinary recovery is not possible, consult the firmware’s failsafe instructions before performing a reset; a reset removes local settings and should be treated as a last resort.

Common causes include a policy that captures the router’s own DNS traffic, a tunnel interface assigned to the wrong firewall zone, overlapping default routes, a subscription profile unsupported by the installed client, and IPv6 traffic escaping an IPv4-only design. Another frequent cause is an incorrect DNS rule: the connection may use the intended tunnel while the name resolution still follows the WAN resolver. Investigate each layer separately instead of assuming that every failure is a server or route problem.

OpenWrt VPN Router FAQ

OpenWrt split tunneling works best when it is treated as a layered network design rather than a single switch. Confirm protocol compatibility, build the tunnel separately, protect local administration, align DNS with routing, and verify real requests from the devices that matter. With a documented backup and a deliberate failure policy, the router can provide flexible household routing without turning every local connection into a troubleshooting exercise.