How to Set Up VPN Split Tunneling on an OpenWrt Router

OpenWrt split tunneling lets you send traffic from selected devices through a VPN while other devices continue using the router’s normal internet connection. The router makes the routing decision, so a laptop, television, or work computer can follow a different path without changing VPN settings on every device.

The reliable way to set this up is to make the VPN interface work first, assign selected devices stable local addresses, and then add policy-routing rules. Test DNS and IPv6 as well as ordinary web access, and keep a rollback path before changing firewall or routing settings. OpenWrt menu names and package behavior vary by release, so treat the examples below as a method rather than a universal set of screenshots.

What router split tunneling means

A router normally sends traffic from devices on its local network through the internet connection supplied by the internet service provider. When a VPN tunnel is active, the router also has a virtual interface that can carry traffic to a VPN endpoint. Split tunneling uses routing rules to decide which device or destination should use which interface.

For a home setup, the easiest policy to reason about is usually device-based: selected devices use the VPN, and everything else uses the regular WAN connection. This is different from configuring a VPN client on each device. It is also different from choosing a proxy inside a browser. A router policy can apply to a device’s wider network traffic, subject to the protocols, DNS behavior, and rules supported by the installed software.

In this context, policy-based routing, often abbreviated as PBR, means choosing a route based on a rule rather than applying one default route to every connection. A rule might match a device’s local IP address, a source subnet, or a destination. The exact match options depend on the OpenWrt release and the PBR package version. Start with a small number of device rules; complicated combinations of device, domain, and destination rules are harder to diagnose.

OpenWrt does not turn every provider’s subscription URL into a router-ready VPN profile. WireGuard and OpenVPN are common tunnel types that OpenWrt can use when you have the corresponding configuration details and packages. If your service supplies a profile or subscription intended for a separate client, confirm that its protocol and configuration format are compatible with your router software. Do not paste account credentials or subscription links into an untrusted converter.

Keep the routing choice and the tunnel type separate in your thinking. A VPN protocol creates the tunnel; policy routing decides which traffic uses it.

Prepare the router and devices

Before installing packages or editing firewall settings, confirm how you can regain access to the router. Make a configuration backup from the OpenWrt administration interface, save it somewhere you can reach if the VPN stops working, and note the router’s local management address. If you administer the router remotely, do not change its default route or firewall policy until you have a safe local recovery option.

Next, identify the devices that should use the tunnel. Assign each one a stable address using a DHCP static lease, or create a dedicated local subnet if your network design calls for it. A policy rule that refers to an address is only predictable if that device keeps the address. A changing DHCP lease can make a rule appear to work one day and apply to another device later. If you use MAC-based matching, remember that some phones and computers use private or randomized MAC addresses; a DHCP reservation for the address the device actually presents may be easier to maintain.

Write down the intended behavior before you configure anything. For example, you might want a media device and one test laptop to use the VPN, while printers, smart-home equipment, and other computers stay on WAN. Also decide what should happen if the tunnel goes down. A fail-open policy lets the selected device fall back to WAN; a fail-closed policy blocks its internet access until the VPN is available. Neither choice is universally right: consider the device’s purpose and the consequences of traffic taking the other path.

• ✅ Back up the router configuration and confirm local access before making changes.
• ✅ Give each policy-controlled device a stable DHCP lease or stable address.
• ✅ Decide whether tunnel failure should allow WAN fallback or block the selected device.
• ❌ Do not change the router’s only management path while connected remotely.
• ❌ Do not assume that a VPN connection automatically routes DNS or IPv6 through the tunnel.

Before setting up a home router, it can also help to review the service’s available client options and account information on the VPN72 China VPN homepage; then verify that the specific profile you plan to use can be configured on OpenWrt. Having a provider account does not by itself mean the router can import every client subscription format.

Configure the VPN and policy rules

The steps below describe a general workflow for current OpenWrt systems. Package names, LuCI menus, and configuration options can differ between releases, installed builds, and firewall versions. Check the documentation for the OpenWrt release running on your router before installing packages or copying commands. Do not mix instructions intended for different firewall generations.

1. Install or create the tunnel interface. Use the appropriate OpenWrt package and the provider’s router-compatible configuration. For WireGuard, this normally includes a private key, peer public key, endpoint, allowed IPs, and any required DNS or keepalive settings. For OpenVPN, it may involve a profile and authentication details. The required fields are provider- and protocol-specific; do not reuse a profile for a different protocol.

2. Bring up the tunnel without changing policy yet. Confirm that the interface is active and that the router can reach the VPN endpoint. Where possible, test from the router itself or from a temporary test device before adding the final device rules. An active interface status alone does not prove that client traffic is being routed correctly.

3. Check firewall-zone and forwarding settings. The VPN interface needs the firewall treatment required by the configuration, and selected LAN traffic needs a permitted route to it. Avoid disabling the firewall to “make the VPN work.” That can expose router services or local devices and obscure the actual routing problem. Follow the release-specific OpenWrt instructions for zones, forwarding, and any masquerading required by the tunnel setup.

4. Install and configure policy routing if needed. OpenWrt installations often use a PBR package and its service integration for selectable routing policies. Confirm that the package supports your release and that its service starts successfully. Add the VPN interface as a usable policy target, then create a rule matching the stable local address of one test device. Keep unrelated devices on the normal WAN route.

5. Apply a narrow test rule. Start with one device and a basic rule rather than adding every device at once. If the package offers a policy status page, inspect whether the intended rule is enabled and whether it refers to the correct interface and source. Save the configuration, restart only the relevant service if required, and check that the router remains reachable.

6. Test both sides of the split. From the selected device, check that an external IP-check service reports the expected VPN exit region, then open a few ordinary sites and any application you care about. From a device that should remain direct, confirm that it still uses the usual connection. A single successful web page does not prove that every app, protocol, or background service follows the same route.

7. Expand gradually and save a known-good backup. Add the remaining devices one at a time, testing after each change. Once the setup behaves as intended, export a fresh configuration backup and record which addresses and policies correspond to each device. This makes future troubleshooting less dependent on memory.

VPN setup interfaces can expose sensitive keys and credentials. Use the router’s authenticated administration session, avoid sharing screenshots containing secrets, and store backups securely. When you need to replace a profile, remove the old credentials from the relevant configuration rather than leaving unused access details in notes or pasted commands.

Test routing, DNS, and failure behavior

Testing should answer three separate questions: which route carries the traffic, which resolver handles DNS requests, and what happens when the tunnel is unavailable. A website loading only answers part of the first question. If the selected device’s public address still appears to be the normal ISP connection, investigate the PBR match, the device’s local address, and the VPN interface target before changing unrelated firewall settings.

DNS deserves a separate check because a device can send web traffic through the VPN while sending name lookups to a resolver reached through WAN. Whether that occurs depends on the router’s DNS configuration, the tunnel profile, and any encrypted-DNS settings on the device or application. Inspect the resolver behavior from a selected device and check the router’s DNS and PBR documentation for supported routing options. Avoid concluding that DNS is protected simply because the tunnel interface is connected.

Also consider IPv6. If the VPN setup only handles IPv4 but a device can reach destinations over IPv6, some traffic may take a different route from the one you intended. The appropriate solution depends on the provider, OpenWrt configuration, and local network. Either configure IPv6 routing consistently or make a deliberate, documented choice about IPv6 for the affected devices. Randomly disabling firewall rules is not a safe substitute for understanding the path.

To test failure behavior, use a planned maintenance window and a device that will not interrupt essential work. Temporarily stop the VPN interface using the supported administration controls, then check whether the selected device loses access or falls back to WAN according to your policy. Restore the interface immediately after the test and confirm that the policy service recovers. Do not pull router power or disconnect the WAN cable as a first troubleshooting step; those actions can make the result harder to interpret and may interrupt other users.

For an orderly diagnosis, compare a VPN-selected device with a direct device while keeping the tests otherwise similar. Check address assignment, the PBR rule status, tunnel status, DNS resolution, and the result after reconnecting the client device to the network. If a rule works for one device but not another, compare their DHCP leases and private-address settings before rebuilding the whole configuration.

Common problems and safe rollback

If the tunnel connects but the selected device has no internet access, check the VPN peer configuration, allowed routes, firewall forwarding, and whether the policy targets the actual tunnel interface. A tunnel can be established while traffic forwarding is still incorrect. If every device loses access after enabling PBR, disable the new policy service or revert the last change using local administration access, then restore the backup if needed.

If only some apps ignore the intended route, determine whether the app uses a different address family, a separately configured DNS resolver, or a connection method not covered by the rule. Some devices also retain network state after a route change. Disconnect and reconnect the device or renew its network lease using its normal settings, then repeat the test. Do not assume that a browser’s result represents the behavior of all apps on that device.

If direct devices unexpectedly use the VPN, inspect broad policies and default-route settings. A rule matching an entire LAN subnet can take precedence over a rule intended for only one device, depending on the package’s ordering and configuration. Remove duplicate or overlapping policies and return to a single test device. If router administration becomes unavailable, reconnect from the local network, use the recovery method documented for that OpenWrt device, or restore the saved configuration. Exact recovery procedures depend on the model and firmware build.

• Selected device stays on WAN: verify its current local address, the source match, policy enablement, and VPN interface status.
• Direct device uses the VPN: inspect subnet-wide rules, default routing, and rule precedence.
• Names fail but IP connectivity works: investigate DNS configuration and which route carries resolver traffic.
• Some traffic takes an unexpected path: check IPv6, app-specific DNS, and whether the rule covers the relevant protocol.
• Router access is lost: stop making remote changes; regain local access and restore the known-good backup if necessary.

Keep the final configuration simple enough to explain: which devices use the tunnel, which interface they use, how DNS is handled, and what happens if the tunnel fails. If the setup becomes difficult to audit, remove extra rules and retest from a minimal baseline rather than layering more exceptions onto an uncertain configuration.

OpenWrt VPN split-tunneling FAQ

Can OpenWrt import any VPN subscription link?

No. A subscription link may be designed for a particular desktop or mobile client and may contain formats or protocol details that OpenWrt does not directly use. Check whether the provider supplies a compatible router configuration, and confirm that the required protocol and packages are supported by your OpenWrt release.

Should I route devices or websites?

Device-based rules are often easier to test and maintain on a home network because they use stable local addresses. Destination-based rules can be useful for specific goals, but domains may resolve to changing addresses and apps may use additional endpoints. Choose the narrowest rule that achieves the intended behavior, then test it from the actual device and application.

Will a router VPN cover every connection from a device?

Not automatically. The result depends on the routing rule, IPv4 and IPv6 configuration, DNS behavior, firewall policy, and any network controls within the device or application. Verify the traffic types that matter instead of assuming that one successful browser test proves complete coverage.

What is the safest way to undo a policy?

Use local router access, disable the relevant PBR rule or service through the supported controls, and restore the known-good configuration backup if necessary. Keep the router’s management path outside experimental routing policies, and avoid remote changes that could cut off the connection needed to recover it.