ASIC Miner – VPN Interfering with Pool Connection
Informational — Monitor and address as needed
Symptoms
- Pool dashboard shows `Last share` drifting 3-11 minutes in a rolling pattern while the miner UI claims it is hashing
- Miner UI flips `Pool 0: Alive` ↔ `Pool 0: Dead` every few minutes with no hardware change
- `cgminer` / `bmminer` / `bosminer` / `luxminer` log shows repeated `stratum_recv timeout`, `Connection reset by peer`, or `pool X died` entries
- Effective (pool-side) hashrate trails local (dashboard) hashrate by 3-12% sustained
- Stale / rejected share ratio above 2% on pool side while local HW% remains normal (<1.5%)
- Problem started the day the VPN, a new kill-switch, or a DNS/DPI filter was enabled
- Ping from a LAN host to the pool hostname spikes 4-10× when the VPN is active
- `traceroute` from the miner shows the first hop going to the VPN endpoint instead of the ISP gateway
- VPN client log shows `re-keying`, `SIGUSR1`, `handshake timeout`, or `NAT rebind` events aligned with miner disconnects
- Browsing and streaming work fine on the same VPN, but the miner disconnects constantly
- Disabling the VPN on the router immediately clears the disconnect pattern
- Pool explicitly rejects your new egress IP (VPN exit node on an anti-abuse blocklist at F2Pool / AntPool / Foundry-class operators)
Step-by-Step Fix
Power-cycle the router, miner, and VPN endpoint in that order with a 30-second gap between each. Wait five minutes for stratum to re-establish, then observe the miner log for 15 minutes. Clears stale NAT entries, VPN session keys, and wedged client state from recent updates. If the disconnect pattern vanishes and stays gone for a full hour, the fault was a stuck state, not configuration. If it returns, continue to Step 2.
Verify the pool configuration URL and port in the miner UI exactly match what the pool publishes (e.g. `stratum+tcp://stratum.braiins.com:3333`, `stratum+tcp://stratum.ocean.xyz:3334`). Typos, stale ports, or leftover test pools produce the same intermittent-reconnect pattern as a VPN fault. Replace the URL, re-authorize the worker, and reboot the miner — many stock firmwares do not handle live URL edits cleanly.
Temporarily disable the VPN tunnel on the router (pause button, `systemctl stop openvpn@client`, or `wg-quick down wg0`) and let the miner run direct-to-pool for 30 minutes. If disconnects stop completely, VPN is confirmed as the cause — move to Tier 2. If they persist, the VPN was innocent and the real fault is upstream (ISP, cable, switch, control board).
Configure split-tunnel or policy-based routing on the router so the miner's MAC or static DHCP IP bypasses the VPN entirely. All modern router firmware (ASUS Merlin, GL.iNet, OpenWRT with `luci-app-mwan3`, pfSense, Unifi) supports this. Add the miner to the bypass list, save, reboot the router. This is the correct long-term fix — privacy VPN on browsers, clearnet on the miner.
Set a static DHCP reservation for the miner's MAC address in the router's DHCP settings. Without a reservation, the miner's IP will rotate every 24-72 hours and silently break any IP-based bypass rule. Reboot the miner and confirm it retained the reservation. Free, two-minute change, prevents the most common `I fixed it yesterday and it is broken again` return ticket.
Raise the VPN's MTU to 1420 (WireGuard — add `MTU = 1420` under `[Interface]` in `/etc/wireguard/wg0.conf` and restart) or set `mssfix 1400` / `fragment 1400` / `tun-mtu 1500` in OpenVPN. Re-run an MTU probe (`ping -M do -s 1400 <pool-ip>`) to confirm 1400-byte payloads now pass. Fragmentation blackholes are invisible without a probe and silently kill long-lived TCP — this is the single highest-leverage fix on the list.
Disable the VPN client's DNS override and configure the miner's DNS explicitly to `1.1.1.1` primary, `9.9.9.9` secondary. Settings live under Network → IP Config (Antminer), Network → Miner (Whatsminer), or Wi-Fi/LAN (AxeOS). Reboot the miner and confirm with `nslookup stratum.pool.com` that you get the clearnet answer, not the VPN's hijacked answer. Many privacy VPNs aggressively rewrite DNS for ad-blocking — fine for browsers, destructive for stratum.
Extend the router's NAT connection-tracking timeout. On OpenWRT / Linux: `sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=86400` and persist in `/etc/sysctl.conf`. On pfSense: System → Advanced → Firewall/NAT, set optimization to `Conservative` and TCP established to 86400s. Stock consumer routers often do not expose this — if yours does not, you cannot fix it, flash OpenWRT. Stratum's idle windows exceed default NAT reap thresholds routinely.
Exempt the miner from the VPN's kill-switch. In most clients this is an `excluded apps` or `excluded IPs` list — add the miner. For router-level kill-switches implemented via iptables, insert an `-s <miner-ip> -j ACCEPT` rule above the drop. For WireGuard kill-switches that work via `AllowedIPs = 0.0.0.0/0` wholesale route swap, use policy-based routing (Step 4) instead; exemption alone will not save you.
Switch the VPN exit node to a geographically closer region and re-measure latency (`ping <pool-ip>` from inside vs outside the tunnel). If the RTT delta exceeds 50ms, stale-share loss eats meaningful payout. Commercial providers (Mullvad, IVPN, ProtonVPN) expose city-level exits; a self-hosted VPS exit you control is better. Retest after the change — 20ms delta or less is the target.
Test with the pool's regional stratum endpoint closest to the VPN exit, not closest to home. Pools like Braiins, Ocean, Foundry publish `us-east`, `eu`, `asia` variants; pick the one near your exit. On smaller solo pools with a single endpoint (Public Pool, Solo CKPool), either accept the latency or remove the VPN from the mining path entirely via Step 4.
Replace the commercial VPN with a self-hosted WireGuard instance on a $5/month VPS near the pool (Hetzner, OVH, DigitalOcean). Install WireGuard with `apt install wireguard`, generate keys, write a minimal config, lock down with `ufw`, route only the miner's traffic through the tunnel. You control the exit IP (clean reputation), latency drops to 10-30ms, and the cost is roughly equal to a commercial sub. This is the Mining Hacker answer — own the exit, own the keys, no middleman logging your shares.
Cross-flash DCENT_OS — D-Central's open-source Antminer firmware — for real on-device network diagnostics: `tcpdump`, `traceroute`, explicit DNS control, Stratum v2 client, per-chip HW%. Alternatives: Braiins OS+, LuxOS, Vnish. All four expose a real shell; stock Bitmain busybox does not. You can confirm in 60 seconds whether submit packets are leaving the miner and whether the pool is acknowledging them — the single most diagnostic step in this whole procedure.
Configure a dedicated mining VLAN on a managed switch + VLAN-aware router. Tag the miner's switch port to VLAN 10, route VLAN 10 via the ISP gateway directly, firewall it from the rest of the LAN. Your privacy VPN continues to cover the default VLAN where laptops live. 20-minute setup on Unifi / pfSense / OpenWRT and the correct long-term architecture — mining is an appliance, network it like one.
Run a stratum proxy (`stratum-proxy`, CKPool in proxy mode, or a Stratum v2 translator) on a clearnet-connected host on your LAN. The miner talks to the local proxy; the proxy talks to the pool over clearnet. Decouples the VPN question entirely — the miner never touches the internet, the proxy does, and the proxy is trivially easy to exempt from the VPN. Bonus: smooths over transient ISP hiccups with faster reconnect logic than stock firmware.
Stop DIY when bypassing the VPN does not help AND `socket close` / `RST` entries persist AND a known-good miner on the same cable and switch does not exhibit the problem. You have isolated the fault to the control board — network ASIC, Ethernet PHY, or CPLD bridge. Book a D-Central ASIC Repair slot at `https://d-central.tech/services/asic-repair/`.
D-Central bench process for network-fault miners: controlled LAN test fixture, full-rate packet capture of miner egress, Ethernet PHY register-level sanity check, PHY or CPLD replacement if confirmed, firmware reflash with your exact pool configuration pre-loaded, 24-hour post-repair burn-in to a staging pool to verify stable stratum before the miner ships back.
Ship the control board only when possible (4-6 screws on most Antminers, 6 on Whatsminer) — anti-static bag, padded envelope, include a note listing your pool URL, firmware version, and the observed disconnect pattern. Saves diagnostic time and repair cost. Shipping the whole miner is supported but costs 4-6× more in freight. Canadian / US / international accepted.
When to Seek Professional Repair
If the steps above do not resolve the issue, or if you are not comfortable performing these repairs yourself, professional service is recommended. Attempting advanced repairs without proper equipment can cause further damage.
Related Error Codes
Still Having Issues?
Our team of Bitcoin Mining Hackers has been repairing ASIC miners since 2016. We have seen it all and fixed it all. Get a professional diagnosis.
