OpenWrt VPN Router Setup Guide: Smart Routing Rules

Turning an OpenWrt router into a VPN gateway can be more convenient than installing a separate client on every phone, computer, television, or game console. Once the router is configured correctly, devices on the home network can use a central connection without each device needing its own subscription import or proxy application. The important part is not simply making the router connect to a server. A practical setup also needs smart routing: selected domains should use the tunnel, while local services, domestic websites, printers, NAS devices, and other destinations should remain on a direct connection.

OpenWrt gives you the flexibility to build this arrangement, but it also exposes more networking details than a normal desktop client. You need to think about the tunnel protocol, DNS behavior, firewall zones, routing rules, IPv4 and IPv6, and how devices are identified. This guide explains a reliable planning method, the main implementation choices, and a troubleshooting process that avoids changing several variables at the same time.

Plan the OpenWrt gateway before installing packages

Begin by deciding what the router should accomplish. There are three common designs. In a full-tunnel design, nearly all internet traffic from selected devices enters the VPN. In a split-tunnel design, only chosen domains, IP ranges, or applications use the tunnel. In a device-based design, one television or testing device uses the VPN while the rest of the network remains direct. Smart routing usually combines the second and third designs: route a defined group of destinations through the tunnel and preserve normal access for everything else.

The router must also have enough storage, memory, and processing capacity for the packages and encryption method you plan to use. OpenWrt versions, target platforms, and package repositories differ, so do not copy a package command from an unrelated firmware release without checking compatibility. A configuration written for one proxy core may not be accepted by another. Likewise, a configuration URL designed for Clash, sing-box, or a proprietary application may require conversion or manual adaptation before it can run on OpenWrt.

HBVPN supports Windows, macOS, iOS, Android, and Linux clients, but a router is a different environment. A desktop client can often import a subscription link with one click and provide a graphical rule editor. OpenWrt generally needs a compatible service package, a proxy core, or a standard tunnel configuration such as WireGuard. Therefore, confirm the format offered by your account before designing the router setup.

Choose a tunnel method that OpenWrt can maintain

WireGuard is often the most straightforward option when a provider supplies a complete WireGuard profile. The configuration normally includes a private key, an interface address, a peer public key, an endpoint, and allowed IP settings. OpenWrt can manage WireGuard through LuCI or command-line tools, and its behavior is comparatively easy to inspect with standard routing commands. The main limitation is that a simple WireGuard profile does not automatically provide domain-based smart routing. You must add policy-routing logic, firewall marks, DNS integration, or a compatible management package.

Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC are proxy protocols rather than interchangeable names for the same feature. They differ in transport behavior, encryption or authentication design, connection handling, and client support. A sing-box or Clash-compatible configuration may contain several of these protocols, but OpenWrt still needs a proxy core that understands the selected format. Do not assume that importing a URL into a WireGuard interface will work, or that a generic OpenVPN package can read a proxy subscription.

For a first deployment, choose one core and one configuration source. Running several cores at once makes port assignments, DNS ownership, and firewall behavior harder to understand. If the provider supplies a standard WireGuard profile, it is usually sensible to test that route first. If the provider supplies a subscription intended for sing-box or Clash-compatible clients, use a router package that explicitly supports that format and verify how it handles updates.

Before changing the router, export or record the current network settings. Note the LAN address, DHCP range, wireless names, DNS settings, and any existing port forwards. Keep a local copy of the original configuration. If the router becomes unreachable, you should be able to disable the new service from a local connection or use the device’s documented recovery method.

Build a clear network layout and routing policy

A simple layout has an OpenWrt router connected to the normal upstream network, a LAN bridge serving household devices, and one VPN interface or proxy listener. The router remains the default gateway for clients. Traffic is then classified according to destination, source device, or both. The classification decides whether packets use the normal WAN interface or the VPN path.

Domain rules require special care because routers route packets by IP address, while users think in domain names. A domain must first be resolved to an address, and the router must know which addresses belong to the VPN rule set. If a client resolves a domain using an unrelated DNS server, the router may not see the query or may receive an address that does not match the intended policy. This is why smart routing is usually a combined DNS and firewall design rather than a list of domains alone.

Separate direct and tunnel destinations

Start with broad categories instead of an enormous rule list. Local network ranges, the router’s management address, private DNS names, printers, NAS devices, and local streaming or casting services should normally stay direct. The tunnel set can then contain the selected external domains or destination groups. A final direct rule is useful as a safety net, but the exact precedence depends on the core or policy-routing package.

• ✅ Keep local subnets and router management traffic outside the tunnel.
• ✅ Define the selected domain group before adding application-specific exceptions.
• ✅ Send DNS queries through the resolver path required by the routing design.
• ✅ Decide whether IPv6 should be routed through the tunnel or disabled consistently.
• ❌ Do not assume that a node label, domain name, and exit country are the same thing.
• ❌ Do not run two independent DHCP or DNS services on the same LAN.

DNS interception can help ensure that clients use the router’s resolver, but it should be introduced carefully. Some devices use encrypted DNS, hard-coded resolvers, or application-level name resolution. In those cases, a router rule based only on ordinary DNS requests may not be enough. Blocking or redirecting such traffic can also affect legitimate privacy settings and device functions. Test one client first, and make sure you know how to undo the change.

Decide between domain rules and device rules

Domain rules are useful when only certain services should use the tunnel across the whole household. Device rules are easier to understand when one television, tablet, or test computer needs a different path. Source-based rules can identify devices by IP address, DHCP reservation, MAC address, VLAN, or firewall zone, depending on your OpenWrt design.

A DHCP reservation is preferable to relying on a changing address. If the device receives a new address after a lease renewal, a source-based rule may silently stop applying or affect the wrong client. For a larger network, separate VLANs can provide cleaner boundaries: a normal LAN remains direct, while a designated media or testing VLAN follows the VPN policy. This takes more planning, but it avoids maintaining individual device rules indefinitely.

Configure the tunnel and test it in stages

The safest workflow is incremental. Do not import a large rule set, enable DNS interception, and switch the entire household at the same time. Install the required OpenWrt package or core, add one tunnel, and test the tunnel from the router itself. Then test one LAN client before adding smart-routing rules.

1. Check firmware and package compatibility. Confirm the OpenWrt release, hardware target, architecture, available storage, and package repository status. Avoid installing a package built for a different target.
2. Prepare the configuration. Use the provider’s official configuration source. If you use a subscription link, treat it as a credential and do not paste it into public converters, screenshots, or shared documents. For a manual profile, verify keys, certificates, server address, port, and protocol-specific options.
3. Create the tunnel or proxy inbound. Give the interface or listener a clear name. Keep the local proxy port restricted to the LAN unless remote access is deliberately required.
4. Set firewall zones and forwarding. Permit only the traffic needed between LAN, WAN, and the tunnel. Preserve access to the router’s management interface from the trusted local network.
5. Test a single destination. Check whether a selected domain follows the tunnel and whether an ordinary local or direct destination still uses WAN. Test from a client, not only from the router.
6. Add DNS and policy rules gradually. Introduce domain groups, source-device rules, and fallback behavior one change at a time. Record each change so it can be reversed.

For a WireGuard setup, pay attention to AllowedIPs. A value that represents all destinations can create a full-tunnel route, while a narrower value may leave some traffic direct. The correct choice depends on whether policy routing is being handled by WireGuard itself, by firewall marks, or by another package. When a proxy core is used, check the inbound and outbound definitions separately: the inbound accepts traffic from LAN clients, while the outbound selects the tunnel or direct connection.

Use the router’s status page and command-line tools to observe the actual path. Useful checks include the interface state, handshake status where applicable, route tables, firewall counters, DNS responses, and system logs. A successful handshake only proves that the tunnel endpoint can communicate. It does not prove that a client’s DNS query, TCP connection, UDP flow, or IPv6 request is following the intended policy.

# Examples for inspection; interface names vary by installation
ip addr
ip route
logread | tail
nslookup example.com

The commands above are inspection examples, not a universal configuration. Interface names, resolver addresses, and package-specific commands vary. Replace the domain with a destination you are authorized to test, and compare the result with a known direct destination. For privacy-sensitive checks, use the client’s browser or application as well as command-line tools, because some applications maintain their own connection pools or DNS behavior.

If a selected domain opens through the wrong path, inspect the order of rules first. A general direct rule placed before the selected tunnel rule will win. If the right domain routes correctly but its login, images, API, or media requests fail, the service may use additional domains or a content delivery network. Add only the required related domains after identifying them from the application’s documented behavior or controlled logs; avoid blindly routing every third-party domain through the tunnel.

Troubleshoot DNS, firewall, and client-side failures

When the router appears connected but clients cannot browse, separate the problem into layers. First check whether the client can reach the router. Next check whether the router can reach the upstream network. Then test the tunnel independently. Finally test the policy and DNS rules. This sequence prevents a DNS mistake from being mistaken for a protocol failure.

Common symptoms and focused fixes

The tunnel is down: verify the server address, credentials, keys, certificate chain, system time, and protocol support. A wrong clock can invalidate certificates or make authenticated connections fail. Confirm that the endpoint is reachable through the normal WAN path before changing routing rules.

The tunnel is up, but all traffic is direct: inspect the default route, policy priority, firewall marks, and source-device match. A proxy listener can be healthy while no client traffic is actually sent to it. Check whether the client is configured to use the router as its gateway and whether the selected rule uses a domain list that the resolver can recognize.

All traffic enters the tunnel unexpectedly: look for an overly broad AllowedIPs value, a full-tunnel policy, or a catch-all rule placed above the direct exceptions. Restore local-network exclusions first. Printer discovery, casting, router administration, and local file sharing often depend on direct access and multicast behavior that a simple proxy path does not carry.

Names resolve, but applications fail: check for DNS mismatch, IPv6 leakage, UDP limitations, MTU issues, and applications that use hard-coded or encrypted DNS. Some protocols and applications need UDP support that a TCP-only proxy path cannot provide. Do not change the MTU blindly; compare packet behavior and logs, then make the smallest targeted adjustment.

Only one device fails: inspect that device’s gateway, DNS settings, cached connections, and private address randomization. Mobile devices may switch between Wi-Fi and cellular networks, while televisions can retain stale DNS or application sessions. Disconnect and reconnect the client after a policy change, then repeat the test with a second device to determine whether the issue is local or router-wide.

IPv6 deserves a deliberate decision. If the WAN provides IPv6 but the VPN policy covers only IPv4, some applications may prefer IPv6 and bypass the intended route. You can configure IPv6 through the tunnel if the provider and core support it, or apply a consistent policy that prevents unhandled IPv6 traffic from escaping the design. Leaving IPv6 in an unknown state is less reliable than choosing and documenting one approach.

Maintain the setup without losing control

Once the first rules work, document the design. Record which interface or core provides the tunnel, which DNS service handles selected domains, which devices use source-based policies, and what the fallback behavior is when the tunnel is unavailable. A written map is especially valuable after an OpenWrt upgrade or package replacement.

Subscription updates should be treated as configuration changes, not as harmless text refreshes. A provider may add, remove, rename, or modify routes. Review the generated configuration before applying a major change, keep a known-good backup, and confirm that the update did not replace your local routing rules. Never expose the subscription URL in a public issue, browser history shared with others, or an untrusted conversion service.

Use the provider’s official client on Windows, macOS, Android, iOS, or Linux when router-wide routing is unnecessary. A local client is easier for a single user who needs application-specific rules, while OpenWrt is valuable when several devices must share one policy or when a device cannot install a compatible client. You can review the available setup options on the setup guide and compare supported routes on the global nodes page.

• ✅ Keep a backup of the working OpenWrt configuration before upgrades.
• ✅ Reserve addresses for devices that use source-based routing.
• ✅ Review subscription changes before applying them to the router.
• ✅ Test local access, direct internet access, selected tunnel destinations, and IPv6 separately.
• ❌ Do not expose the router administration interface or proxy listener to the public internet without a documented security design.
• ❌ Do not treat a successful connection indicator as proof that every rule is correct.

For households with changing requirements, start with a small rule set and expand it only when a real need appears. A short, understandable policy is easier to audit than a large collection of copied domain lists. If a service changes its domains, update the relevant group and test the affected application rather than rerouting the entire network.

Frequently asked questions

Can I import a subscription link directly into OpenWrt?

It depends on the installed core or management package. A subscription link is a configuration source, not a universal OpenWrt plugin. A client such as Clash Verge, sing-box, or Shadowrocket may support a particular format directly, while an OpenWrt package may require a compatible provider format, a generated configuration, or manual conversion. Confirm the expected format before importing anything, and keep the link private because it may contain account-linked access credentials.

Should I use the router or an official client?

Use the router when several devices need a shared policy, especially devices that cannot run a VPN client. Use an official Windows, macOS, Android, iOS, or Linux client when one user needs simple controls, application-level rules, or independent route selection. There is no need to force every device through the router if only one computer needs the tunnel.

Why can local devices stop working after enabling the VPN?

A full-tunnel route, firewall isolation, DNS changes, or an incorrectly ordered policy can affect local traffic. Check that private LAN ranges and the router’s management address use direct rules. Also verify that the client still receives the OpenWrt router as its gateway and that local discovery protocols are not being sent to a proxy that cannot carry them.

What should happen when the VPN route becomes unavailable?

Choose the fallback deliberately. A direct fallback preserves general connectivity but may send selected destinations over the normal WAN path. A fail-closed policy prevents those destinations from connecting until the tunnel returns, but it can look like an application outage. For most home networks, keep ordinary local and direct traffic available while deciding separately how sensitive or specifically selected destinations should behave.