OpenWrt VPN Router Setup Guide: Configure Split Tunneling

Running a VPN on an OpenWrt router can centralize network access for phones, laptops, smart TVs, game consoles, and other devices that do not offer a convenient VPN client. Instead of configuring every device separately, the router becomes the point where traffic is classified, encrypted, and sent through the selected VPN route. The most flexible design is split tunneling: only selected devices, domains, IP ranges, or applications use the VPN, while ordinary local and regional traffic continues through the normal WAN connection.

This arrangement is powerful, but it is not a single checkbox. You need to confirm that the router has enough storage and memory, select a protocol that the firmware and provider support, import the connection details correctly, define routing rules, and make sure DNS requests follow the same policy as the traffic they resolve. A technically correct tunnel can still appear broken if DNS, IPv6, firewall zones, or policy-routing rules are inconsistent.

Check OpenWrt compatibility first

Start by treating the router as a small Linux system rather than as a normal desktop VPN client. The router must run the VPN process continuously, maintain encryption keys, apply firewall rules, and sometimes perform policy routing for several clients at once. Hardware capability therefore matters more than the appearance of the LuCI interface.

Review hardware, storage, and firmware

Log in to LuCI or connect to the router over SSH and record the OpenWrt release, target platform, available storage, memory, and current network layout. The exact menu names can differ between releases and installed packages. Avoid copying instructions written for a different target without checking the package architecture first. Installing a package built for the wrong platform can fail immediately or leave a partially configured service.

Storage is needed for the VPN client, policy-routing components, certificates, logs, and configuration files. A router with very limited flash space may be able to run a lightweight tunnel but become difficult to maintain after several packages are added. Memory is also relevant when the router serves many wireless clients, runs ad blocking, records logs, or handles multiple routing tables at the same time.

The platform list includes Windows, macOS, iOS, Android, and Linux, but router support is a separate question. OpenWrt can use standard protocol configurations, yet the router does not normally install the official desktop or mobile application. Instead, you use a compatible OpenWrt package and import the provider’s server parameters or subscription information in a format supported by that package.

Choose a protocol that fits the router

WireGuard is often a practical starting point on OpenWrt because its configuration is compact and its tunnel model is straightforward. A profile generally contains a private key, an interface address, a peer public key, an endpoint, and allowed IP settings. The crucial point is that AllowedIPs has both routing and peer-selection implications. Using a full-tunnel value such as 0.0.0.0/0 sends all IPv4 traffic toward the peer unless policy routing later excludes it.

OpenVPN is also widely supported and can be appropriate when the provider supplies an OpenVPN profile or when compatibility with an existing setup is more important than minimal configuration. Its profile may reference certificates, authentication data, remote endpoints, cipher settings, and transport choices. Do not remove certificate or authentication directives simply because the file looks complicated.

Shadowsocks, VMess, Trojan, and Hysteria2 are not interchangeable with WireGuard or OpenVPN. They are commonly handled by different proxy clients or routing frameworks, and the configuration fields, transport behavior, and DNS integration vary. A provider subscription link may be intended for Clash Verge, sing-box, or another compatible client rather than for the native OpenWrt network interface. Confirm that the OpenWrt software you plan to use understands the subscription format before importing it.

IEPL, BGP, and CN2 describe network paths or upstream connectivity rather than VPN encryption protocols. A line advertised with one of these terms still needs a client-compatible protocol and valid credentials. Select a region and route based on the destination, then verify whether the configuration is supported by the OpenWrt client you have chosen.

Prepare and configure the VPN client

Before changing the router’s default route, make the connection work in a controlled way. If possible, test the same account and line in a supported desktop or mobile client first. This separates account or server problems from OpenWrt configuration problems. It also lets you confirm the intended exit region and identify whether the provider gives you a WireGuard profile, an OpenVPN file, a proxy subscription, or another format.

Install the required components

OpenWrt installations commonly use LuCI for administration and SSH for package installation or diagnostics. Update the package index using the package manager appropriate for your OpenWrt release, then install only the components required by the chosen protocol and routing design. Depending on the release and package selection, this may include a WireGuard or OpenVPN client, LuCI integration, firewall support, DNS tools, and a policy-routing package.

Do not install several competing VPN managers at the same time just because their interfaces look convenient. Two services may create duplicate interfaces, conflicting firewall zones, or multiple default routes. If you are migrating from one manager to another, disable the old service and remove obsolete rules after saving a backup of the configuration.

Import the profile carefully

For WireGuard, create a tunnel interface and enter the provider-supplied values exactly as provided. Pay attention to key roles: the router keeps the private key, while the remote server is identified by its public key. The endpoint must contain the correct host and port, and a keepalive value may be useful when the router is behind a restrictive NAT. Do not publish private keys, client certificates, or authentication tokens in screenshots or support requests.

For OpenVPN, upload the profile only through the router’s protected administration interface and store username and password data in the method recommended by the package. Check whether the profile expects a separate certificate, a key file, or an inline block. A successful process start is not enough; the tunnel interface must receive the expected address and the firewall must permit the intended forwarding.

If you use sing-box or another proxy-oriented client, first determine how it integrates with OpenWrt. Some designs create a transparent proxy using a TProxy or redirect mechanism; others expose a local SOCKS or HTTP port that selected applications must use. Transparent proxying and native layer-3 VPN routing are different designs. Mixing their firewall rules without understanding the traffic flow can create loops, duplicate DNS interception, or inaccessible LuCI pages.

1. Back up the current OpenWrt configuration before adding the tunnel.
2. Install the client and routing components that match the selected protocol.
3. Create the tunnel interface without changing the whole router’s default route yet.
4. Start the client and inspect its status, handshake, assigned address, and recent log entries.
5. Test one designated device before applying the policy to the rest of the LAN.

For an initial test, keep the router’s normal WAN as the default route and send only one test device through the VPN. This prevents a configuration error from disconnecting every household device. If the test device cannot reach anything, inspect the tunnel status first, then firewall forwarding, then DNS. Changing all three areas at once makes the cause much harder to identify.

Configure split tunneling with policy routing

Split tunneling means that routing decisions are made according to a defined policy instead of sending every packet through one default interface. The policy can be based on source devices, source IP addresses, destination addresses, domains, ports, or combinations of these. On OpenWrt, the most maintainable starting point is usually source-based routing: assign a stable DHCP lease to a device, then place that address in the VPN policy.

Start with device-based rules

Reserve an address for the test phone, laptop, or television in the router’s DHCP settings. Then create a policy that sends that source address through the VPN interface while leaving all other LAN addresses on WAN. This is easier to verify than a domain list because the device’s traffic follows one predictable path. It also avoids the problem of a service using several domains, content delivery networks, or changing destination addresses.

When the policy-routing package offers a strict or fallback mode, read the description carefully. In a strict design, traffic matching the VPN policy stops when the tunnel is unavailable. In a fallback design, it may return to WAN. Strict behavior can reduce accidental direct connections, but it may make the selected device appear offline during a tunnel outage. Fallback can preserve connectivity, but it may not meet a requirement that selected traffic must never leave through WAN.

Use separate policies for separate goals. For example, a television may need a VPN route for a regional streaming service, while a work laptop may need only a small set of destinations routed through the tunnel. Avoid putting the entire LAN into the VPN policy simply because it is faster to configure. Local printers, router services, file shares, and domestic services often work better when they remain on the normal LAN and WAN paths.

Use domain and destination rules with care

Domain-based routing is convenient when only one website or application should use the VPN, but it depends on DNS and address discovery. A domain may resolve to several addresses, use separate domains for login and media, or deliver content through a changing CDN. If the router resolves the name through one DNS path and the client connects through another, the policy may not match as expected.

Destination IP rules are more deterministic but require maintenance. Large services may publish many address ranges, and an address can host multiple unrelated services. Do not assume that routing one visible domain name covers every API, authentication host, image host, or update endpoint used by an application. Begin with a small rule set, observe actual connections, and expand it only when there is a clear reason.

Handle DNS and IPv6 consistently

DNS is often the reason a split-tunnel setup appears inconsistent. If a device uses the router for DNS but the router forwards queries through WAN, the result can reveal a different resolver path from the VPN traffic. If a domain policy depends on the resolved address, the routing decision may also be wrong. Decide whether DNS should follow WAN, VPN, or a controlled resolver policy, and apply that decision consistently.

Check DHCP announcements, router DNS forwarding, encrypted DNS settings, and hard-coded DNS on the client device. Some applications use their own DNS-over-HTTPS or DNS-over-TLS connection and therefore bypass the router’s ordinary DNS policy. In those cases, domain-based routing may not behave as expected without an explicit strategy for that application.

IPv6 needs a separate review. A policy that covers only IPv4 can leave IPv6 traffic on the ordinary WAN route. You can either configure a complete IPv6 tunnel and policy, or disable IPv6 on the relevant network only when that is appropriate for your environment and supported by your connectivity plan. The important point is not to assume that an IPv4 VPN rule automatically protects IPv6 traffic.

• ✅ Reserve stable LAN addresses for devices used in policy rules.
• ✅ Test one device and one policy before expanding the scope.
• ✅ Decide whether DNS should use WAN, VPN, or a dedicated resolver path.
• ✅ Review IPv6 separately instead of assuming IPv4 rules cover it.
• ❌ Do not run two transparent proxy systems with overlapping redirect rules.
• ❌ Do not use a large destination list without a plan for updates and exceptions.

Test the route and troubleshoot methodically

Test in layers. First confirm that the router itself has normal WAN connectivity. Next confirm that the VPN client is running and that the remote peer has a recent handshake or an active OpenVPN session. Then test the selected device while checking its route, DNS result, and public exit region. Finally, test an unselected device to verify that it still uses WAN and can access local services.

Use the router’s status pages and logs rather than relying only on whether a web page opens. For WireGuard, inspect the interface state, peer handshake time, transmitted and received counters, endpoint, and allowed routes. For OpenVPN, look for authentication success, certificate validation, tunnel initialization, and route installation. A process that is “running” may still lack a usable route or may be blocked by a firewall zone.

Common failure patterns

The tunnel starts but the selected device has no internet: check forwarding from the LAN zone to the VPN zone, masquerading on the VPN interface, the policy-routing table, and the tunnel’s allowed routes. If the provider expects a full-tunnel profile but the router is using only a narrow route, return traffic may not follow the intended path.

All devices use the VPN unexpectedly: inspect whether the VPN interface replaced the main default route, whether a full-tunnel option was enabled globally, and whether the policy package is operating in a default-to-VPN mode. Restore the WAN default route and rebuild the policy with one source address.

The selected device uses WAN instead of VPN: verify that its DHCP address has not changed, that the policy rule matches the actual source address, and that the rule is enabled in the correct order. Clear stale connections after changing routing rules, because an existing session may continue through its original path until it closes.

Websites open by IP but not by name: investigate DNS forwarding, encrypted DNS inside the application, and DNS policy rules. A working tunnel does not prove that name resolution follows the same route. Also check whether the domain list includes the service’s authentication or API domains.

Local devices stop working: make sure traffic to the router, local subnet, printer, NAS, and multicast services is not being sent into the VPN. Add explicit local-network exceptions where necessary. If guest Wi-Fi and the main LAN share policies unintentionally, separate them with VLANs or distinct firewall zones.

The router becomes unreachable after a rule change: connect from the trusted LAN, use a local console if available, or restore the previous configuration backup. Avoid applying several firewall and routing changes during a remote session. A safety policy that keeps router management traffic on the LAN can prevent many lockouts.

Make the configuration maintainable

Give every rule a clear name such as “TV through VPN” or “Laptop work destinations,” and record the reason for each exception. Keep a backup after the tunnel works and another backup after split tunneling is verified. Do not store private keys in plain notes or publish complete configuration files when asking for help.

When changing lines, regions, or protocols, change one variable at a time. First replace the server profile while keeping the routing policy unchanged. Then test the tunnel. Only after that should you alter DNS or destination rules. This approach makes it possible to identify whether a failure comes from the server profile, authentication, firewall, route selection, or name resolution.

OpenWrt VPN setup FAQ

Can every OpenWrt router run a VPN?

No. Compatibility depends on the OpenWrt target, available storage and memory, package support, encryption workload, and the number of clients using the router. A router may support OpenWrt but still be unsuitable for a complex transparent proxy or several simultaneous routing policies. Check the device architecture and resources before installing packages.

Can I use the official client and the router VPN at the same time?

Yes, but they should be treated as separate paths. A device with its own official Windows, macOS, iOS, Android, or Linux client may create another tunnel on top of the router policy. Test for route conflicts, duplicate DNS handling, and unexpected exit regions. Usually, keep the official client disabled on devices that are intentionally managed by the router, unless you have a specific layered-routing reason.

Can I paste a subscription link directly into OpenWrt?

Only if the OpenWrt client explicitly supports that subscription format. A link intended for Clash Verge, sing-box, Shadowrocket, or another compatible client may not be understood by a native WireGuard or OpenVPN interface. When direct import is unavailable, obtain the protocol profile supported by the router client and enter or upload its parameters through the appropriate interface.

What is the safest first split-tunnel policy?

Start with one device that has a reserved LAN address and route all of that device’s traffic through the VPN while leaving the rest of the network on WAN. Confirm DNS, IPv4, IPv6, local services, and tunnel failure behavior. Once that works, narrow the policy to destinations if needed. This staged method is easier to reverse and less likely to interrupt the whole network.

For a centralized setup, VPN TX supports Windows, macOS, iOS, Android, and Linux clients, while router users can work with compatible protocol configurations and third-party clients. Plans include 90+ countries and 200+ lines, simultaneous online devices are unlimited, and registration requires only a username and password rather than an email address. Review the supported configuration format before deploying it on OpenWrt, then keep the router policy as explicit and minimal as possible.