Guest Wi-Fi is the part of a hotel network that generates the most complaints and receives the least engineering. It is often bolted onto whatever infrastructure already existed, given its own SSID, and declared separate — which it is not, in any of the ways that matter.
This is about how guest access is actually put together: what separation means at the network layer, why an extra SSID costs you capacity rather than adding it, how the various portal approaches trade off against each other, and what to think about before you start collecting data from the people using it.
A separate SSID is not a separate network
An SSID is a name broadcast by a radio. That is the whole of it. Two SSIDs on the same access point share the same radios, the same channel, the same airtime and — unless somebody has done the work — the same layer 2 network, the same DHCP scope and the same route to everything else on site.
Real separation is done at the network layer:
- Distinct VLANs. Each SSID maps to its own VLAN, with its own subnet and DHCP scope, trunked back from the access points to the switching. This is the foundation; without it nothing below is meaningful.
- Routing and firewall policy. Guest traffic should reach the internet and nothing else. Deny guest to corporate, guest to management, guest to building services, guest to payment infrastructure, explicitly — and by default rather than by exception.
- Client isolation. Guests on the same VLAN can otherwise see each other. Peer-to-peer blocking on the guest SSID stops one guest device scanning, reaching or attacking another. In a hotel, where the guest network is effectively a public network with private devices on it, this is not optional.
- Separate management. Access point and switch management interfaces on their own VLAN, unreachable from any guest path.
- Its own DNS. A resolver you control, with filtering, so the guest network does not become an open relay for whatever a compromised device wants to do.
- Its own egress where you can. A separate circuit, or at minimum separate queues and a committed share, so a saturated guest network does not take the property management system, the payment terminals or the door system with it.
Back-of-house systems deserve the same treatment as a category. Payment terminals, door locks, building management, CCTV and IoT sensors each have different risk profiles and should not share a broadcast domain with each other or with guests simply because they all happen to be wireless.
Airtime is shared, whatever the SSID says
This is the mechanism most often missed, and it explains a large share of "the guest Wi-Fi is killing the business network" complaints.
Wi-Fi is a contended medium. Every device associated to a radio — regardless of SSID, VLAN or policy — takes its turn on the same channel. A radio can only transmit one frame at a time. VLAN separation gives you security and routing control; it gives you no protection at all from a guest device consuming the airtime that a staff device needs.
Worse, the relationship between bandwidth and airtime is not what people expect. A device with a strong signal transmitting at a high data rate gets its data across in a short burst. A device at the edge of the cell, on a slow rate, occupies the medium for a much longer period to move the same amount of data. So the guest sitting in the far corner of the lounge with two bars can consume disproportionately more airtime than the guest sitting under the access point streaming video — even though the second one is using more bandwidth.
Sensible guest policy therefore tends to combine: a per-client rate limit set to something a guest actually needs rather than something generous; a per-SSID aggregate limit; airtime fairness enabled; a minimum data rate high enough that a device cannot cling on from the car park; and a realistic view of concurrent devices per room, because modern travellers arrive with three or four each.
Captive portals and their trade-offs
There is no portal approach without a cost. The question is which cost you would rather pay.
| Approach | What it gives you | What it costs you |
|---|---|---|
| Click-through Accept terms and continue | Lowest friction. Fastest route from arrival to working internet, which is what most complaints are actually about. | No identification of the user and no data captured. For some operators that is a feature rather than a cost. |
| Email or form capture | Contact details, and a marketing list if consent is properly obtained. | Friction, and a significant share of deliberately false entries. Brings you squarely into personal data territory, with everything that implies. |
| Social login | Fast for the guest, and richer profile data. | Dependency on a third-party identity provider, an outbound connection required before the guest is authenticated, and a data-sharing relationship you must be comfortable explaining. |
| SMS or voucher code | A verified route to a real person, and natural session control. Vouchers suit conferences and short stays. | Cost per message, delivery failures for international guests, and reception staff time issuing codes. |
| PMS integration Room number and surname | Ties access to an actual booking, supports tiered service by rate or loyalty tier, and expires automatically at checkout. | Integration work and an ongoing dependency between the network and the property management system. When the PMS is down, so is guest Wi-Fi, unless there is a fallback. |
| WPA3 Enhanced Open (OWE) | Encrypts the air on an open network with no password and no user action, so guest traffic is not readable by anyone else in range. | Client support is not universal on older devices, and it authenticates nothing — it is a confidentiality measure, not an access control, and pairs with rather than replaces a portal. |
| Passpoint / Hotspot 2.0 | Automatic, credential-based association with no portal at all. Excellent where it works. | Requires provisioning and client support, and is generally worth it only for operators with a scheme or a chain-wide identity to attach it to. |
The implementation details that cause the tickets
- Captive portal detection. Modern operating systems test for a portal by requesting a known URL and watching what comes back. If that mechanism is blocked or the response is malformed, the guest gets a connection that says it is online and does not work — and no portal appears. This is a leading cause of "the Wi-Fi is broken" at the front desk.
- HTTPS cannot be intercepted cleanly. A portal that tries to redirect an encrypted session produces certificate warnings and trains guests to click through security errors. Well-behaved portals rely on the operating system's own detection rather than intercepting traffic.
- Devices without browsers. Smart TVs, games consoles, casting sticks, e-readers and a growing pile of IoT cannot present a portal. They need MAC-based bypass, a separate pre-shared-key SSID, or a self-service registration route.
- Session persistence across roams. If the portal session is tied to an access point rather than held centrally, a guest walking from reception to the bar gets asked to sign in again. This is entirely avoidable and entirely common.
- Casting between rooms. Guests expect to cast from a phone to an in-room TV. Discovery protocols such as mDNS do not cross VLAN boundaries without a proxy or a purpose-built gateway, and enabling them carelessly lets a guest cast into somebody else's room. This needs designing, not switching on.
- Session length and re-auth. Set to the realistic length of a stay or a visit. A portal that re-appears every few hours generates more complaints than it prevents.
Data collection and consent: what to think about
The moment a portal collects a name, an email address or a phone number, an operator is processing personal data — and device identifiers such as MAC addresses may count as personal data in their own right depending on how they are used and retained. This is a legal question rather than a technical one, so what follows is a list of things worth putting to whoever advises you on data protection, not advice in itself.
- What are you actually collecting, and why? Many portals collect fields because the template offered them. Every field should have a purpose you can articulate.
- On what basis? The basis for providing the service is not the same as the basis for marketing to someone afterwards, and the two are worth keeping visibly separate.
- Is consent to marketing separate from access? A tick box that bundles "I accept the terms" with "send me offers" is the arrangement most often criticised. Unbundling it is straightforward to implement.
- Is the privacy notice available before the point of collection? On the portal page itself, reachable without signing in — which means it has to be on the walled-garden allow list.
- How long is it kept, and who else sees it? Portal platforms are frequently cloud services operated by a third party, sometimes in another jurisdiction. That relationship needs to be documented.
- What about logs? Association logs, DHCP leases and portal records accumulate by default. Decide a retention period deliberately rather than letting the platform's default decide it for you.
- Presence analytics. Wi-Fi presence and footfall analytics work by observing devices that have not connected to anything. Whether and how that can be done is a question worth asking before the feature is enabled, not after.
The engineering point is narrower and we will stand behind it: the portal platform should let you configure all of the above rather than forcing a template on you, and that capability is worth checking during selection rather than discovering afterwards.
SSID sprawl, and why it costs capacity
SSIDs feel free. They are not, and the cost is paid in exactly the resource a busy hotel has least of.
Each SSID is advertised by a beacon frame, transmitted on every radio that carries it, at roughly ten times a second. Beacons are sent at the lowest mandatory data rate so that every supported client can decode them — which means they are sent slowly, and a slow frame occupies the medium for longer than a fast one. Add broadcast and multicast handling, probe responses to every scanning device, and the airtime spent simply announcing the network's existence grows with every SSID you add, on every radio, whether anyone is using it or not.
A property with Guest, Guest-5G, Staff, Staff-Old, Conference, Events, EPOS, CCTV and an SSID somebody created for a trade show three years ago is spending a real and recoverable share of its capacity on overhead. The remedies are unglamorous:
- Keep the count low. Most properties can run on a small handful, and the discipline is worth more than any single tuning change.
- Do not create separate SSIDs per band. One SSID across both bands, with steering considered on its merits, rather than Guest and Guest-5G.
- Use one SSID with multiple VLANs where the platform supports it — dynamic VLAN assignment by RADIUS attribute, or per-user pre-shared keys — instead of one SSID per user class.
- Do not broadcast an SSID on radios that do not need it. A back-of-house or EPOS SSID rarely needs to exist on every access point in the building.
- Raise the lowest mandatory rate, so the beacons that remain cost less airtime and the cell has a defined edge.
- Retire what is unused. Every SSID should have someone who can say what it is for.
None of this is exotic, and most of it is free. It is also the sort of thing that gets decided properly at design stage and patched badly afterwards, which is why it belongs in the design rather than in the commissioning notes. More on how this plays out in practice in hospitality and hotels.
Let's find out what your Wi-Fi is actually doing.
Book a survey and you get measured data, a design you can build to, and a number you can budget against — not an opinion.