A Family Wi-Fi Captive Portal: Map the Network Before You Deploy

A captive portal — the login page that pops up on hotel and airport Wi-Fi — is also a tidy way to gate access on a home network. Parents reach for it to put a speed bump between kids and the internet: a page that has to be acknowledged, or a condition that has to be met, before devices get out to the wider web. The temptation is to log into the router and start flipping switches. Don’t. A home network is a shared dependency, and the fastest way to spend a Saturday evening on the phone with an angry teenager is to change DNS or DHCP on live hardware without knowing what depended on it.

This is an operational runbook for the part that happens before you deploy anything: inventory the network, understand what a captive portal actually is (and is not), take read-only measurements, write down the behavior you expect, and rehearse the rollback. It is deliberately a narrow networking exercise, not another generic hardening checklist. None of the commands below change your configuration.

1. Start with an inventory, not router changes

You cannot gate a network you have not drawn. Before touching anything, fill in a worksheet. Keep it in a text file or on paper — not a sticky note — because you will need it again during rollback.

• Existing router — make, model, admin URL, who holds the admin password.
• Access point(s) — is Wi-Fi served by the router itself, a separate AP, or a mesh? List each SSID.
• DHCP authority — which device hands out IP addresses and leases? There must be exactly one on a given subnet.
• DNS authority — what resolver do clients receive? The router, a public resolver, or something on your LAN?
• Subnets — the IPv4 range (e.g. 192.168.1.0/24), the gateway address, and whether IPv6 is active.
• Parent devices — the ones that must never get locked out, including the one you administer from.
• Kids’ devices — each one, plus what school access it needs (a specific learning platform, video classes, a homework portal).

Now sketch a generic topology from that worksheet: internet → modem → router (DHCP/DNS) → access point → clients. Mark where a portal would sit in that chain. This is a generic diagram of your own house; it is explicitly not a reference to any particular vendor’s architecture. The goal is to know, on paper, which single box controls addressing and naming before you decide what to change.

2. Separate the portal experience from enforcement

“Captive portal” sounds like one thing but is really three. The IETF architecture (RFC 8952, an informational document published in November 2020) describes the components as distinct: a provisioning step that tells a joining device it is captive, an API the device can query for its state, and an enforcement point in the network that actually permits or blocks traffic. Modern operating systems detect the captive state and open the login page for you precisely because that signalling is standardized.

The crucial consequence: a captive login does not mean the portal reads your encrypted traffic. Enforcement happens at the network layer — which IPs and ports a device may reach — not by decrypting HTTPS. If any setup asks you to install a custom root certificate (an “interception CA”) or to click through browser certificate warnings, stop. That is TLS interception, a different and far more invasive thing, and it trains your family to ignore exactly the warnings that protect them. If you need HTTPS on a service you run yourself, configure real certificates properly instead — see our practical TLS setup for Nginx. A gate that controls where devices can go does not need to read what they send.

3. Read-only Linux observations

From a Linux machine already on the network, you can confirm what your worksheet claims without changing anything. These commands only read state. Availability varies by distribution: ip comes from iproute2 and is near-universal, while resolvectl exists only where systemd-resolved manages DNS (some systems use NetworkManager or resolvconf instead).

# IPv4 routes — which gateway your traffic uses
ip route

# IPv6 routes — often present even when you think IPv6 is off
ip -6 route

# DNS resolver state per link (systemd-resolved only)
resolvectl status

Read ip route for the default via line: that is your current gateway. Check ip -6 route because a device with a working IPv6 path can route around an IPv4-only gate entirely. Read resolvectl status to see which DNS server each interface was handed. Collect these outputs locally and redact MAC addresses, public IPs, and any identifiers before you paste them anywhere. One caveat worth stating plainly: these commands diagnose routes and resolvers. They show you the paths traffic can take; they do not prove that any two parts of your network are segmented from each other. None of the output here was captured on your specific hardware — run them yourself and trust your own results.

4. A one-device acceptance matrix

Before rolling anything out to the whole family, pick a single test device and write down the behavior you expect for each scenario. Each row is a requirement you intend to verify — not a capability any product has promised you. Run the list end to end on the one device and record what actually happens.

That last row matters. If a gate enforces on IPv4 only, an IPv6-capable device may walk straight past it. Test both address families explicitly rather than assuming parity.

5. Choose a deployment model

Broadly, there are three ways to put a gate in front of the kids’ devices, in rough order of effort:

• Existing router controls. Many consumer routers already offer a guest network, per-device schedules, and basic content filtering. The FTC’s consumer guidance recommends running a separate guest network and using distinct passwords for the admin interface and the Wi-Fi itself, keeping firmware updated, and using WPA2 or WPA3. If the built-in features cover your worksheet, this is the lowest-risk option.
• A documented DIY captive portal. You can build enforcement on dedicated router/firewall software. Netgate’s pfSense documentation describes a captive portal feature with gating and configuration options — and also documents its own limitations. Notably, the pfSense captive portal does not support IPv6; that is a specific statement about that implementation and should not be generalized to every product. (pfSense is a FreeBSD-based project, not Linux software, so treat it as a reference implementation rather than a drop-in for a Linux box.)
• A preconfigured appliance. Some products ship the gate as a small box you add to your existing network, trading flexibility for a shorter setup.

For a concrete example of this access-gating idea, WonderFi, a new experiment from the same owner as this site, describes a separate kids’ Wi-Fi network where short exercises unlock internet time; its networking implementation has not been independently verified here.

Whichever model you pick, hold it to the same acceptance matrix. A model that cannot satisfy the “allowed school resource” or “parent override” rows is the wrong model for your house, regardless of how it markets itself.

6. Roll back without locking the family out

Plan the exit before the entrance. Deploying a gate means changing something — DHCP scope, DNS, a new device in the path — and any of those can go wrong in a way that takes the whole house offline, parents included.

• Record the original settings. Before the first change, export or photograph the router’s current DHCP range, DNS servers, and firewall rules. This is the restore point.
• Keep a parent recovery path. Make sure at least one administrator device can always reach the router’s admin interface, independent of the gate you are adding.
• Use a maintenance window. Make changes when a failed experiment is an inconvenience, not a crisis — not ten minutes before a kid’s online class.
• Write the restore steps. “If X breaks, revert setting Y to the value in the worksheet” — specific enough to follow while stressed.
• Never test illustrative config on the live network. Rehearse on the one acceptance device first.

If the portal itself is a service that refuses to come back after a restart, treat it like any other service incident: check its status and logs methodically before you start changing things. Our Linux service incident response runbook is a useful discipline for exactly that “service restart” row in the matrix.

One hard rule: homework access must never depend on completing a challenge. School resources belong on an always-allowed list, carved out before any gating logic runs. And remember the boundary of the whole exercise — a Wi-Fi gate controls Wi-Fi. Cellular data and a neighbor’s open network are out of its path, so a Wi-Fi portal is a nudge and a structure, not a wall.

Do the mapping, take the read-only measurements, write the matrix, and rehearse the rollback. The deployment itself is almost anticlimactic once the network is drawn — which is exactly the point.