Import Routes on Keenetic from .bat File

Keenetic can upload a file in Windows route ADD format and apply all routes to a selected interface automatically. NetRoute Pro generates exactly that file — you just download and upload.

(config)> ip route <CIDR> <VPN_IF>

(config)> ip route 1.1.1.0/24 Wireguard0

route ADD 1.1.1.0 MASK 255.255.255.0 0.0.0.0

Prerequisites

• Keenetic router with a configured VPN tunnel (WireGuard, OpenVPN, IKEv2, OpenConnect, etc.)
• NetRoute Pro Chrome extension installed
• Access to the router's web UI (usually http://my.keenetic.net)

Step 1. Generate a .bat file in NetRoute Pro

1. Open the target website in Chrome
2. Click the NetRoute Pro icon in your extensions
3. Select the Windows platform — that's the format Keenetic accepts
4. Gateway can be any value (e.g. 0.0.0.0) — Keenetic ignores it when you bind to an interface on upload
5. Choose aggregation mask (recommended /24)
6. Click Analyze Website
7. Download the result as a .bat file

Step 2. Open the Routing section in Keenetic

1. Open http://my.keenetic.net or the router's IP
2. Sign in as administrator
3. Go to Management → Routing
4. Select the IPv4 routes tab

Step 3. Upload the file with VPN interface binding

1. Click the Upload button
2. Select the downloaded .bat file
3. In the Interface dropdown, select your VPN tunnel
   • The interface name depends on your setup and VPN provider — it's different for each user
   • If unsure — check which interface your VPN uses in the Internet section
4. Confirm the upload

Done — all routes from the file are added and bound to the selected VPN interface. Keenetic ignores the gateway values from the .bat file; traffic flows through the chosen interface.

Alternative for WireGuard: AllowedIPs

If you're using WireGuard, you can skip static routes entirely and set subnets directly in the peer's AllowedIPs:

1. In NetRoute Pro, select the WireGuard platform
2. Copy the AllowedIPs line
3. In Keenetic: Internet → WireGuard → peer settings → paste into Allowed IPs
4. Save

DNS leak — required reading

Static routes on Keenetic forward traffic by IP. They do not route DNS. A LAN client still asks Keenetic’s DNS proxy (which by default forwards to your ISP) for example.com first — only the resulting IP traffic goes through the VPN. The ISP sees which sites are visited even though the data is encrypted.

Three options, by threat model:

1. Hide DNS from ISP fully. In Internet → Other connections → your VPN interface, mark it as the priority connection for DNS, OR set static DNS servers in Network rules → Internet safety pointing at your VPN provider’s internal resolver (e.g. 10.0.0.1). Keenetic will route DNS queries through the tunnel.
2. Reduce ISP visibility (public DoH/DoT). Keenetic supports DoH/DoT natively in Network rules → Internet safety → DNS-over-HTTPS / DNS-over-TLS. Add Cloudflare (1.1.1.1), AdGuard (94.140.14.140), or Quad9 (9.9.9.9) as the system resolver.
3. Accept the leak. Default behaviour — only the data path is encrypted, lookups stay with your ISP.

Verify from a LAN client at dnsleaktest.com — the resolver shown should belong to your VPN or chosen DoH, not your ISP. On Keenetic itself, check active DNS servers under System dashboard → DNS.

IPv6 dual-stack bypass

Static IPv4 routes cover IPv4 traffic only. If a destination has an AAAA record (most popular sites do), LAN clients prefer IPv6 (RFC 6724) and the request goes via your ISP’s IPv6 default route — bypassing the VPN.

Two fixes on Keenetic:

• Generate IPv6 routes in NetRoute Pro if your VPN has an IPv6 endpoint — same flow, different prefixes (2606:4700::/32, 2001:4860::/32, etc). Import as a separate .bat with the same VPN-interface binding.
• Disable IPv6 globally in Internet → Connections → IPv6 if your VPN doesn’t support v6. All traffic falls back to v4 and gets tunneled correctly.

Verify

After import, check that routes applied: they appear in Routing → IPv4 routes list bound to your VPN interface. But that only confirms the route was added — not that traffic actually flows through the VPN. Three real verification steps from a LAN client:

1. Check exit IP for a routed domain — the IP you see should belong to your VPN provider, not your ISP:

   curl -v https://example.com 2>&1 | grep "Connected to"
   # Should show an IP within one of your routed CIDRs.

2. Check what the wider internet sees as your IP for a routed site:

   curl -s https://api.ipify.org
   # When the routed CIDR includes ipify or you test through a proxy at the VPN
   # exit, this reflects the VPN exit IP. Compare with your real ISP IP.

3. On the router itself (CLI via SSH/Telnet):

   show ip route                  # confirm CIDRs bound to VPN_IF
   show interface stat <VPN_IF>   # RX/TX bytes should grow as the LAN client browses

tracert/traceroute are unreliable for this verification: ICMP/UDP probes are commonly filtered, returning * * * on every hop and giving you no useful signal.

Common issues

Website IP changed — route stopped working

CDNs like Cloudflare and Fastly rotate IPs periodically. Regenerate the .bat in NetRoute Pro with RIPE BGP optimization enabled — it substitutes announced BGP prefixes that cover all provider IPs.

Too many routes

Keenetic handles hundreds of static routes without issues. If you need more — use the WireGuard AllowedIPs approach.

Route added but traffic doesn't go through VPN

• VPN interface up? Check in Internet → Connections — the VPN row should show Connected with a non-zero uptime.
• SNAT for LAN traffic? Open Internet → Other connections, select your VPN interface, and ensure “Use for accessing the Internet” is enabled. This is what makes Keenetic NAT LAN-client traffic out via the VPN. Without it, packets reach the VPN exit but the VPN server sees them with internal LAN source IPs and silently drops them.
• Don’t enable a separate masquerade rule for commercial VPN providers (Mullvad, ProtonVPN, IVPN, etc.). The provider’s server already SNATs your traffic to its own exit IP — an extra masquerade on the client side does nothing useful and can break asymmetric flows. Only enable masquerade if you’re running your own VPN server that doesn’t SNAT.
• Check firewall rules — nothing in Network rules → Firewall should explicitly drop traffic to your routed CIDRs.

For advanced users: CLI

To automate or manage routes programmatically, connect via SSH/Telnet and use ip route commands in config mode. But for most cases, .bat upload is enough.

Example Configuration File

Ready-to-edit template with inline comments. Replace the example routes with output from NetRoute Pro for your target sites.

• keenetic-routes.bat — Windows route ADD format ready for Keenetic upload

@echo off
REM Example .bat file for upload to Keenetic router.
REM Generated by NetRoute Pro: https://alexander2k.github.io/netroute-site/
REM
REM Format: route ADD <network> MASK <netmask> <gateway>
REM Gateway can be 0.0.0.0 — Keenetic ignores it when you bind to an interface on upload.
REM Replace these example routes with output from NetRoute Pro for your target sites.

route ADD 1.1.1.0 MASK 255.255.255.0 0.0.0.0
route ADD 8.8.8.0 MASK 255.255.255.0 0.0.0.0
route ADD 162.159.0.0 MASK 255.255.0.0 0.0.0.0

REM Upload via Keenetic web UI:
REM   System -> Routing -> Upload .bat -> select VPN interface -> confirm.

Tip: Need a config without these comment lines? In NetRoute Pro options, uncheck “Include comments in exported files” — the extension will export only the route commands. Useful for routers that don’t tolerate comment lines.

View all example configs on GitHub →

Official Documentation

• Keenetic Help Center
• Keenetic: Routing (official)
• Keenetic CLI Reference

Related Guides

• MikroTik — RouterOS .rsc script import
• WireGuard — split tunneling with AllowedIPs
• Linux — ip route via shell script
• OpenVPN — client config route directives