A Guest Wi-Fi That's Actually Isolated

Someone comes round, asks for the Wi-Fi password, and you hand it over without a second thought. That password, on most home setups, is a key to the same flat network your NAS, your printer, your cameras and your router’s admin page all live on. The “Guest Network” checkbox on a typical ISP router does surprisingly little to change that — and understanding what it actually does is the difference between a network that feels isolated and one that is.

What the guest toggle usually does, and why it isn’t enough

When you enable the guest option on most consumer routers, one of two things happens. Either the router spins up a second SSID that hands out addresses on the same subnet as everything else, with a firewall rule that half-heartedly blocks a couple of ports, or it enables something called AP isolation (sometimes “client isolation” or “station isolation”). AP isolation stops two wireless clients on that SSID from talking to each other — useful in a coffee shop — but it does nothing about a guest reaching wired devices, the router’s own management interface, or anything on the broader LAN. A visitor’s phone can still open 192.168.1.1 and see the login page, still discover the NAS over mDNS, still hammer the printer.

The reason this matters is not that your friends are hostile. The threat is the phone itself: a device you don’t control, running apps you’ve never audited, possibly already compromised, sitting inside your trust boundary for the evening. A single infected laptop plugged in “just to grab a file” has all the lateral reach it needs if the guest network is really just your network with a different password. Proper guest isolation means a visitor can do exactly one thing — reach the internet — and nothing else. Not the NAS, not the cameras, not the router config, not the other guests.

Getting there means treating the guest SSID as belonging to a separate network segment with its own address range, and then writing firewall rules that permit the internet and deny everything internal. On consumer gear that segment is a VLAN, and if the idea of VLANs makes you nervous, the groundwork is worth reading first in VLANs without fear. Everything below assumes you can tag a wireless SSID onto its own VLAN, which most access points that aren’t ISP-supplied can do.

The shape of a properly isolated guest network

Picture four things a guest device might try to reach: the internet, the router itself, your internal LAN, and the other guests. An isolated design allows the first, allows a tightly scoped slice of the second, and denies the last two.

The internet is the whole point, so that traffic passes. The router needs to be reachable for two narrow purposes — the guest device must get an address over DHCP and must be able to resolve names over DNS — so those two services stay open and nothing else on the router does. The internal LAN, meaning every other subnet you run, is denied outright: a guest packet destined for 192.168.1.0/24 (or wherever your trusted devices live) hits a drop rule. And guest-to-guest traffic is cut off with client isolation on the AP, so one visitor’s phone can’t see another’s.

Here’s a firewall ruleset that expresses exactly that. It’s written in nftables, which is what a Linux-based router or a device running something like OpenWrt will use under the bonnet; the logic maps cleanly onto the rule tables in OPNsense, pfSense or a UniFi controller if that’s what you run. Assume the guest VLAN interface is guest0 on 192.168.50.0/24, and your trusted networks are the RFC1918 ranges.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

table inet guest_fw {
    # the set of everything a guest must NOT reach
    set internal_nets {
        type ipv4_addr
        flags interval
        elements = { 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12 }
    }

    chain guest_in {
        type filter hook input priority 0; policy drop;

        iifname "guest0" ct state established,related accept
        # let guests get an address and resolve names — nothing else on the router
        iifname "guest0" udp dport { 67, 68 } accept
        iifname "guest0" udp dport 53 accept
        iifname "guest0" tcp dport 53 accept
        iifname "guest0" ip protocol icmp icmp type echo-request accept
        # everything else aimed at the router itself is dropped by policy
    }

    chain guest_fwd {
        type filter hook forward priority 0; policy drop;

        iifname "guest0" ct state established,related accept
        # block guests from routing into any internal network
        iifname "guest0" ip daddr @internal_nets drop
        # allow the rest (i.e. the internet) out
        iifname "guest0" accept
    }
}

Two chains are doing the work. guest_in governs traffic aimed at the router and defaults to drop, opening only DHCP, DNS and ping. guest_fwd governs traffic being routed through the router and drops anything headed for an internal range before allowing the remainder out to the internet. The order matters: the drop rule for @internal_nets sits above the blanket accept, so a guest packet to your NAS is discarded before the accept ever sees it.

That set-based approach is deliberate. Rather than listing your subnets one rule at a time, @internal_nets names the whole RFC1918 space, so a guest can’t reach any private range you might add later without you touching the ruleset again. It fails closed.

DHCP, DNS and the small services a guest still needs

An isolated segment still has to hand out addresses and answer name lookups, or nothing works and your visitors just see “connected, no internet”. Run a DHCP scope bound to the guest VLAN with a lease pool in 192.168.50.100–200, the gateway set to the router’s guest-side address, and — this is the part people miss — the DNS server pointing at whatever you want guests to use.

Pointing guest DNS at your internal sinkhole is a genuine decision with two sides. On one hand, sending guests through your ad-and-tracker filter is a small kindness and keeps their lookups off the ISP’s resolver. On the other, it means the guest VLAN can reach one internal service (the sinkhole), which slightly softens the isolation, and it exposes your block-list behaviour to strangers. My compromise is to run a separate DNS listener for guests — the same AdGuard Home or Pi-hole instance can bind a second interface — so guests get filtering without being handed a route to the management network. If that’s more fiddle than you want, pointing the guest scope straight at a public resolver like 9.9.9.9 is a perfectly honest choice and keeps the segment completely sealed from your infrastructure.

Whatever you choose, hard-code it in the DHCP options. If you leave guest DNS pointing at the router and the router forwards to your internal resolver, you’ve quietly built the exact route you were trying to avoid.

Bandwidth: stopping one guest from eating the uplink

Isolation is about reach, but there’s a related annoyance worth handling at the same time: a guest device syncing a phone backup or streaming 4K can starve your own traffic. Most access points and routers that support VLAN-tagged SSIDs also support per-SSID rate limiting. Cap the guest SSID at something civil — a few tens of megabits down, less up — and the worst a visitor can do is slow themselves down. If your gear does the limiting on the switch instead of the AP, the counters you’d use to see who’s consuming what are the same ones covered in per-device bandwidth monitoring with a managed switch.

Troubleshooting the things that will go wrong

Guests connect but get no IP address. Nine times out of ten this is a VLAN tagging problem, not a firewall one. The SSID is tagged onto VLAN 50 at the access point, but the trunk port carrying traffic from the AP back to the router doesn’t have VLAN 50 tagged, so the DHCP request never arrives. Check that every switch port in the path between AP and router carries the guest VLAN as a tagged member. A quick way to confirm the AP side is right is to plug a laptop into a port set as untagged on VLAN 50 and see whether it gets a guest address.

Guests get an IP but no internet. Now it probably is the firewall, or DNS. Confirm the guest can resolve a name (nslookup example.com from the guest device); if resolution fails, your DNS option in the DHCP scope is wrong or the port-53 accept rule is missing. If resolution works but nothing loads, your forward chain is dropping the return traffic — check that the established,related accept sits at the top of guest_fwd, because without it the replies to a guest’s own outbound connections get caught by the drop policy.

Guests can still reach the router’s admin page. The guest_in chain’s default policy must be drop, and you must not have a stray accept for the router’s web port. Test it directly: from a guest device, try to open the router’s management address and try to SSH to it. Both should time out. If the login page loads, something above the policy line is letting it through — often a management rule that isn’t scoped to a source interface.

Casting and AirPlay stop working. This is the honest cost of isolation. Chromecast, AirPlay and most “cast to the telly” features rely on mDNS/Bonjour discovery, which is link-local and does not cross between VLANs by design. If a guest genuinely needs to cast, you either accept an mDNS reflector/repeater that selectively bridges discovery between the guest and media VLANs — which pokes a deliberate, narrow hole in the isolation — or you decide guests don’t cast and leave the segment sealed. I keep mine sealed and hand out the TV remote instead.

One guest can see another. Enable client isolation on the guest SSID at the access point. The firewall rules above stop guest-to-LAN traffic, but two clients on the same AP and VLAN can talk to each other at layer 2 without a routed packet ever reaching the firewall, so the AP has to be the one to break that path.

Is it worth it?

If your idea of a guest network is the checkbox on the ISP router, then yes, unequivocally — the checkbox is mostly theatre and a VLAN-backed segment with the firewall rules above is the first version that actually earns the name. It costs you an evening, an access point that can tag SSIDs onto VLANs, and a router you can write real rules on. In return, every phone, laptop and smart-thing a visitor brings through the door is fenced into a segment where the only thing it can touch is the internet.

Who is this overkill for? If you live alone, never have visitors, and your “guests” are only ever your own trusted devices, the honest answer is that you don’t need a guest network at all. But the moment you’re handing a password to a device you didn’t set up, the gap between AP isolation and real isolation is exactly the gap an attacker would use — and closing it is an afternoon’s work you do once and never think about again.