OpenWrt VPN Split Tunneling Setup Guide for Home Routers

Running a VPN directly on an OpenWrt router can make network management much easier: phones, computers, televisions, game consoles, and other home devices can follow one central routing policy instead of being configured individually. The important part is not simply enabling a tunnel. A useful home-router setup must decide which traffic uses the tunnel, which traffic stays on the local connection, how DNS follows the same decision, and how to recover when a node or upstream network becomes unavailable.

OpenWrt split tunneling is therefore best understood as policy routing rather than a single switch. You can route selected devices through a VPN, send selected domains through a proxy, bypass local services, or combine these methods. The exact menu names depend on the OpenWrt release and the client package you install, but the underlying design remains similar. This guide focuses on a maintainable arrangement that works with router-side WireGuard, sing-box or Xray-based clients, and compatible subscriptions that contain protocols such as Shadowsocks, VMess, Trojan, or Hysteria2.

Understand the split-tunneling model

A home router normally receives traffic from the LAN, applies its routing table, performs DNS forwarding, and sends packets to the internet through the WAN connection. When a VPN client is added, it creates another outbound path. Depending on the implementation, that path may be a WireGuard interface, a TUN interface managed by sing-box or Xray, or a local proxy service that the router redirects transparently.

Split tunneling means that the router chooses between these paths according to rules. A simple policy might send one television through the VPN while leaving every other device on the normal WAN route. A domain-based policy might send selected international services through the tunnel but keep local banking, local video services, and router administration on the direct path. A combined policy can give priority to device rules and then apply domain rules to traffic that is not already matched.

These two routing models should not be confused:

• ✅ Device-based routing: useful when a complete device, such as a TV or work computer, should consistently use one path.
• ✅ Domain-based routing: useful when only particular services should use the tunnel while the same device still needs local websites and local network resources.
• ✅ Direct bypass rules: useful for router management, printers, NAS devices, local discovery, and services that reject an unexpected exit region.
• ❌ Do not assume a proxy rule covers every application: some applications use hard-coded addresses, QUIC, certificate pinning, or their own DNS resolver.

Also separate the protocol from the client. WireGuard is a VPN protocol that normally creates a routed interface. Shadowsocks is a proxy protocol, while VMess, Trojan, and Hysteria2 are commonly consumed through Xray or sing-box compatible clients. A subscription link does not automatically become a native OpenWrt VPN profile. The router needs a compatible package or gateway client that can parse the subscription and expose a transparent routing interface.

Choose a router topology and client

Before changing firewall rules, confirm how your home network is arranged. OpenWrt may be the primary router, an access point behind another router, or a secondary gateway for selected devices. Split tunneling is most predictable when OpenWrt is the device providing DHCP, DNS, and the default gateway. If another router still provides DHCP, client traffic may bypass OpenWrt even when the OpenWrt interface appears connected.

Primary-router mode

In primary-router mode, all LAN devices use the OpenWrt address as their gateway. The router can identify clients by source IP or MAC mapping, forward their DNS requests, and apply firewall or policy-routing rules consistently. Reserve stable DHCP leases for devices that need special treatment. A stable address makes a rule easier to audit than a rule tied to a changing address.

Secondary-gateway mode

In secondary-gateway mode, connect a separate VLAN, LAN segment, or selected device group to OpenWrt. This is often safer when the existing router must remain unchanged. The devices placed behind OpenWrt use the tunnel policy, while the remaining household devices continue using the original gateway. The trade-off is that local discovery can become less convenient if the two networks are separated.

For the client itself, use the least complicated option that meets your routing requirement:

Hardware capacity also matters. Encryption, TUN capture, DNS filtering, and rule-set matching consume CPU and memory. A router that works well as a basic access point may become unstable when it handles many concurrent connections. Check available memory, storage, thermal conditions, and connection tracking before enabling a large rule set. Do not interpret a router CPU limitation as a problem with the remote line.

Configure OpenWrt split tunneling step by step

The following workflow is deliberately staged. Make one change, test it, and record the result before moving to the next stage. Keep a local backup of the OpenWrt configuration and ensure that you can reach LuCI or SSH through the LAN if a rule causes an outage.

Prepare LAN identities

Start by creating DHCP reservations for devices that need a fixed policy. Give each device a descriptive name in LuCI, such as living-room-tv or work-laptop. Avoid using a broad subnet rule until the basic tunnel has been verified. A broad rule can unintentionally capture printers, router administration, local file shares, and smart-home controllers.

Next, confirm the gateway and DNS values distributed by DHCP. A client should normally list the OpenWrt router as its DNS server if the router is expected to classify domains. If a device is manually configured with an external DNS address, its queries may bypass the router and domain rules may appear to fail even though the tunnel is working.

Import and test the tunnel

For WireGuard, add the peer configuration supplied by the provider, verify the private key and peer public key, and attach the interface to the appropriate firewall zone. Pay attention to allowed IPs. An allowed-IP value that covers all destinations can create a full-tunnel route, while a narrower value may be appropriate for a destination-specific design. Do not copy an all-traffic template when your objective is selective routing.

For sing-box or an Xray-compatible client, import the subscription through the package's supported interface. Confirm that the subscription refreshes correctly, that the selected protocol is supported by the installed core, and that the client exposes a TUN or transparent proxy entry point. A successful import only proves that the configuration was parsed. It does not prove that LAN traffic is being redirected.

Test with one reserved device first. Check three paths separately: a local website or local service, a destination expected to use the tunnel, and the router's own management address. The first test confirms that the LAN still works, the second checks policy matching, and the third confirms that you did not accidentally route administration traffic into the remote path.

Create policy rules

Begin with a small policy. For example, route one television through the tunnel and leave the rest of the LAN direct. Once that works, add domain groups for destinations that need the alternate route. Depending on the client, rules may be expressed as domain suffixes, geosite categories, IP sets, address lists, or outbound selectors. Prefer a domain suffix or maintained rule set over a long list of individual IP addresses because cloud services change addresses frequently.

A sensible rule order is:

1. Allow router, LAN, and private address destinations to remain direct.
2. Bypass local domains and services that must stay on the local connection.
3. Match explicitly selected devices or destination domains for the VPN outbound.
4. Send unmatched traffic through the direct WAN path unless you intentionally require a full tunnel.

In a sing-box-style design, the conceptual structure is usually an inbound TUN interface, several outbounds, a DNS section, and route rules that select an outbound. In a WireGuard design, the conceptual structure is an interface plus firewall and policy-routing rules. The menu or configuration syntax differs by package, so do not mix a sing-box JSON example with an OpenWrt UCI section unless the package documentation explicitly supports that format.

{
  "route": {
    "rules": [
      { "ip_is_private": true, "outbound": "direct" },
      { "domain_suffix": ["lan", "local"], "outbound": "direct" },
      { "source": ["192.168.1.50"], "outbound": "vpn" },
      { "domain_suffix": ["example-service.test"], "outbound": "vpn" }
    ],
    "final": "direct"
  }
}

The example is a policy model, not a drop-in configuration. Replace the placeholder address and domain with values that exist in your network, and use the syntax required by your installed client. The key idea is that private destinations and local names are handled before VPN matches, while an explicit device or domain rule is evaluated before the final direct route.

Keep DNS consistent with routing

DNS is the most common reason a domain-based split tunnel appears unreliable. A device may resolve a service through the ISP resolver, an encrypted browser resolver, or a hard-coded DNS address while the router expects to classify every query locally. The result can be a wrong region, an address that is unreachable through the selected path, or a connection that goes direct even though the domain rule says VPN.

Choose one DNS architecture and document it. In a router-centered design, LAN clients send DNS requests to OpenWrt. OpenWrt then uses separate upstream resolvers or DNS routes according to the same policy as the traffic. Some clients support a direct DNS server and a remote DNS server, with rules selecting which one handles a domain. Others require a DNS hijack or redirect so that ordinary port 53 requests are sent to the router.

Do not treat DNS encryption as a complete routing solution. DoH or DoT can protect a DNS request from local observation, but the resolver's answer still needs to match the path used by the subsequent connection. If an application uses its own encrypted resolver, the router may not see the domain in a normal DNS request. In that case, domain policy may require TUN inspection, an application-specific rule, or an IP-based fallback.

• ✅ Keep lan, local, RFC1918 private ranges, and router management addresses on the direct path.
• ✅ Test both a domain that should bypass the VPN and a domain that should use it.
• ✅ Clear the client and router DNS cache after changing domain rules.
• ❌ Do not publish a public DNS address to clients and assume OpenWrt can still classify every query.
• ❌ Do not use a domain rule alone for an application known to connect directly to fixed IP addresses.

Local services also need correct name resolution. Printers, NAS devices, casting targets, and smart-home controllers may use multicast DNS or broadcast discovery rather than ordinary unicast DNS. A VPN client that captures all traffic can interfere with this discovery even when private IP addresses are excluded. Keep local discovery on the LAN, and consider a separate guest or IoT network when devices do not need to communicate with trusted computers.

Select routes and maintain the policy

Once the mechanics work, route selection becomes a quality and maintenance question. A service may offer many countries and lines, but the closest-looking exit is not automatically the most stable. Compare a small number of candidate routes under the same access network and time period. Observe connection establishment, page loading, streaming behavior, interactive application stability, and whether local services remain reachable.

Labels such as IEPL, BGP, or CN2 describe parts of an upstream network path and are not substitutes for testing. IEPL may indicate a dedicated private connection between locations, while BGP describes internet routing and CN2 is commonly used to identify a carrier route in China. These labels can help organize choices, but they do not guarantee identical performance for every ISP, destination, or time of day.

Use separate policy groups for different household needs rather than switching the entire router whenever one device has a problem. A work computer may need direct access to local systems, a television may need one consistent remote exit, and a game console may work better with a direct route or a carefully selected tunnel. Keeping these decisions independent reduces the chance that a change for one device disrupts everyone else.

Subscription updates should also be controlled. A refreshed subscription can add, remove, or rename outbounds and may change the default selection. After an update, verify the active outbound, the DNS path, and the rules for your important devices. If your client supports backup configuration or an explicit policy group, save a known-good state before refreshing.

Troubleshoot without losing the LAN

When a rule fails, reduce the system to a known baseline. Disable the newest policy, keep one test device, and confirm direct access first. Then enable the tunnel without selective rules, followed by one VPN match. This sequence identifies whether the failure comes from the tunnel itself, the transparent redirect, the domain set, or the DNS path.

Check the routing state

From OpenWrt, inspect the active interfaces, routes, and policy rules using LuCI or the command line tools available in your release. Confirm that the tunnel has a peer handshake or an active client session, that the default or selected route points to the intended interface, and that return traffic is not being sent through a different gateway. Asymmetric routing can look like packet loss even when the outbound tunnel is connected.

From a LAN device, compare its gateway and DNS settings before and after policy changes. If the device has cached a route or DNS response, restart the network connection or clear the cache. Test by destination category rather than relying on one browser page: use a local address, a normal direct destination, and a destination matched by the VPN rule.

Avoid double proxying and loops

Do not run two transparent proxy clients on the same OpenWrt router unless you fully understand their interception order. A TUN client, a redirect-based client, and a separate firewall redirect can capture one another's traffic. Exclude the router's own management, DNS, NTP, and tunnel endpoint traffic when the package requires it. Otherwise the router may try to reach the VPN server through the VPN route that is needed to establish the VPN.

Also avoid putting the router's WAN address, tunnel endpoint, and private LAN destinations into a broad remote rule. If the client supports an automatic bypass for the tunnel server, leave it enabled unless you have a specific reason to replace it. A safe recovery plan is to connect a computer by Ethernet, disable the last rule through LuCI, and restore the configuration backup if the web interface becomes inaccessible.

Check MTU and transport behavior

Encapsulation reduces the usable packet size. If some sites load while others stall, or if large transfers fail while small requests work, investigate MTU and fragmentation rather than immediately changing the node. WireGuard, TUN interception, TCP-based proxying, and UDP-based Hysteria2 can each have different overhead and behavior. Keep the client defaults initially, then make one MTU adjustment at a time while testing the same destination.

Some applications prefer QUIC over UDP, while others fall back to TCP. A rule that works for web traffic may not behave identically for a game, video device, or voice application. Check whether the selected client supports the transport and whether the firewall permits the required traffic. If domain matching is unreliable for that application, a device-based policy may be more predictable.

Frequently asked questions

A reliable OpenWrt split tunnel is built in layers: stable LAN identities, one verified tunnel, an explicit rule order, DNS that follows the policy, and a recovery path for local access. For users who prefer not to maintain router packages, a supported Windows, macOS, iOS, Android, or Linux client can remain a practical fallback. SQVPN supports those platforms, uses subscription-based client imports, requires no email address for registration, and offers 30-day no-questions-asked refunds. The router approach is most valuable when you need consistent rules for devices that cannot install a client themselves.