Bitaxe – WiFi AP Client Isolation Blocking Device Access

Confirm the Bitaxe is genuinely on the network and the failure is network-blocking, not miner-side. Read the OLED: hashrate non-zero, IP shown, pool/worker visible. Cross-check at the pool dashboard for a share submitted in the last 10 minutes. Open the router admin DHCP table and confirm the MAC + IP. If all three confirm, the miner is healthy — every fix below is on the WiFi/router side. If the OLED is showing a fault or zero hashrate, back out to the Bitaxe Not Hashing page; AP isolation is not your problem.

Try a wired client first. Plug a laptop directly into the router with an ethernet cable, get a DHCP lease, and load `http://<bitaxe-ip>/` in a browser. If the wired client reaches AxeOS and a wireless client on the same SSID does not, AP isolation on that SSID is the diagnosis with very high confidence. This single test takes 60 seconds and isolates 'WiFi feature blocking' from 'router routing / firewall / VLAN' problems.

Try a different SSID. Most home routers broadcast 2-4 SSIDs (main, guest, IoT, sometimes a separate 5 GHz). Move your laptop or phone onto the **main / trusted** SSID and retry the dashboard URL. If it works on the main SSID and fails on guest, AP isolation is enabled on the guest SSID by factory default — that's the entire root cause. The fix is to either disable isolation or move the Bitaxe (more on that in steps 5 and 7).

Locate the AP isolation toggle in your router admin. Log in (typically `http://192.168.1.1/` or `http://192.168.0.1/`), navigate to Wireless / WiFi / SSID settings, find the SSID the Bitaxe is using, and look for any of: `AP Isolation`, `Client Isolation`, `Wireless Isolation`, `Guest Network Isolation`, `Block intra-network traffic`, `Allow guests to see each other and access my local network` (inverted), `Layer 2 Isolation`, or `Wireless separation`. Vendor naming varies — TP-Link / ASUS / Netgear / D-Link / UniFi / Eero / Google Home all use slightly different terms for the same toggle.

Disable AP isolation on the Bitaxe's SSID. If you own the router and the SSID is yours, flip the toggle off, save / apply, and wait 30-60 seconds for the AP to reload its config. Reconnect the wireless client (laptop or phone) to the SSID and retry `http://<bitaxe-ip>/`. This is a 30-second fix on most home routers and resolves the issue completely. Document the change in your home-network notes — factory resets and firmware updates can re-enable it without warning.

If the Bitaxe is on a Guest SSID by deliberate choice (e.g. you wanted to keep mining traffic separate from your main LAN for security), think about whether the trade-off is worth it. AP isolation does not provide any meaningful security against the Bitaxe — the miner only talks outbound to a public stratum pool and never accepts inbound connections from the internet. The only thing isolation breaks is *your* ability to manage it. Better pattern: dedicated IoT SSID with isolation OFF, or main LAN with a DHCP reservation. See step 7.

Set up a dedicated IoT / mining SSID on your router. Most modern home routers (UniFi, ASUS, TP-Link, Eero Pro, Google Wifi, Netgear Orbi) support multiple SSIDs. Create one named `iot` or `mining`, place it on its own VLAN if your router supports it, and explicitly set AP Isolation to OFF on that SSID. Move the Bitaxe and any other ESP32-based miners onto it. You get the security separation from your laptops / phones, plus full visibility from a designated admin device that joins the same SSID when you need to manage the Bitaxes.

Add a DHCP reservation in your router so the Bitaxe always gets the same IP. Find the Bitaxe's MAC address (OLED, board silkscreen, or DHCP leases table) and bind it to a fixed IP like `192.168.10.42`. Bookmark `http://192.168.10.42/` on every device you use to manage the miner. This is the cleanest long-term setup: no `bitaxe.local` / mDNS dependence, no IP changes after lease expiry or router reboot, and no surprise when factory resets re-enable AP isolation.

Use the wired LAN side instead of WiFi if you can. The Bitaxe Hex (and many DIY Bitaxe builds with USB-to-ethernet adapters) can sit on a wired ethernet drop. Wired clients on a router are not subject to the AP isolation toggle — that feature is wireless-side only. If your laptop is wired and the Bitaxe is wired (or one of the two), you bypass the entire AP-isolation problem without touching the WiFi config. For Bitaxes on WiFi only, simply manage them from a wired admin laptop.

Plug in a small travel router as a WiFi-to-WiFi bridge for hotel, conference, or co-working WiFi. A pocket router (`GL.iNet GL-MT300N-V2` Mango, `GL-AR300M`, `GL-AXT1800` Slate AX, etc., $35-$120 CAD) joins the upstream WiFi as a client and broadcasts its own private SSID downstream. The Bitaxe and your laptop both join the private SSID — full LAN visibility, no AP isolation, your own DHCP space. This is the only way to run a Bitaxe at a hotel, dorm, or convention without admin access to the venue's router.

On enterprise / business WiFi (corporate office, university, large venue), AP isolation is usually enforced at the controller level (Cisco Meraki, Aruba, UniFi Network controller) and you cannot toggle it as a regular user. Don't try to fight it. Either: (a) ask IT to put your specific MAC pair on a non-isolated VLAN, (b) use the travel-router approach in step 10, or (c) move the miner home where you control the network. Enterprise IT will, correctly, refuse to disable client isolation across the whole guest WLAN for one mining device.

Set up an mDNS reflector / proxy on your router if your topology requires AP isolation between most clients but a designated admin client must reach the Bitaxe. UniFi: Settings → Networks → toggle `mDNS` per network and put both the Bitaxe SSID and the admin SSID into the reflector group. pfSense / OPNsense: install the `Avahi` package and configure the SSID interfaces. OpenWrt: enable `enable-reflector` in `/etc/avahi/avahi-daemon.conf`. The reflector clones multicast announcements across the L3 boundary so `bitaxe.local` resolves even when clients are on different segments.

Phone hotspot / tethering: phone hotspots almost always have AP isolation hard-enabled (Apple iOS, Android One, most carrier APN profiles). The Bitaxe will join, get an IP, hash to the pool, but you will never reach the dashboard from a laptop on the same hotspot. If the laptop is also tethered and you only need pool stats, use the pool dashboard or a phone-based monitoring app instead of AxeOS. For full local management, you need a real router downstream of the hotspot — a travel router (step 10) accepts the hotspot upstream and provides a private LAN to both your laptop and Bitaxe.

Verify the fix worked end-to-end. From the wireless client that previously failed: `ping <bitaxe-ip>` should reply in 5-50 ms with 0% loss; `http://<bitaxe-ip>/` should load AxeOS within 1-3 seconds; `http://bitaxe-<mac>.local/` should resolve if your client supports mDNS (Bonjour on Windows, Avahi on Linux, native on macOS / iOS / modern Android). If `ping` works but HTTP doesn't, you have a different problem (firewall, blocked port, AxeOS UI hung) — see the Bitaxe AxeOS Dashboard Unreachable page.

Document the network state for future you. In a notes file or password manager: SSID name, AP isolation state (ON/OFF), VLAN ID if applicable, Bitaxe MAC, reserved IP, AxeOS firmware version, router make/model and admin URL. The next firmware update or router reset will re-enable AP isolation on factory-default SSIDs without telling you, and you will spend an hour rediscovering the same fix unless you wrote it down. This applies tenfold to bench-rebuilds and re-deployments.

When AP isolation is locked on by your venue and none of the bypasses are an option (no admin access, no travel router allowed, no IT support), the Bitaxe still mines fine — you just cannot manage it from inside that network. Workaround: configure the Bitaxe's settings BEFORE you bring it into the locked network (pool URL, worker name, frequency, voltage), join it to the locked WiFi, and treat it as fire-and-forget for the duration. Use the public pool dashboard for monitoring. Only update settings later when you bring the miner back to a network you control.

Do NOT ship a working miner to D-Central because the dashboard is unreachable on a guest or corporate SSID. There is no hardware fault that manifests as 'on the LAN, hashing on the pool, not reachable from a peer client.' If the Bitaxe is hashing, the Bitaxe is fine. Open a free remote-support ticket at `https://d-central.tech/contact/` or hop into D-Central's Discord — we have walked operators through every flavor of this on UniFi, ASUS, TP-Link, Eero, Google Home, Cisco Meraki, Aruba, GL.iNet, and stock ISP gateways. Free for all Bitaxe customers, EN/FR support.

When opening a D-Central remote-support ticket, give us enough info to help fast: Bitaxe variant (Supra / Ultra / Gamma / GT / Hex / Max), AxeOS firmware version (`Settings → System Info`), OLED screenshot showing IP and hostname, router/AP make and model, the SSID type (main / guest / IoT / enterprise), whether you have admin access to the AP, and a screenshot of the wireless settings page if you do. We have seen every combination — UniFi controller policies, eero guest-mode quirks, Google Home isolation defaults, hotel captive portals, Cisco Meraki client-isolation enforcement — and we will get you to the working config without anyone shipping anything.