OpenWrt Split Tunneling Guide: Route Traffic with Rules

OpenWrt split tunneling is a policy problem, not simply a switch that makes “some traffic use the VPN.” A router must first identify traffic by source device, destination address, domain name, or port, then send the matching flows to the VPN interface while leaving everything else on the normal WAN path. When those decisions are made clearly, local printers, NAS services, banking sites, games, and ordinary browsing can follow different routes without requiring every device to run its own client.

The cleanest design is to separate the work into four layers: establish a reliable VPN interface, define the traffic that should use it, make DNS follow the same decision, and test both the selected and excluded paths. OpenWrt can use WireGuard or OpenVPN directly, while compatible packages and clients can handle protocols such as Shadowsocks, VMess, Trojan, VLESS, Hysteria2, or sing-box-based profiles. Compatibility depends on the installed package, core version, firmware architecture, and configuration format; importing a subscription into a desktop or mobile client does not automatically make the same link usable by the router.

Choose a routing model before writing rules

There are three practical ways to structure split tunneling on OpenWrt. Device-based routing sends all traffic from selected clients through the VPN. Destination-based routing sends traffic for selected websites, IP ranges, or services through the VPN regardless of which device requests it. A combined policy uses both conditions, such as sending one streaming device through the VPN only when it accesses a defined set of destinations.

Device-based routing is usually the easiest place to begin because it avoids the changing IP addresses associated with domain names. Give the chosen device a stable DHCP lease, identify it by its reserved address or MAC address, and attach that source to the VPN interface. The rule remains understandable: “this client uses the VPN; other clients use WAN.” It is useful for a television, test laptop, or a separate guest device that should have a different default path.

Destination-based routing is more flexible but requires more maintenance. A service may use several domains, redirect to regional endpoints, resolve to different addresses over time, or rely on a content delivery network shared by unrelated services. A single IP address copied from a DNS lookup is rarely a durable website rule. Domain-aware policy routing is preferable when available, but it must be paired with a DNS service that can place the resolved addresses into the routing mechanism used by the firewall.

Policy-based routing packages such as pbr are commonly used with modern OpenWrt firewall stacks. They provide a LuCI interface and UCI configuration for choosing an interface, source address, destination address, or domain. The exact menu names and supported options vary with the OpenWrt release and package version, so treat interface labels and policy fields shown by your router as authoritative. Avoid copying an old configuration designed for a different firewall generation without checking whether it uses firewall4 and nftables or an older firewall3 and iptables setup.

Prepare the VPN interface and firewall zone

Split tunneling cannot work reliably until the VPN itself works as a normal OpenWrt interface. For WireGuard, obtain the private key, peer public key, endpoint, allowed IPs, and keepalive value from the configuration source. For OpenVPN, import the provider profile and confirm the certificate, authentication, and transport settings. If the configuration comes from a subscription service, use its router-compatible profile or generate a configuration specifically for OpenWrt rather than pasting a mobile-only link into LuCI.

Create a separate logical interface for the tunnel and place it in a dedicated firewall zone. The zone normally needs forwarding from the LAN or the relevant VLAN toward the VPN interface, plus the appropriate masquerading or source NAT behavior. The VPN peer must also have a route back to the client subnet. A tunnel that shows “up” but lacks forwarding, DNS access, or a return route may appear connected while applications still fail.

WireGuard’s AllowedIPs deserves special attention. A full-tunnel peer commonly uses a broad route such as 0.0.0.0/0, and IPv6 may require a separate decision. A policy-routing package may install or suppress these routes depending on its configuration. If you want only selected traffic to use the tunnel, do not assume that changing AllowedIPs alone creates application-level split tunneling. It controls which destinations are considered reachable through the peer; the firewall still needs to classify client traffic correctly.

OpenVPN profiles can behave differently because they may push routes, DNS settings, or redirect-gateway instructions from the server. Review imported options before enabling them. A server-pushed default route can override the intended direct path, while a missing route can cause the VPN-selected client to connect without reaching the destination. When using sing-box or another third-party core on OpenWrt, make sure the transparent proxy mode, TUN device, DNS listener, and firewall integration are all supported by the package version. A proxy process listening on the router is not automatically a transparent gateway for LAN clients.

• ✅ Reserve a stable LAN address for every device used in a policy.
• ✅ Give the VPN its own logical interface and firewall zone.
• ✅ Verify that the tunnel can reach an external destination before adding split rules.
• ✅ Decide whether IPv4 and IPv6 should use the same policy.
• ❌ Do not put the router’s management interface or local services behind a broad proxy rule without a recovery path.
• ❌ Do not run multiple transparent proxy clients that compete for the same DNS port or firewall hooks.

Configure rules in LuCI and with UCI

After installing and enabling a policy-routing package, open its LuCI page and select the VPN interface as the target. The interface must be up when the policy service starts, and the service should be configured to wait for network readiness if the tunnel is established after boot. If the package offers strict enforcement, understand its effect before enabling it: strict mode may block matching traffic when the VPN is unavailable instead of allowing that traffic to fall back to WAN.

A device-based rule can be described as follows: reserve 192.168.1.50 for a test laptop, select that address as the source, and choose the VPN interface as the policy target. Other LAN clients remain on WAN. This is a useful first test because it has a clear expected result. If the laptop cannot connect, inspect the interface and firewall. If the laptop connects but another client also uses the tunnel, look for a default route or a broader policy that is taking precedence.

A destination policy can use a domain list such as service.example and cdn.example, with the VPN interface as the target. Include all domains required by the application, not just the hostname visible in the browser. Authentication, images, APIs, telemetry, and media delivery may use separate names. Keep the list readable and document why each entry exists. A large, unstructured list becomes difficult to audit when a service changes its endpoints.

# Illustrative policy values; adapt them to the LuCI fields
source client: 192.168.1.50
destination domains: service.example, cdn.example
target interface: vpn
fallback: WAN when enforcement is disabled

# UCI-style concepts
config policy
    option name 'test-client-to-vpn'
    option src_addr '192.168.1.50'
    option dest_addr 'service.example cdn.example'
    option interface 'vpn'

The example is intentionally schematic. Option names, list syntax, and domain support can differ between package releases. Use uci show to inspect the configuration generated by LuCI, then use the package documentation for the installed version. Applying a guessed command copied from an unrelated firmware image can create a policy that looks saved but is never loaded by the active service.

Policy order also matters. A narrow exception should not be hidden below a broad rule that catches the same traffic first. Keep the rule set in a logical order: protect router and LAN destinations, define direct exceptions, define VPN destinations, and then decide whether any default policy should apply. After saving changes, restart the policy service if LuCI does not do so automatically. Watch the system log for nftables errors, missing interfaces, unresolved domains, or failed route installation.

Use VLAN boundaries when the policy is large

When many devices need the same route, a separate VLAN or guest network can be easier to manage than a long list of individual addresses. Put the relevant clients in that network, assign it a dedicated firewall zone, and send the zone through the VPN policy. Keep the management network separate so that a bad tunnel configuration does not remove access to LuCI or SSH. Inter-VLAN access should be allowed only for the local services that genuinely need it, such as a printer or media server.

This approach also makes rollback clearer. Moving a client back to the ordinary LAN removes it from the VPN policy without editing several firewall objects. It is not necessary for a small home network, but it becomes valuable when phones, televisions, work devices, and guest equipment need different handling.

Make DNS follow the policy

DNS is one of the most common reasons a seemingly correct split tunnel behaves inconsistently. A client may ask the router for a domain, receive an address associated with one route, and then connect through another. Alternatively, a browser may use encrypted DNS directly, bypassing the router’s domain rules. The result can be a page that partly loads, a service that changes region unexpectedly, or a rule that works only for an address already present in cache.

Use the router’s DNS forwarding design deliberately. If domain-based policies depend on dnsmasq or another resolver integration, make sure LAN clients actually use the router as their DNS server. Decide whether selected domains should be resolved through the VPN-facing resolver, the normal WAN resolver, or a local encrypted resolver. The correct choice depends on the destination and on the privacy and availability requirements of the network; there is no universal DNS setting that fixes every route.

Check for DNS leaks at two levels. First, inspect the router’s resolver configuration and query logs when testing a known domain. Second, inspect the client itself for browser DNS-over-HTTPS, private DNS, or an application-specific resolver. A phone can bypass router policy even when the router’s configuration is correct. Disable or account for those client features during testing, then re-enable them one at a time to see whether the intended policy still works.

Local names require extra care. Hostnames used for printers, NAS devices, and router services should resolve locally and should not be sent to a remote VPN resolver. Keep local DNS zones and DHCP behavior intact, and avoid forwarding private address ranges through an external tunnel. If a local service stops working after enabling the VPN, test it by local IP and by local hostname; the difference will show whether the problem is routing or name resolution.

Test selected and direct traffic separately

Test from a client that is definitely included in the policy and from another client that is definitely excluded. Use the same destination, then compare a local service, an ordinary website, and the service intended for the VPN. The purpose is not to collect a dramatic speed number; it is to confirm that the policy decision is repeatable and that unrelated traffic remains usable.

1. Confirm the client has the reserved address and received the expected DNS server from DHCP.
2. Check that the VPN interface is up and that the router has the intended routes and firewall forwarding.
3. Open the selected domain from the included client and inspect the VPN interface counters or connection log.
4. Repeat the request from an excluded client and verify that its traffic uses WAN.
5. Access a printer, NAS service, or router page by local hostname and local address.
6. Restart the VPN interface, renew the client lease, and repeat the tests after a network change.

On OpenWrt, useful evidence includes ip route, ip rule, nft list ruleset, interface byte counters, and the system log. A route table can show whether a destination is reachable through VPN, but it does not by itself prove that the firewall marked the client’s packet correctly. Packet counters on the relevant nftables chain and interface counters provide stronger evidence. For a connection that fails only by domain, compare its IP-based behavior with its hostname behavior to isolate DNS and domain-set issues.

If the selected client has no connectivity, check the return path and NAT before changing domain rules. If selected traffic works but excluded traffic also uses the VPN, look for a full-tunnel default route, an overly broad source policy, or a proxy mode that captures all LAN traffic. If only some pages load, expand the domain set carefully and check IPv6. If local services fail, inspect firewall forwarding between LAN zones and confirm that private addresses are not being redirected into the tunnel.

Plan rollback before changing the network

Router routing changes can lock you out, especially when a broad default route, DNS redirect, or firewall zone is applied incorrectly. Make changes from a wired device when possible, keep a second management path available, and export the OpenWrt configuration before editing. Record the original WAN, LAN, DHCP, DNS, firewall, and VPN settings separately so that you can restore one layer without deleting the others.

For a controlled rollback, first disable the policy-routing service, then stop the VPN interface, remove or disable its firewall forwarding, and restore the normal WAN default route. Renew the affected client’s DHCP lease and clear its DNS cache. If LuCI is unavailable but SSH still works, use the package’s service controls and inspect the UCI configuration rather than deleting random firewall files. Rebooting may restore a previous runtime state only if the persistent configuration was not already changed, so do not rely on a reboot as the primary recovery method.

Maintenance is part of split tunneling. Review domain lists when an application changes its endpoints, verify rules after OpenWrt or package upgrades, and check whether a new firmware version changed firewall syntax or DNS behavior. Keep protocol credentials private, especially WireGuard private keys and subscription URLs. If a subscription must be imported into a compatible router client, refresh it through the client’s supported mechanism instead of exposing the link in screenshots or public configuration files.

• ✅ Export a known-good configuration before enabling a new VPN policy.
• ✅ Keep router management and local recovery access outside the experimental rule.
• ✅ Document each policy’s source, destination, target interface, and fallback behavior.
• ✅ Re-test after firmware, package, DNS, or VPN profile changes.
• ❌ Do not leave strict enforcement enabled until the tunnel has passed failure and recovery tests.
• ❌ Do not assume a working browser session proves that every application follows the same route.

For a home network, the most maintainable arrangement is usually a reserved-address rule for a small set of devices, a carefully documented domain list for special destinations, local DNS kept local, and a separate management path that never depends on the tunnel. OpenWrt gives you enough control to build more advanced policies, including VLAN-based routing and protocol-specific proxy integrations, but every additional layer increases the need for logs, clear naming, and a rollback plan.