OpenWrt VPN Router Setup: Split Tunneling Rules Guide

Plan the OpenWrt VPN gateway before changing settings

OpenWrt usually operates as the gateway between your local network and the internet. Devices receive an address from the router through DHCP, use the router as their default gateway, and normally send DNS queries to the router as well. This position makes central routing possible: the router can inspect the destination, source device, domain category, or interface policy and then choose either the normal WAN route or a VPN tunnel.

Before installing packages, confirm that the router is actually running OpenWrt and that you can reach LuCI or SSH. Record the current LAN address, administrator access method, WAN interface name, and wireless network names. A backup of the existing configuration is especially important when the router is the only way to reach the internet. Save the backup locally rather than relying on a file stored on a device that depends on the router.

Choose a routing mode

There are three practical starting modes. In a full-tunnel design, all selected LAN traffic goes through the VPN and only explicitly excluded destinations use the WAN. This is easy to understand for a dedicated device or a separate guest network, but it can interfere with local services, banking sites, regional content, printer discovery, and router updates if exclusions are incomplete.

In a split-tunnel design, the WAN remains the default route and only specified devices, domains, IP ranges, or ports use the VPN. This is usually the safest first configuration for a mixed household. Local devices continue to communicate locally, ordinary traffic keeps its normal path, and you can add rules gradually. A third option is device-based routing: for example, a television or a separate wireless SSID can always use the VPN while work computers and local infrastructure stay direct.

• ✅ Begin with one LAN client, one tunnel, and one clearly identifiable destination.
• ✅ Decide whether rules are based on source device, destination domain, destination IP range, or a separate network.
• ✅ Keep router administration and local subnets reachable through the direct interface.
• ✅ Write down the intended default route before enabling policy routing.
• ❌ Do not assume that an active tunnel automatically captures all LAN traffic.
• ❌ Do not test by changing every routing option at once; it becomes difficult to identify which change caused the failure.

Make a simple policy table before implementation. For example, the router itself, printers, NAS devices, and local management addresses can remain direct. A dedicated television address or guest network can use the VPN. Work devices can use direct routing unless a specific destination needs another path. This table is more useful than a vague instruction such as “send streaming traffic through the VPN,” because many applications use several domains and services.

Select a VPN protocol and create the tunnel

OpenWrt can work with different tunnel technologies, but the setup method depends on the protocol and the package available for your firmware target. WireGuard is commonly convenient for a router because its configuration is compact and the tunnel interface integrates cleanly with firewall and routing rules. OpenVPN is also widely supported, although its configuration can involve certificates, authentication files, cipher settings, and more service-specific options.

Shadowsocks, VMess, Trojan, Hysteria2, and similar protocols are not interchangeable with WireGuard or OpenVPN. They generally require a compatible client such as sing-box, Xray, or another OpenWrt-supported implementation. A normal subscription link is not automatically a complete OpenWrt configuration. If your provider offers a subscription, first determine whether the router client can parse that format. Otherwise, export the required server parameters into the client’s native configuration format and keep credentials private.

WireGuard and OpenVPN considerations

For WireGuard, you typically need a private key on the router, a server public key, an endpoint address, an allowed-address policy, and possibly a keepalive setting. The meaning of AllowedIPs is important: it can describe traffic accepted through the peer and also influence routing. A broad value may create a full-tunnel route, while a narrower value can support selective destinations. Do not copy a full-tunnel example into a split-tunnel design without checking the resulting routes.

For OpenVPN, check whether the provider expects UDP or TCP, certificate authentication, username and password authentication, or additional TLS settings. Importing a profile may create a tunnel successfully but still fail to route LAN traffic if the profile pushes routes that conflict with your policy-routing design. If the profile redirects the default gateway, decide whether to accept that behavior or disable it in a way supported by the provider and your security requirements.

Use LuCI when the available interface exposes all required fields clearly. SSH and configuration files can be more precise, but a typo in a UCI option can leave the service stopped or create a route that is hard to diagnose. After saving a tunnel, check its service status, interface address, handshake or connection state, and route table before adding split-tunnel rules.

Do not install several competing VPN management systems on the router without a reason. A native WireGuard configuration, a policy-routing package, and a separate sing-box service can coexist, but each additional manager may create its own firewall assumptions, DNS behavior, and startup rules. Choose one primary method, document its interface names, and add another component only after the first path works.

Configure split tunneling rules step by step

Policy routing on OpenWrt is normally implemented with firewall marks, routing tables, and rules that select a table for matching traffic. Many users manage this through a policy-routing package such as pbr and its LuCI interface, while some installations use a different compatible package or manually maintained firewall rules. Package names and options can vary by OpenWrt release, so confirm that the package matches your firmware version and target architecture before installing it.

Prepare stable client identities

Device-based rules should not depend on an address that changes every time a client reconnects. Create a DHCP reservation for the television, computer, or phone that will be used in testing. You can identify a client by its reserved IPv4 address, MAC address where supported, or a dedicated VLAN and wireless network. A separate guest or media network is often easier to reason about than a long list of individual devices.

Be careful with phones and tablets that use private or randomized MAC addresses. The router may see a different identity after the wireless network is forgotten or privacy settings change. If a policy suddenly stops matching, check the DHCP lease and client identity before rebuilding the VPN configuration.

Create the first policy

Start with one policy that sends one reserved client through the VPN. Keep the rule narrow and give it a descriptive name, such as “test television through tunnel.” If the policy interface provides choices for source address, destination, interface, and DNS, fill in only what you need. A source-device rule is a good first test because it avoids guessing every domain used by an application.

After the device rule works, add destination-based policies when the use case requires more selectivity. Domain rules can be convenient, but an application may use a content delivery network, an authentication domain, an API hostname, and a separate media hostname. A single domain entry may therefore produce an incomplete result. IP rules can be more predictable for a fixed service, but large providers may change addresses or use shared infrastructure. Treat domain and IP lists as maintenance items rather than permanent truths.

# Illustrative checks; replace interface and address names with your own values
ip addr show
ip route
ip rule
logread | grep -i -E 'pbr|wireguard|openvpn'
nslookup example.com

The commands above are diagnostic examples, not a universal configuration. The interface may be named vpn, wg0, or something created by a package. Use the actual names shown on your router. After changing a policy, restart only the relevant service if possible, renew the client lease, and reconnect the test device. Restarting the whole router after every edit can hide startup-order problems and makes troubleshooting slower.

Handle DNS and IPv6 deliberately

DNS determines which address a domain name resolves to, while policy routing determines where packets travel. They are related but not identical. If a client sends DNS to the router and the router forwards it through the direct WAN while the application traffic uses the VPN, the service may see inconsistent locations. If DNS goes through the VPN but the application uses a direct IPv6 path, the result can be equally confusing.

Choose a DNS design that matches your policy. You may use the router as the LAN resolver and forward queries according to the intended interface, or use a resolver supplied by the VPN configuration where supported. Make sure local hostnames and router management names still resolve. Do not blindly redirect every DNS packet if local discovery or a required enterprise resolver depends on the original behavior.

IPv6 deserves a separate decision. If the VPN tunnel and policy rules support IPv4 only, clients with native IPv6 may bypass the intended route. You can either configure IPv6 tunneling and policy routing correctly or disable IPv6 on the relevant network while testing, using the option appropriate for your environment. The important point is consistency: verify both address families instead of checking only an IPv4 result.

Test each rule and troubleshoot failures

Testing should happen from the client device, not only from the router. First record the public exit address while the device uses the normal WAN route. Then apply the VPN policy, reconnect the client, and check the address again. A changed exit address suggests that the traffic followed the tunnel, but it does not prove that every application, DNS query, or IPv6 connection did the same.

Next, test a local resource such as the router administration page, a printer, or a NAS name. Local access should remain available if your policy is designed to preserve LAN traffic. Then test a direct destination and the destination intended for the VPN. Compare the results after changing only one rule. For DNS, inspect the resolver shown by the client and query a few domains from the client itself. Browser results alone can be misleading because browsers may cache answers or use their own secure DNS feature.

• ✅ Confirm the tunnel interface is up and has the expected peer or session state.
• ✅ Confirm the test device received its reserved LAN address.
• ✅ Compare the public exit address before and after the policy is enabled.
• ✅ Test local resources to ensure the rule has not broken LAN access.
• ✅ Check both IPv4 and IPv6 behavior when IPv6 is enabled.
• ✅ Review OpenWrt system and firewall logs after a failed connection.
• ❌ Do not use only the VPN icon or tunnel status as proof that application traffic is routed correctly.
• ❌ Do not add broad domain lists until the basic device-based rule has passed testing.

Common failure patterns

If the VPN interface is up but the client still uses the WAN, inspect the policy service status, source address, firewall zone, and selected routing table. A typo in a reserved address or a rule applied to the wrong LAN interface is common. If all internet access disappears, temporarily disable the new policy, confirm that the WAN route works, and then inspect whether a full-tunnel route was introduced unintentionally.

If local services stop working, check whether the policy is sending private LAN ranges into the VPN. Private addresses such as the router’s LAN subnet normally need a direct route. If only some websites fail, investigate DNS, MTU, and IPv6 before assuming the server is unavailable. A tunnel can connect successfully while packets larger than the path supports are fragmented or dropped; an appropriate MTU adjustment may be needed, but change it gradually and document the original value.

If a television application behaves differently from a browser, remember that the television may use hard-coded DNS, IPv6, multiple service domains, or certificate and time checks. Test the device’s actual network behavior. A router rule based on one hostname cannot guarantee that every related service uses the same hostname.

Back up, restore, and maintain the configuration

Before adding more policies, export an OpenWrt configuration backup and keep a short written record of the working state. Note the tunnel protocol, interface name, firewall zone, DNS choice, reserved client addresses, and policy package settings. A screenshot is useful for visual options, but a configuration backup and a plain-text change log are more useful when you need to undo one part of the setup.

When a new rule causes problems, first disable that rule rather than deleting the entire VPN service. If the issue remains, disable the policy-routing service and verify that ordinary WAN routing returns. Then test the tunnel separately. This three-step rollback distinguishes a bad client rule from a broken tunnel and from a general firewall problem.

Keep the router firmware and packages compatible. An upgrade can change firewall behavior, package syntax, kernel modules, or service startup order. Read the release notes, back up the configuration, and avoid upgrading immediately before an important trip or event. After an upgrade, test LAN access, WAN access, the VPN handshake, DNS, IPv4, IPv6, and at least one split-tunnel policy.

Review domain-based rules periodically. Services change hostnames, use regional endpoints, or move traffic to new content delivery addresses. If a rule is business-critical, prefer a stable network design such as a dedicated client or VLAN when appropriate, and keep a direct fallback available. The purpose of central routing is to reduce repetitive setup, not to make troubleshooting impossible.

OpenWrt VPN setup FAQ

A well-designed OpenWrt gateway is built through small, testable changes. Establish the tunnel, reserve one test device, apply one split-tunnel rule, verify routing and DNS, and only then expand to more clients or destinations. This approach keeps the router understandable and gives you a clear rollback path whenever a new policy affects connectivity.