Extending guest WiFi with a third-party extender.
Stretch the guest network behind the captive portal with a TP-Link, Netgear or OpenWrt extender — and the three mistakes that break the portal.
A third-party extender can stretch your guest network into the rooms your HaloWiFi AP can't reach — with every client still behind the captive portal. The setup is three settings on the extender; the failures are always the same three mistakes. This guide covers both, plus which devices actually work.
The short version: put the extender in AP/bridge mode, match the Guest SSID exactly (open, no password), and make sure the extender never runs DHCP or NAT. Do that, and a client behind the extender is indistinguishable from a client on the main AP — same DHCP lease, same portal login, same session tracking.
How it works
The extender is a dumb radio. It rebroadcasts the Guest SSID and bridges every frame back to the HaloWiFi LAN — no routing, no NAT, no DHCP of its own. Everything that makes guest WiFi guest WiFi stays on the HaloWiFi router, unchanged: DHCP address assignment, captive-portal interception (HaloChilli), RADIUS authentication, session tracking, bandwidth quotas and analytics. The extender is invisible to the portal logic.
Backhaul matters more than brand. Run an Ethernet cable from the extender to any LAN port on the HaloWiFi router or a downstream switch. Wireless backhaul works, but on single-radio extenders it halves effective throughput and adds a roaming variable — every permanent deployment should use cable.
One ESSID per extender. A HaloWiFi router broadcasts two networks at once — the open Guest network (captive portal) and the password-protected Staff/PSK network. A third-party extender can only rebroadcast one of them. This guide extends the Guest ESSID; the Staff branch is covered in step 4.
The topology
From the router’s perspective, a client behind the extender looks identical to a client on the main AP — same DHCP range, same RADIUS session, same portal flow.
Field notes, deployment team
What the extender must never do
Three failures account for nearly every broken extender deployment:
- Double NAT. The extender must not create its own subnet. If it does, HaloChilli can’t see the client’s real IP and the captive-portal redirect fails completely — clients get a connection error instead of the login page.
- Its own DHCP. Only the HaloWiFi router assigns addresses. A live DHCP server on the extender hands out out-of-range IPs, breaking RADIUS accounting, bandwidth control and analytics. Re-check after every firmware update — some devices silently re-enable it.
- Hiding client MACs. Sessions are tracked by the client’s original MAC address. Mesh systems that forward all traffic behind the node’s own MAC break per-device session isolation, time limits and quotas for everyone on that extender.
Two softer rules: broadcast exactly one SSID (the one you chose to extend — never both), and match the Guest SSID string exactly, case-sensitive, with security set to Open / None. A mismatched SSID is a second visible network that bypasses portal auth.
Setup in six steps
- Put the extender into AP / bridge mode. In the extender’s web UI or app, switch the operating mode to Access Point (sometimes “AP mode” or “bridge”). This disables its router and NAT functions. Do not use “Range Extender” or “Repeater” mode — those create a second subnet and break the portal.
- Disable the extender’s DHCP server. Many devices do this automatically in AP mode — confirm it under LAN/Network settings. The DHCP field should read Disabled before you continue.
- Connect the backhaul cable. Ethernet from the extender’s LAN or WAN port into any LAN port on the HaloWiFi router or a switch on its LAN. Cat5e or better; for ceiling mounts, a PoE switch powers the extender over the same cable.
- Match the Guest SSID. Set the extender’s SSID to exactly the HaloWiFi Guest network name, security Open / None. The Guest network is open by design — the captive portal does the authenticating.
- Verify the client IP. Join the extender’s SSID with a test device. It should get an address in the HaloWiFi DHCP range (typically 192.168.182.x). Anything like 192.168.0.x or 10.0.0.x means the extender’s DHCP is still on — back to step 2.
- Confirm the portal appears. Browse to any HTTP site (e.g. http://example.com) — the HaloWiFi portal login should load; complete a test login end-to-end. HTTPS sites show a certificate error before the redirect can fire, so always test with plain HTTP.
Extending the Staff/PSK network instead? Same steps, different step 4: match the Staff SSID and set WPA2-Personal (or WPA3) with exactly the same passphrase. There is no captive portal on that ESSID — the password is the gate. Never leave an extender SSID open on the Staff segment; that would be uncontrolled access.
Device compatibility
From venue deployments so far — treat unlisted devices as untested and verify MAC passthrough plus true AP mode before installing:
Works in AP mode
- TP-Link RE series — Tether app or web UI: Settings → Operation Mode → Access Point. Disable DHCP under LAN settings. MAC passthrough confirmed.
- Netgear EX series — use AP mode, not Range Extender mode (settings at 192.168.1.250). Disable DHCP under LAN Setup.
- GL.iNet / OpenWrt — full control: disable DHCP, set
network.lan.proto=none, disable firewall forwarding. The most flexible option for technical deployments.
Conditional
- TP-Link Deco — must be switched to Access Point mode in the app before joining the network; mesh mode hides client MACs. Verify DHCP is off after the mode change.
- Netgear Orbi — AP mode exists on RBR/RBS; older firmware lacks MAC passthrough, so check versions first.
- Generic OpenWrt — configure as a dumb AP via LuCI/UCI: no gateway/DNS on the LAN interface, dnsmasq off, wireless bridged to LAN.
Do not use
- Amazon Eero / Google Nest WiFi — neither offers true bridge mode; both always create a second subnet and hide client MACs, which kills the portal redirect for every client behind them.
- Single-radio budget extenders — one radio shared between clients and backhaul halves throughput, and most can’t do true AP mode at all.
When something’s not right
- Portal not appearing — test with an HTTP (not HTTPS) site; confirm the client IP is in the 192.168.182.x range; confirm AP mode (not router/NAT) and that no second DHCP server is live.
- Wrong client IP — the extender’s DHCP is active. Disable it, reboot the extender, reconnect. Firmware updates are the usual culprit.
- Per-device limits not enforcing — the extender is in mesh mode and hiding MACs. Switch to true AP/bridge mode; verify with a capture that the client MAC appears on the LAN.
- Clients get uncontrolled access — the extender SSID is bridged to the wrong segment and has bypassed HaloChilli. Re-bridge onto the Guest LAN and confirm NAT is off.
When to stop extending
Extenders work, with caveats you now know: no RF telemetry, no fast roaming, and settings that need re-checking after firmware updates. A second HaloWiFi AP removes all three — full cloud visibility, zero MAC-passthrough concerns, and seamless portal roaming: HaloWiFi APs in one deployment share 802.11r keys automatically through the cloud controller, so handoffs take ~50 ms. A third-party extender on the same SSID forces a full re-association — a 150–300 ms drop — every time a client walks between radios.
If the extender is a stopgap, it’s a good one. If coverage is the actual problem, the second AP is the actual fix — and it’s managed from the same dashboard as the first. Questions either way: [email protected].