NordVPN Split-Tunnel — Design & Diagnosis

NordVPN Split-Tunnel on the Main Box

Documented 2026-07-19 after a “why does whatismyipaddress show my real Cox IP while nordvpn says Connected?!” investigation. Answer: nothing is broken — the box runs a deliberate split-tunnel, and every confusing symptom is that design working.

The design (intentional, confirmed 2026-07-19)

Goal: privacy for torrenting. Everything else is convenience.

Layer Config Effect
Tunnel NordLynx (WireGuard), normally a US server default route for all traffic → VPN
Allowlist (~80 subnets) Cloudflare’s entire published CIDR set (104.16/13, 172.64/13, 162.158/15, 198.41.128/17, …) + pinned /32 CloudFront & Akamai edges CDN-fronted websites bypass the tunnel (real Cox IP). Added to make Credit Karma load / kill CDN captcha-hell.
qBittorrent Session\Interface=nordlynx (bound to the VPN interface) Torrents are tunnel-or-nothing — if the VPN drops, torrents STOP; they can never leak out Cox. Stronger than a kill switch, scoped to exactly what needs it.
Kill Switch disabled (deliberate) On tunnel flaps, general traffic falls back to Cox so the trading/automation crons stay alive. Torrent privacy is covered by the interface binding instead.
Rotation cron 0 */12 auto-change-vpn.sh: kill qbittorrent → nordvpn c united_states → restart qbittorrent fresh server + clean torrent session every 12h
DNS Nord’s resolvers (103.86.96.100/99.100) via the tunnel; Nord intercepts ALL port-53 while connected (queries to any resolver IP get answered) DNS never goes to Cox. Side effect: when the tunnel blips, DNS dies all at once → the 5:40 domain-monitor false alarm (now guarded — see the bwscomputerservice page).

Net effect: torrents + non-CDN traffic exit via Nord; CDN-fronted browsing (a big slice of the web) and LAN traffic use the real Cox IP. This is “torrent privacy,” not “hide my IP from websites” privacy — a known, accepted tradeoff.

How it’s implemented (for future debugging)

nordvpn settings → “Allowlisted subnets” is the source of truth. Each entry becomes an ip rule … lookup main (bypass); rule ~32765 sends everything else (not fwmark 0xe1f1) to table 205, whose only route is default dev nordlynx. See them: ip rule show and ip route show table 205.

Why the “leak tests” disagree (they’re both right)

  • whatismyipaddress.com shows Cox → that site is behind Cloudflare → allowlisted → bypasses the tunnel. Expected, not a leak.
  • dnsleaktest.com shows NordVPN/PacketHub (VPN city) → DNS + non-CDN traffic really do tunnel. (PacketHub S.A. = Nord’s IP supplier.)
  • Real verification: curl -s ifconfig.me → should be a Nord egress IP, and nordvpn status → Connected. For torrents specifically: qBittorrent stalls to 0 peers if the tunnel is down (binding proof).
  • traceroute to any Cloudflare-fronted site (incl. bwscomputerservice.com) shows the raw Cox path (10.0.0.1 → Cox → Cloudflare edge) — again by design.
  • The nordlynx interface’s 100.x address is Nord’s internal CGNAT, not a LAN device.
  • nordvpn status “IP” (server inbound) and the observed egress IP can differ — both Nord.

Known quirks / open items

  1. Stale /32 pins: the hand-pinned CloudFront/Akamai /32s were resolved once and CDN IPs rotate — e.g. Robinhood’s API now resolves to CloudFront ranges (3.175.x, 18.64.x) NOT in the allowlist, so bot RH traffic currently rides the VPN (foreign IP when on Canada; US server normally). Possible contributor to RH token/security churn (~5-day expiry pain). If tightening is ever wanted: allowlist RH’s current ranges with a periodic refresh, not one-time pins.
  2. VPN blips silently drop the box to bare Cox for everything except torrents (binding) — the 2026-07-19 overnight blip broke 1.1.1.1 DNS at 5:40 and false-alarmed the domain monitor (guard added same day).
  3. A VM NAT’d through this host (vmnet8) inherits the same split-tunnel — using the Windows VM does not change the privacy posture.