VPN-at-the-edge patterns, kill-switch firewall rules, per-host policy routing, DNS leak prevention

Section	Topic
1	About this Volume
2	The Three VPN Families — When Each Wins
3	WireGuard — The Default Setup
· 3.1	Through the Admin Panel
· 3.2	The UCI underneath
· 3.3	Verifying the tunnel
· 3.4	Throughput
4	OpenVPN — When WireGuard is Blocked
· 4.1	Setup
· 4.2	OpenVPN’s UCI
· 4.3	Caveats
5	Tor — The Paranoid Mode
6	The Kill-Switch — What and Why
· 6.1	Implementation
· 6.2	Verifying the kill-switch
· 6.3	Per-host bypass (selective routing)
7	DNS Leaks
· 7.1	Why it happens
· 7.2	The fix
· 7.3	The DoH-over-VPN belt-and-braces approach
8	Provider-Side Considerations
9	Cheatsheet Updates
10	Footnotes & References

1. About this Volume

Three VPN families in the GL-iNet build, each appropriate for different threat models: WireGuard (the everyday default), OpenVPN (legacy compat / odd-network bypass), Tor (when “this venue is hostile, route through the Tor network”).

Plus the kill-switch firewall rules that prevent traffic-leak when the tunnel drops — without these, a momentary VPN disconnect lets every device on your kit talk directly to the venue’s network.

Reads:

Vol 5 §5 — the nftables/fw4 firewall layer the kill-switch lives in.
Vol 5 §7 — the DNS layer that’s the most common leak vector.

Feeds:

Vol 11 §3 — the daily ops checklist that includes “kill-switch verified” as a step.

2. The Three VPN Families — When Each Wins

	WireGuard	OpenVPN	Tor
Performance on this hardware	~600–900 Mbps tunnel throughput	~150–250 Mbps	~20–40 Mbps (network-limited)
Setup time	Paste config, click Connect	Paste `.ovpn`, click Connect	Toggle a switch
Latency overhead	~1–3 ms	~5–15 ms	~200–800 ms (multi-hop circuit)
Resistance to firewall blocking	Moderate (UDP, fixed port — easy to block)	High (TCP/443, looks like HTTPS)	Highest (with bridges + obfs4)
Privacy from the VPN provider	Provider sees endpoint pairs	Provider sees endpoint pairs	Tor: traffic traverses 3 nodes, no single party sees both ends
When to use	Default; everything else fails open from this	When WireGuard is blocked; when an old commercial provider is ovpn-only	When the threat model includes the VPN provider itself

For tjscientist’s travel kit: WireGuard 95% of the time, OpenVPN as backup, Tor for specific paranoid moments (researching something hostile, in a country with intrusive surveillance).

3. WireGuard — The Default Setup

3.1 Through the Admin Panel

Admin Panel → VPN → WireGuard Client → Add Profile.

Paste the WireGuard config (the standard [Interface]/[Peer] .conf text):

[Interface]
PrivateKey = <your private key>
Address = 10.66.x.y/32
DNS = 10.66.x.1

[Peer]
PublicKey = <provider's public key>
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = <provider host>:51820
PersistentKeepalive = 25

Set “Connect on boot” if you want the tunnel auto-connecting.
Click Connect.

The Admin Panel auto-creates the wg0 interface, adds it to the wan zone with masquerade, sets up the firewall.

3.2 The UCI underneath

# /etc/config/network
config interface 'wgclient'
    option proto 'wireguard'
    option private_key '...'
    list addresses '10.66.x.y/32'
    option dns '10.66.x.1'
    option mtu '1420'

config wireguard_wgclient
    option public_key '...'
    list allowed_ips '0.0.0.0/0'
    list allowed_ips '::/0'
    option endpoint_host 'provider.example'
    option endpoint_port '51820'
    option persistent_keepalive '25'

# /etc/config/firewall (zone for VPN)
config zone
    option name 'vpn'
    option network 'wgclient'
    option masq '1'
    option output 'ACCEPT'
    option input 'REJECT'
    option forward 'REJECT'

# Forwarding rule: LAN → VPN (replaces LAN → WAN when active)
config forwarding
    option src 'lan'
    option dest 'vpn'

3.3 Verifying the tunnel

wg show                                # interface status, last handshake, bytes
ip route show table all | grep wg
ip route get 8.8.8.8                   # should show wgclient as the device
curl -4 ifconfig.me                    # public IP — should be the VPN endpoint

If wg show reports zero handshakes, WireGuard isn’t connecting. Common causes:

WireGuard’s UDP port blocked by the venue firewall (try OpenVPN-over-443 fallback, §4).
Wrong endpoint hostname / DNS resolution failing.
Wrong private key (re-paste; don’t trust copy-paste truncation).
Time/clock skew (rare on this hardware; NTP usually keeps it in sync).

3.4 Throughput

Real-world WireGuard throughput on the BE3600 lands roughly at:

Test	Throughput
LAN → WAN, no VPN	~2.0 Gbps (NAT’d, HW offload)
LAN → WireGuard server in same DC	~700–900 Mbps
LAN → WireGuard endpoint at typical commercial VPN	~400–700 Mbps (varies with routing distance)
LAN → OpenVPN UDP	~200 Mbps
LAN → OpenVPN TCP	~120–180 Mbps

The crypto accelerator on the MT7986 Vol 2 §2.1 is what makes the 700–900 Mbps WireGuard number happen — a cheaper SoC without offload would land much lower.

4. OpenVPN — When WireGuard is Blocked

Some venue firewalls block UDP entirely or block the typical WireGuard ports (51820). OpenVPN over TCP/443 looks like HTTPS to a stateless firewall.

4.1 Setup

Same Admin Panel flow: VPN → OpenVPN Client → Add → Upload .ovpn. Most commercial providers ship .ovpn files; pick one configured for proto tcp and port 443.

4.2 OpenVPN’s UCI

# /etc/config/openvpn
config openvpn 'client'
    option enabled '1'
    option client '1'
    option dev 'tun'
    option proto 'tcp-client'
    option remote 'provider.example 443'
    option resolv_retry 'infinite'
    option nobind '1'
    option persist_key '1'
    option persist_tun '1'
    option ca '/etc/openvpn/ca.crt'
    option cert '/etc/openvpn/client.crt'
    option key '/etc/openvpn/client.key'
    option remote_cert_tls 'server'
    option cipher 'AES-256-GCM'
    option auth 'SHA256'
    option verb '3'

4.3 Caveats

Throughput is meaningfully lower than WireGuard — OpenVPN is single-threaded, kernel-userspace bouncing, no hardware crypto path on this SoC. Plan ~150–250 Mbps.
TCP-over-TCP (OpenVPN-TCP carrying TCP traffic inside) has bufferbloat issues. Set the MTU to 1300 in the config and, if you can, prefer UDP mode unless TCP is actually required.

5. Tor — The Paranoid Mode

The GL-iNet build ships tor in the package feed; install if not present:

opkg install tor tor-geoipdb

Configure to listen on a SOCKS port and (optionally) a transparent-proxy port:

# /etc/tor/torrc
SocksPort 0.0.0.0:9050           # SOCKS5 on all interfaces (firewall this!)
TransPort 0.0.0.0:9040            # Transparent TCP proxy (for the all-traffic-via-tor mode)
DNSPort 0.0.0.0:9053              # DNS over Tor

# If the venue blocks Tor exits, use bridges:
# UseBridges 1
# Bridge obfs4 <bridge-line-from-bridges.torproject.org>

The “everything via Tor” mode involves redirecting all forwarded traffic to TransPort via firewall rules — see the OpenWrt Tor wiki for the recipe. Don’t enable this without understanding that DNS over Tor is non-trivial to do correctly; mistakes here leak DNS to the venue resolver.

For most travel paranoia, a Tor browser on the laptop is enough — it gets you Tor for the threat-model-specific browsing without complicating the rest of the kit’s traffic.

6. The Kill-Switch — What and Why

Without a kill-switch, here’s what happens when the VPN drops:

WireGuard wg0 interface goes down (handshake timeout, network change, etc.).
Default route through wg0 becomes invalid.
Linux falls back to the default route through the WAN interface.
Every device on your LAN is now talking directly to the venue’s gateway, without VPN.
Until you (or auto-reconnect) brings the tunnel back up, your traffic is in the clear.

The kill-switch is firewall rules that drop forwarded traffic when the VPN interface is down — preventing the leak.

6.1 Implementation

# /etc/config/firewall — additions

# Zone for the VPN already exists from the WireGuard setup (§3.2).
# The kill-switch is a forwarding rule that's only active when 'wgclient' is up.

config rule 'vpn_killswitch'
    option name 'Kill-switch — drop LAN→WAN if VPN down'
    option src 'lan'
    option dest 'wan'
    option target 'REJECT'
    option enabled '1'

config rule 'vpn_allow'
    option name 'Allow LAN→VPN'
    option src 'lan'
    option dest 'vpn'
    option target 'ACCEPT'
    option enabled '1'

The killer is: by default, lan → wan forwarding is ACCEPT (this is what makes the router work as a router). The kill-switch makes it REJECT, and adds an explicit lan → vpn ACCEPT. So when wgclient is up, traffic gets a route through vpn and is forwarded; when it’s down, traffic has no lan → wan rule that lets it through.

6.2 Verifying the kill-switch

# Bring the VPN down deliberately (testing only):
ip link set dev wgclient down

# From a LAN client, try to reach the internet:
curl -4 -m 5 ifconfig.me
# Should fail (timeout or "No route to host"), not return anything

# Bring it back:
ip link set dev wgclient up
ifup wgclient

If curl succeeds while wgclient is down, the kill-switch isn’t active. Common reasons:

Forwarding rule lan → wan still has target ACCEPT somewhere (check /etc/config/firewall for duplicate rules).
The rule says REJECT but applies to a non-matching zone.

Check nft list ruleset | grep -A3 forward to see the actual forward chain.

6.3 Per-host bypass (selective routing)

Sometimes you want one device (printer, smart TV, kid’s phone) to bypass the VPN. Two approaches:

Static route in /etc/config/firewall.user:

nft add rule inet fw4 forward ip saddr 192.168.8.50 oifname "wan" accept

Mwan3 policy that selects WAN-only for a specific source IP — see Vol 5 §6.

The mwan3 path is cleaner if you have multiple WANs already configured.

7. DNS Leaks

The single most common VPN-config mistake. Symptoms: VPN is up, traffic is tunneled, but DNS queries go through the venue’s resolver — meaning the venue can see what hosts you’re querying even if it can’t see the contents.

7.1 Why it happens

dnsmasq on the router forwards DNS to whoever the WAN-side DHCP gave it. When WireGuard comes up, it pushes its own DNS server in the config — but unless dnsmasq is reconfigured to use it, the WAN-side resolver wins.

7.2 The fix

In the WireGuard [Interface] section:

DNS = 10.66.x.1                    # provider's resolver

The Admin Panel’s WireGuard setup parses this and writes a UCI override that points dnsmasq to the in-tunnel resolver. Verify:

# Watch DNS queries on the WAN side:
ssh [email protected] 'tcpdump -i wan -n port 53'
# Trigger a DNS query from a LAN client.
# Expected: nothing (the query goes through the tunnel, not WAN).
# If you see queries on WAN, you have a leak.

7.3 The DoH-over-VPN belt-and-braces approach

For maximum DNS leak prevention:

WireGuard tunnel up.
Configure dnsmasq to forward only to 127.0.0.1#5053.
Run https-dns-proxy on 127.0.0.1#5053 pointing at Cloudflare DoH or similar.
WireGuard’s AllowedIPs = 0.0.0.0/0, ::/0 means all traffic — including the DoH outbound TCP/443 — goes through the tunnel.

End result: DNS queries leave the device encrypted-DNS, ride the WireGuard tunnel to the provider, and the venue sees only encrypted UDP to the WireGuard endpoint.

8. Provider-Side Considerations

The router does the right thing if the VPN provider does. Things to check on the provider side:

Does the provider support WireGuard? Mullvad, IVPN, AzireVPN, ProtonVPN do. Older providers may be OpenVPN-only.
Does the provider rotate keys? Mullvad lets you generate keys yourself, no email/account binding. This matters if your threat model includes the provider itself.
Does the provider log connections? Most claim no-logs; a few have been audited (Mullvad, ProtonVPN). Trust is provider-specific and outside this volume’s scope.
Multi-hop? Some providers offer a built-in two-hop option (e.g., Mullvad’s Multihop). This is valuable when you don’t want any single provider node to see both your real IP and your destination — though it halves throughput.

9. Cheatsheet Updates

Inputs to Vol 12:

WireGuard for everything, OpenVPN-over-TCP-443 as fallback, Tor for paranoia.
Kill-switch is lan → wan REJECT + lan → vpn ACCEPT. Verify by bringing wgclient down and trying to reach the internet.
DNS-leak fix: DNS = line in the WireGuard config; verify with tcpdump -i wan port 53.
WireGuard real throughput: ~700–900 Mbps with provider in same metro; ~400–700 Mbps for typical commercial provider.
OpenVPN throughput: 150–250 Mbps. Always slower; the BE3600 has crypto offload only for WireGuard’s primitives.
Tor is for paranoia, not throughput. ~20–40 Mbps and high latency by design.

10. Footnotes & References

GL-iNet GL-BE3600 Volume 7 — VPN Workflows: WireGuard, OpenVPN, Tor, Kill-Switch, Policy Routing

Contents