Daniel sent us this one — he's running a Ubiquiti setup with three SSIDs already, and he's been thinking about adding VPN-routed SSIDs for privacy and geo-spoofing. His wife asked the killer question: if the whole network is always-on VPN to Israel, how do you override that at the client level when you want to appear in the US for streaming? His instinct was to create separate SSIDs for different geographies, maybe even a Tor SSID. But before he goes down that road, he wants to know whether adding SSIDs actually creates radio interference, and whether hiding an SSID helps. That's the tension — more SSIDs equals more flexibility, but does it also equal more noise?
It's the right question to ask, because the answer lives in a place most home networking guides never go — the beacon frame. Not the router config page, not the VLAN setup, but what the access point is actually doing with its radio, a hundred times a second, whether you've configured one SSID or twelve. And I love this question because it exposes a mental model that almost everyone has and almost everyone gets wrong. We think of SSIDs as separate networks, like lanes on a highway. More lanes, more cars, more congestion. But that's not what's happening at the radio level at all.
It's the heartbeat of WiFi. Every access point sends out these management frames called beacons on a fixed interval — by default, one hundred Time Units, which works out to about a hundred and two point four milliseconds. The beacon announces the network's existence, its capabilities, its supported data rates, and crucially, its SSID. When you have one SSID, the AP sends one beacon per interval. When you have three, it sends three — sequentially, on the same channel, from the same radio.
They're not separate networks in any radio sense. They're just labels in a queue.
An SSID is an identification construct — it's a field in a management frame. Adding an SSID doesn't spin up a new radio or carve out a new channel. It just means the AP's existing radio has to spend a little more time transmitting management traffic before it can get back to carrying your actual data. That's the overhead, and it's not interference in the traditional sense — it's not noise from a neighboring network stomping on your signal. It's your own AP doing housekeeping.
The question becomes: how much housekeeping is too much? And I think this is where Daniel's concern about interference comes from — he's imagining his AP shouting multiple network names simultaneously and those shouts colliding somehow.
Right, and that's the wrong picture. Think of it like a public address system in a train station. One announcer, one microphone, one speaker. If that announcer has to read three announcements instead of one, it takes three times as long to get through the announcements. But the announcements don't collide with each other — they're sequential. The announcer isn't shouting over himself. The cost is time, not clarity. And Ekahau, the WiFi survey and design company, did the testing on this back in twenty twenty-one. Their numbers: each additional SSID consumes roughly zero point one to zero point three megabits per second of airtime for beacon frames. That's the raw management overhead. For a home user with three to six SSIDs on a single access point, we're talking less than one percent of total airtime. It's negligible — your microwave oven is a bigger threat to your WiFi than your fourth SSID.
My microwave doesn't have a VLAN tag, I assume.
It doesn't even support WPA3. But here's where the real cost shows up — and it's not the beacon frames themselves, it's contention. In dense environments, every management frame is a moment when a client device can't transmit. More beacons mean more moments of silence enforced by the AP. If you're in an apartment building with forty overlapping BSSIDs from your neighbors, and you're also running eight SSIDs of your own, suddenly the channel is spending real percentages of its capacity just on beacons. I've seen enterprise horror stories — a conference center with twelve SSIDs per AP and forty overlapping APs, where beacon traffic exceeded fifteen percent of channel capacity.
Fifteen percent of the air just announcing "I'm here, I'm here, I'm here." That's like a party where everyone's introducing themselves so loudly that nobody can actually have a conversation.
And the conference center didn't even realize it. They kept adding SSIDs for different departments, different guest tiers, different vendor networks, and nobody stopped to calculate the cumulative beacon load. The WiFi felt slow, so they added more APs, which added more beacons, which made the problem worse. It's a death spiral of politeness — every AP politely announcing itself while collectively drowning out actual traffic.
Which brings us to the hidden SSID myth, and this is where I need to be really clear because it's one of the most persistent misconceptions in WiFi. Cisco has a support document — document eight two zero six eight — that explicitly addresses this. Disabling SSID broadcast does not reduce beacon transmission. The AP still sends the beacon. The SSID is still in the frame body. It's just not in the SSID parameter set field, which is the part that consumer devices display in their network list.
Hiding the SSID is like taking your name off the mailbox but still having the mail carrier deliver letters to your house.
That's actually perfect. And anyone with Wireshark or Kismet — free tools — can see the SSID instantly. It's not encrypted, it's not obscured, it's just not in the one field that Windows and macOS use to populate the "available networks" list. Meanwhile, you've created a new problem: clients that want to connect to a hidden network can't just passively listen for beacons. They have to actively send probe requests saying "are you there, hidden network?" and the AP has to respond with a probe response for each one.
It increases traffic.
It increases management traffic on both sides. Cisco's document is blunt about it — hidden SSIDs create more overhead, not less. And there's a secondary issue: some client devices, especially older IoT gear, handle hidden SSIDs poorly. They'll keep probing, draining battery, or fail to roam properly between APs because they can't passively scan for the network.
I want to dig into that roaming failure for a second, because it's one of those things that sounds theoretical until it bites you. What actually happens when a device can't roam?
Imagine you've got two APs in your house, both broadcasting the same hidden SSID. Your phone is connected to the one in the living room, and you walk to the bedroom. Normally, your phone would passively hear the bedroom AP's beacon, realize the signal is stronger, and initiate a roam. But because the SSID is hidden, your phone can't passively identify the bedroom AP as the same network. It has to actively probe, which takes longer and consumes more power. By the time it figures it out, you've already been standing in the bedroom for thirty seconds with a dead connection, and your video call has dropped. It's a real, tangible user experience degradation, all for a security measure that provides zero actual security.
The short answer to Daniel's two questions: adding a few SSIDs won't hurt his radio performance in any measurable way, and hiding them would actually make things worse.
That's the radio layer. But Daniel's real project isn't about beacon frames — it's about routing policy. And that's where this gets interesting, because the SSID-per-geography idea is actually viable. It's clever. It solves a real problem.
Let's walk through the wife's scenario. Whole network VPN to Israel. She wants to watch something on a US streaming service. The streaming service sees an Israeli IP and blocks her. On a normal setup, she'd have to disconnect the VPN on her device, which defeats the purpose, or run a second VPN client on her laptop, which is fiddly and prone to leaking.
The beauty of Daniel's approach is that the client doesn't need to run a VPN at all. The network does it for them. On a Ubiquiti system, the chain works like this: you create a new SSID, you assign it to a VLAN, you create a routing policy that says "traffic from this VLAN goes out through this WireGuard or OpenVPN tunnel," and you point that tunnel at an endpoint in New York or London or wherever. The client joins the "US Streaming" SSID, and from the perspective of Netflix, that device is in the United States. No client software, no split tunneling configuration, just join the right WiFi network.
Which is both elegant and slightly absurd. You're choosing your nationality by picking a WiFi network.
Welcome to the modern internet. And on Ubiquiti's own community forums, there are multiple threads where users report running five to eight SSIDs on a single U6 series AP with no measurable throughput degradation. One user I saw runs main, IoT, guest, US-VPN, and UK-VPN on a single U6-Pro and says there's no noticeable performance difference. The bottleneck is the VPN tunnel's bandwidth, not the WiFi. And that's the thing — people obsess over the WiFi layer when the real constraint is the VPN endpoint's throughput. If your VPN provider gives you fifty megabits per second, it doesn't matter if your WiFi can do six hundred.
That fifty megabit number is generous for a lot of commercial VPN services. So the VPN tunnel is the bottleneck, not the beacon frames.
And here's a concrete example. Let's say Daniel sets up a US-VPN SSID that routes through a WireGuard tunnel to a New York endpoint. His wife connects her laptop to that SSID and starts streaming Netflix in 4K. Netflix recommends about fifteen megabits per second for 4K streaming. The VPN tunnel can easily handle that — even a modest VPN provider should give you twenty-five to fifty megabits. The WiFi overhead from that additional SSID is consuming maybe zero point two megabits of airtime for beacons. So the streaming experience is bottlenecked by the VPN tunnel's capacity, not by the WiFi management overhead. The beacon frames are a rounding error.
Daniel's idea passes the radio test and the practical test. What about the Tor SSID?
That's where I'd pump the brakes. Technically, you can do it — create an SSID that routes all traffic through Tor. But Tor over WiFi introduces complications that a lot of people don't think through. Tor circuits bounce through three relays by design, and each hop adds delay. Web browsing over Tor on WiFi is already slow; adding the WiFi management layer doesn't help. Second, Tor's design resists the "choose your exit country" idea. You can configure Tor to prefer exit nodes in certain countries, but you get what the circuit gives you — it's not a guarantee.
The anonymity promise gets complicated.
Tor exit nodes can see your traffic if it's not encrypted at the application layer. Your source IP is hidden from the destination server, but the exit node's IP is public — and many services block known Tor exit nodes outright. Plus, running all your home traffic through Tor creates metadata patterns. If someone is doing timing analysis and they can see that your house's internet connection has bursts of Tor traffic that correlate with, say, posting on a forum, that's a correlation attack vector. It's not that Tor is broken — it's that Tor wasn't designed for "route my entire smart TV through it.
The Tor SSID is a fun party trick, but it's not a serious privacy tool in this configuration. What about the scenario where someone actually needs Tor-level anonymity for a specific device? Is the Tor Browser just always the better answer?
The Tor Browser is built by people who understand Tor's threat model deeply. It bundles privacy protections that a raw Tor connection doesn't give you — it blocks browser fingerprinting, it enforces HTTPS, it isolates cookies per tab. When you route arbitrary traffic through Tor at the network level, you lose all of that. Your smart TV isn't going to suddenly start resisting fingerprinting just because its packets are going through a Tor circuit. You're getting the latency penalty of Tor without the privacy benefits of the Tor Browser's application-layer protections. It's the worst of both worlds.
The Tor SSID is a research project. If Daniel wants to learn how Tor circuits work and he's willing to accept that his Roku will be unusably slow, sure. But for the stated goal of geo-spoofing, a commercial VPN endpoint is the right tool.
Let's talk about the practical downsides of the multi-SSID approach, because there are real ones even if the radio layer is fine. Daniel's already got three SSIDs. Add a US one, a UK one, maybe a Tor one — now we're at six. That's six passwords to manage, six networks cluttering the WiFi picker on every device, and a family conversation that starts with "which network am I supposed to be on for this?
And it's a real usability problem. My phone doesn't know that the UK SSID is for BBC iPlayer — it just sees six networks with similar names and picks whichever one has the strongest signal. If I walk from the living room to the kitchen and my phone roams from US-VPN to Main, suddenly my streaming session drops because my IP changed mid-stream.
Daniel's wife, who asked the smart question in the first place, is now the one who has to remember which network to join when she wants to watch different things. She went from "how do I override the VPN?" to "I need a cheat sheet to use my own WiFi.
That's the failure mode that kills these setups. Not a technical failure — a human factors failure. The network works perfectly, but nobody can remember which SSID does what, so they just stay on the main one and the fancy geo-spoofing SSIDs sit there unused, quietly burning beacon frame airtime for no benefit. I've seen this in corporate environments too — the marketing team gets a special SSID for demo purposes, and six months later nobody uses it, but it's still broadcasting, still consuming airtime, still appearing in everyone's WiFi picker.
Which is why I want to talk about the alternative, because it's the approach that actually answers her question more elegantly. Instead of multiple SSIDs, you do policy-based routing on a single SSID. The router inspects the traffic, sees that it's destined for Netflix, and routes it through the US VPN tunnel. Everything else goes through the Israel VPN or direct. One SSID, one password, zero client decisions.
That's the dream, right? The network just knows. You don't think about geography — the router handles it transparently.
That sounds cleaner. Why wouldn't everyone do that?
Because it's harder to configure. Ubiquiti's built-in tools can do basic policy-based routing — you can route by destination IP or by port — but they're not great at domain-based routing. Netflix uses hundreds of IP ranges and they change constantly. If you want to say "anything going to a Netflix-owned domain goes through the US tunnel," you need something that can do DNS-based policy routing. That's where pfSense shines, or OpenWrt, or even a Raspberry Pi running Pi-hole plus WireGuard split tunneling.
The tradeoff is: SSID-per-VPN is simple to configure but messy to use. Single-SSID with policy routing is clean to use but complex to configure.
And Daniel's tolerance for tinkering is the deciding factor. If he enjoys spending a Saturday afternoon writing pfSense rules and maintaining a list of streaming service IP ranges, the single-SSID approach is objectively better. If he wants something that works tonight with the gear he already has, adding two SSIDs and pointing them at VPN tunnels is perfectly reasonable.
There's a middle ground too, isn't there? Keep the always-on VPN SSID for most devices, and have one "direct" SSID for when you need to override.
That's the simplest version of the idea, and honestly, it might be the smartest starting point. Daniel's original three SSIDs plus one additional one — call it "No-VPN" or "Local" — that bypasses the tunnel entirely. When his wife needs to geo-spoof, she joins that SSID and runs a VPN client on her device, choosing whatever endpoint she wants. It's not as slick as the per-geography SSID approach, but it's zero additional router configuration beyond creating the SSID and excluding it from the VPN routing policy.
It avoids the "which country am I joining" problem entirely.
The client handles geo-selection, the network just provides a clean exit. It's the least clever solution, and sometimes that's the best kind. There's a principle in system design — I think it comes from the SRE world — that you should solve problems at the layer where the knowledge lives. The knowledge of "I want to appear American right now" lives in the user's head. Moving that decision to the network layer means you have to encode that knowledge into SSID names and routing tables. Sometimes it's better to just let the user express that intent directly on their device.
Before we get to recommendations, I want to bust one more myth that keeps showing up in forum threads about this exact topic. There's this idea that more SSIDs create more interference because they're "separate networks" competing for airspace. You touched on this earlier, but let's be really explicit.
They're not separate networks at the radio level. They're management frames from the same physical radio on the same channel. The radio doesn't care whether the beacon says "Daniel-Main" or "Daniel-US-VPN" — it's just bits in a frame. The only thing that changes is how many frames the radio has to send per beacon interval. Interference comes from other radios on the same or adjacent channels — your neighbor's AP, not your own fourth SSID.
The hidden SSID thing — I want to make sure we're clear on the security angle too, because some people think hiding the SSID is a security measure.
It's security theater. The SSID is transmitted in cleartext in every beacon frame regardless of whether broadcasting is "disabled." Any WiFi scanner can see it. The only thing hiding does is prevent casual users from seeing your network in their phone's WiFi list — and it annoys your own devices by making them shout "are you there?If you want to secure your network, use a strong WPA3 passphrase and keep your firmware updated. Hiding the SSID does nothing except make your own life harder.
I want to pause on the phrase "security theater" because it gets thrown around a lot, but this is a textbook case. Security theater is when something feels secure but doesn't actually improve your security posture. Hiding an SSID feels like you're making your network invisible. In reality, you're making it slightly more annoying to connect to, while broadcasting its name in cleartext to anyone with a five-dollar WiFi adapter and free software. It's the digital equivalent of closing your curtains but leaving the window wide open.
The worst part is that it can create a false sense of security that leads to worse decisions. Someone who hides their SSID might think "well, my network is invisible, so I don't need a strong password." And now you've got a hidden network with a weak passphrase, which is actually worse than a visible network with a strong one — because at least with the visible network, you know you need good authentication.
To summarize the radio layer for Daniel: with six or fewer SSIDs on a single AP, the overhead is under one percent of airtime. His internet connection will be the bottleneck, not beacon frames. And he should never hide an SSID — it increases management traffic and provides zero security benefit.
On the routing layer, his SSID-per-geography idea is technically sound. The Ubiquiti gear can do it. The VPN tunnel bandwidth is the constraint, not the WiFi. The real question is whether he wants to manage multiple SSIDs and train his family on which network to use for which activity.
Which brings us to actionable recommendations. Daniel, if you're listening — and I assume you are, since you sent the prompt — here's what I'd do. Start with two additional SSIDs beyond your current three. One for a US VPN endpoint, one for a UK endpoint. Set them up, monitor your airtime utilization in the Ubiquiti controller, and see if management frame overhead creeps above two percent. It almost certainly won't.
If you find that the multi-SSID life is annoying — too many networks, family members confused, devices roaming wrong — then you've learned something valuable, and you can invest the time in building a policy-based routing setup on a single SSID. The multi-SSID approach is a perfectly fine version one. It's not the final form, but it works tonight.
The other thing I'd suggest: skip the Tor SSID for now. If you're curious about Tor, run the Tor Browser on a device connected to your direct SSID. That gives you the anonymity properties of Tor without the complexity of routing your entire network through it, and it avoids the IoT device compatibility nightmare.
To Daniel's wife — she asked exactly the right question. The whole point of an always-on VPN is that you don't think about it, but the moment you need to think about it, the abstraction breaks. The SSID-per-geography hack is a way to restore choice without sacrificing the default privacy posture. It's a clever answer to a sharp question.
One thing we haven't talked about — and this is where the future gets interesting — is WiFi seven, eight oh two dot eleven B E. It introduces something called multi-link operation, or MLO, which allows an access point to use multiple radios across different bands simultaneously. In theory, future hardware could assign different SSIDs to different radio links, which would actually reduce contention rather than increase it.
The SSID overhead calculus might flip entirely. If your AP has three radios and you're running three SSIDs, each one could potentially get its own dedicated link with no beacon competition. We're not there yet with consumer hardware — the first WiFi seven APs are just hitting the market and MLO implementations are still basic — but it's coming. Daniel's question might have a completely different answer in two years.
Which is a good reminder that the right answer today is about understanding the mechanism, not memorizing the rule. Daniel asked whether SSIDs cause interference — the answer is "no, they cause overhead, and here's how much." He asked whether hiding helps — the answer is "no, it hurts, and here's why." Those mechanisms are what let you make good decisions when the hardware changes.
The best home networks are built on good questions, not expensive gear. Daniel's wife asking "what happens when we need to override the VPN?" is worth more than any piece of equipment in the rack. That question is the difference between a network that serves the people using it and a network that serves the person who built it.
Now: Hilbert's daily fun fact.
Hilbert: In seventeen eighty-seven, a Spanish naval expedition off the coast of Patagonia recovered a single surviving page from a naturalist's journal describing the cuttlefish's ability to match not just the color but the precise texture of surrounding kelp — a camouflage mechanism so sophisticated that the journal's author initially believed the specimen had escaped his collection jar, only to realize it had been pressed against the glass the entire time, perfectly imitating the cork stopper.
That cuttlefish was playing four-dimensional chess with a Spanish naturalist. And I have to say, there's something deeply humbling about a creature that can do real-time texture matching when I can't even get my phone to reliably switch between two WiFi networks.
I'm now going to spend the rest of the day wondering what else I've been looking directly at without seeing. A cuttlefish imitating a cork stopper is basically the biological equivalent of a hidden SSID — it's right there, you're looking at it, but your brain is telling you it's something else entirely.
Except the cuttlefish actually achieves something useful with its deception. The hidden SSID just makes your own devices shout louder.
Network administrators: zero.
This has been My Weird Prompts. Thanks to our producer Hilbert Flumingtop. If you've got a weird prompt of your own — maybe your wife asked a question that sent you down a networking rabbit hole — email the show at show at my weird prompts dot com. We'll be back next week.
