VPN Breaks Pool Stratum Handshake

Open your VPN client's settings and find the split-tunnel toggle. Exclude the miners' subnet (typically `192.168.1.0/24`, `192.168.0.0/24`, or `10.0.0.0/24`). Mullvad: Settings → Split Tunneling → Add IP Range. ProtonVPN: Settings → Split Tunneling → Custom Bypass. NordVPN desktop: Settings → Split Tunneling (app-level only — limited). Restart the VPN client. Verify with `curl ifconfig.me` from a miner-subnet device — should return your real ISP public IP, not the VPN exit IP.

Or take the VPN off your router entirely. Reset router config to factory or remove the VPN client / WireGuard config. Install the VPN per-device on the laptops, phones, tablets that actually need privacy. Miners go back to bare-LAN-to-internet routing. This works on every VPN provider, regardless of how garbage their split-tunnel implementation is.

Switch to a VPN that handles split-tunneling correctly. Mullvad and ProtonVPN are the gold standards (proper subnet exclusion). Windscribe's R.O.B.E.R.T. firewall-rule system also works. Avoid PIA, NordVPN, Surfshark, and ExpressVPN for router-level installs that need to coexist with mining traffic — their split-tunnel implementations are app-based on desktop only and unavailable on router firmware.

Restart every miner after changing VPN configuration. Stratum sockets are stateful — a miner that established its connection through the old broken path keeps trying to use that route until forced to renegotiate. Power-cycle (not soft reboot) or use the miner UI's `Restart cgminer` / `Restart bmminer` button. Bitaxe / NerdAxe: AxeOS UI → System → Restart.

Watch pool dashboard for 60 minutes minimum. Three numbers tell you if the fix took: accepted-share rate matching miner-UI hashrate within ±2%, worker uptime greater than 50 minutes, stale-share rate below 1%. If the worker disconnects more than once in 60 minutes, the fix didn't take — proceed to Tier 2.

On OpenWrt / ASUS Merlin / GL.iNet routers, configure policy-based routing. Create a routing rule: traffic from the miner subnet, regardless of destination, uses the WAN gateway (not the VPN gateway). On OpenWrt: Network → Routing → Static IPv4 Routes plus a custom mark in `firewall.user`. Search `[your router model] policy based routing exclude subnet` for brand-specific tutorials.

On OPNsense or pfSense, use gateway-based outbound NAT exclusion. Gateways → Single, then Firewall → Rules → LAN → Add with source = miner subnet, destination = any, gateway = WAN_GW (not VPN_GW). Save, apply changes, verify with `traceroute pool.example` from the miner subnet — first hop should be your router's WAN, not the VPN gateway.

WireGuard self-host: pin `AllowedIPs` to the destinations that actually need the tunnel. Default `AllowedIPs = 0.0.0.0/0` routes everything through WireGuard. Replace with explicit subnets — e.g. `AllowedIPs = 10.10.10.0/24, 192.168.50.0/24` (your remote networks). Mining subnet stays out. Now mining traffic goes direct, everything else still tunnels.

OpenVPN self-host: use `route-nopull` plus selective `route` directives. Add `route-nopull` to client config to ignore server-pushed routes, then add `route 10.10.10.0 255.255.255.0 vpn_gateway` for each subnet you actually want tunneled. Mining subnet stays on the WAN gateway by default. Restart OpenVPN client and verify routing table on miner-side device.

Verify the firewall isn't redirecting back into the tunnel. Some default firewall configs `MASQUERADE` all outbound traffic into the tunnel interface. Run `iptables -t nat -L -nv` on the router; any rule sending miner-subnet traffic to `tun0` or `wg0` defeats the routing changes. Remove those rules. On OPNsense/pfSense: Firewall → NAT → Outbound — set to Manual and remove the VPN entry for miner subnet.

Pin static routes for pool stratum endpoints on the miner itself. If firmware allows: `ip route add stratum.slushpool.com via 192.168.1.1 dev eth0` where `192.168.1.1` is your router's WAN-gateway IP. Surgical fix — even if the rest of the network tunnels, this connection escapes. Works on Bitaxe (AxeOS shell), Antminer (rooted SSH), Whatsminer (BTminer rooted SSH). Persists until reboot unless saved in startup script.

Set up a dedicated mining VLAN. Create VLAN 20 = `192.168.20.0/24` for miners on a managed switch + VLAN-capable router. Configure VLAN 20 to use a routing table without the VPN as default gateway. All miners get tagged onto VLAN 20. Bonus: mining traffic is now isolated from the rest of your home network for security as well as routing.

Implement DNS split-horizon for pool hostnames. Run a local DNS resolver (Pi-hole, AdGuard Home, dnsmasq, Unbound) and force pool hostnames to resolve through your ISP's resolver, not the VPN's. Prevents DNS leak issues that show up as `mining.subscribe` failing on a hostname that resolves correctly outside the tunnel and incorrectly inside it.

Tune TCP keepalive on the miner if firmware exposes the kernel sysctls: `echo 60 > /proc/sys/net/ipv4/tcp_keepalive_time`, `echo 30 > /proc/sys/net/ipv4/tcp_keepalive_intvl`, `echo 5 > /proc/sys/net/ipv4/tcp_keepalive_probes`. Persists only until reboot unless patched into firmware init scripts. Keeps stratum socket warm enough to survive NAT eviction on the VPN exit-node gateway.

Move the miners to a separate ISP connection — second cable modem, Starlink, LTE failover, any second uplink that bypasses the VPN entirely. Mining lives there; your privacy stack lives on the primary uplink. Cost is a second internet bill, but for a serious home-mining operation the redundancy alone justifies it. Configure failover so a primary-uplink outage doesn't kill mining either.

Stop solo-debugging. You've completed split-tunnel, A/B tested, added static routes, and the pool still shows reconnect storms. You're now chasing one of: (a) ISP-level CGNAT interaction with the pool, (b) a pool reputation block on your residential IP, or (c) a deeper firmware bug in the miner's stratum implementation. None of those are VPN problems anymore — you've solved the VPN problem and uncovered something else. Open a D-Central support ticket.

What D-Central does on a remote support session: tail miner stratum log live, packet-capture from LAN side, traceroute miner→pool with VPN on/off, validate routing tables, validate firewall rules, validate firmware version, recommend either a firmware change (DCENT_OS on Antminer, AxeOS update on Bitaxe, BTminer rebuild on Whatsminer) or an ISP-level escalation. Typical ticket closure: one business day.

Document for the support ticket. Provide: VPN provider + version + install location (router/desktop/per-app), miner model + firmware version, pool URL + port + protocol (stratum / stratum+tcp / stratum+ssl / stratum_v2), `mtr` output with VPN on AND off, miner log excerpt covering one reconnect cycle, and `curl ifconfig.me` output from the miner subnet (proving the split-tunnel did or didn't take effect). With those six things D-Central can usually root-cause within one back-and-forth.