Guía de configuración de WiFi para invitados empresariales: segmentación de VLAN, seguridad y Captive Portals

Enterprise Guest WiFi Setup Guide: VLAN Segmentation, Security, and Captive Portals. A Purple technical briefing for IT managers, network architects, and venue operations directors. Introduction and Context. Welcome. If you are responsible for a hotel, a retail estate, a stadium, or any venue where members of the public connect to your WiFi, this briefing is for you. We are going to cover the three pillars of a properly architected guest WiFi deployment: VLAN segmentation, security standards, and captive portal design. Not theory - practical, actionable guidance you can take into your next infrastructure review. Let me set the context first. Guest WiFi is no longer a nice-to-have. It is an operational requirement and, when done correctly, a significant source of first-party customer data. Purple operates across more than 80,000 live venues globally, and in 2024 alone we processed 440 million logins. The patterns we see across those deployments tell a very clear story: the venues that treat guest WiFi as a serious infrastructure project, rather than an afterthought, are the ones that avoid security incidents, stay compliant with GDPR, and actually extract business value from the data they collect. So. Let us get into it. Technical Deep-Dive. Part one: VLAN segmentation. A VLAN, Virtual Local Area Network, is a logical partition of your physical network. Think of it as creating separate lanes on the same road. Guests travel in one lane. Staff travel in another. Your corporate systems travel in a third. The lanes do not cross. Why does this matter? Without VLAN segmentation, a guest device on your WiFi sits on the same network segment as your point-of-sale terminals, your back-office servers, or your property management system. That is a serious security exposure. A compromised guest device, or a malicious actor deliberately probing your network, can reach systems they have absolutely no business touching. The standard approach is to assign each traffic type its own VLAN ID. VLAN 10 for guest WiFi, VLAN 20 for staff, VLAN 30 for corporate infrastructure. The specific numbers are arbitrary, but the separation is not. Each VLAN gets its own IP subnet, its own DHCP scope, and its own firewall policy. Guest traffic routes directly to the internet. It never touches your internal network. On the hardware side, this is supported natively by all the major enterprise access point vendors: Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet. Every one of those platforms lets you map an SSID to a VLAN tag, and every managed switch in your stack will honour that tag to keep traffic separated all the way to the core. One configuration detail worth highlighting: client isolation. Within the guest VLAN itself, you want to prevent guest devices from communicating with each other. A guest's laptop should not be able to see another guest's phone. Enable client isolation on your access points. It is a single checkbox in most enterprise management consoles, and you eliminate an entire class of peer-to-peer attack. Part two: security standards. Let us talk encryption. WPA3, Wi-Fi Protected Access 3, is the current standard, ratified by the Wi-Fi Alliance. For guest networks, the relevant mode is WPA3-SAE, which replaces the older WPA2-PSK handshake with a more secure Simultaneous Authentication of Equals protocol. This eliminates offline dictionary attacks against captured handshakes. If your hardware supports it, and anything purchased in the last three years almost certainly does, deploy WPA3. For staff and corporate networks, the correct standard is 802.1X, which is the IEEE framework for port-based network access control. 802.1X requires each device to authenticate against a RADIUS server, Remote Authentication Dial-In User Service, before it is granted network access. The authentication exchange uses EAP, Extensible Authentication Protocol, with the most common enterprise variants being EAP-TLS, which uses mutual certificate-based authentication, and PEAP, which wraps a username-and-password exchange inside a TLS tunnel. EAP-TLS is the stronger option. It requires a client certificate on every device, which means you need a PKI, Public Key Infrastructure, to issue and manage those certificates. For large enterprise deployments with Microsoft Entra ID or Okta, this integrates cleanly with your existing certificate authority. PEAP is easier to deploy and still significantly more secure than a shared password. For guest networks, 802.1X is typically impractical. Guests do not have corporate certificates. The alternative is iPSK or PPSK: individual or private pre-shared keys. Each guest session gets a unique key, which means you can revoke a single session without changing the password for everyone. Purple's platform automates this entirely: when a guest authenticates through the captive portal, the system generates and assigns a unique session key automatically. Now, compliance. If your venue processes card payments anywhere near the network, PCI DSS, the Payment Card Industry Data Security Standard, applies. Requirement 1.3 mandates network segmentation between cardholder data environments and all other systems. A properly configured guest VLAN satisfies this requirement, provided you document the segmentation and include it in your annual assessment. GDPR applies to the personal data you collect at the captive portal: name, email address, marketing consent. We will come back to that in the captive portal section. Part three: captive portals. A captive portal is the web page that intercepts a guest's browser when they first connect to your WiFi, before granting internet access. It is the mechanism through which you collect consent and identity data. Here is how it works technically. When a guest connects to your SSID, their device is placed in a pre-authentication state. DNS queries resolve, but all HTTP traffic is redirected to the portal's IP address. The guest sees your branded login page. Once they authenticate, by email, social login, or SMS verification, the RADIUS server or the WiFi controller marks their MAC address as authorised and opens internet access. There are several authentication methods available. Email registration is the most common and captures a verified email address directly. Social login via Google, Facebook, or Apple is lower friction but depends on the guest having an active social account. SMS verification adds a phone number to your dataset. For higher-security environments, you can require identity verification through Purple's Verify add-on, which checks government ID documents. The GDPR dimension here is critical. Every data point you collect at the portal requires a lawful basis. For marketing communications, that basis is explicit consent: a conscious-choice opt-in, not a pre-ticked box. Your portal must present clear, plain-language consent statements, link to your privacy policy, and record the timestamp and version of the consent given. Purple's platform stores all of this automatically and provides a full audit trail, which is exactly what a data protection authority will ask for if you ever face an investigation. One design principle that significantly affects both compliance and data quality: keep the portal simple. Every additional field you add reduces completion rates. Name and email, with a clear marketing consent checkbox, is the right balance for most venues. Purple's data across 350 million unique users shows that portals with three fields or fewer convert at significantly higher rates than those with five or more. Implementation Recommendations and Pitfalls. Let me give you the practical recommendations, and then flag the most common mistakes we see. For a new deployment, work in this sequence. First, design your VLAN architecture before you touch any hardware. Map out which traffic types exist in your venue, assign VLAN IDs, define subnets, and document firewall rules between segments. Second, configure your core switch and router to enforce inter-VLAN routing policies. Guest traffic should have a default route to the internet and a deny-all rule for everything else. Third, configure your access points to map each SSID to the correct VLAN. Fourth, deploy your captive portal and test the full authentication flow end-to-end before going live. Fifth, run a penetration test or at minimum a manual verification that a device on the guest VLAN cannot reach any internal IP address. The most common mistakes. Number one: forgetting to enable client isolation. Guests can see each other's devices, which is a privacy issue and a potential attack vector. Number two: using the same pre-shared key for guest WiFi for years without rotation. If that key leaks, every device that has ever connected to your network has it. Use iPSK or PPSK and automate rotation. Number three: deploying a captive portal without proper GDPR consent mechanisms. This is not a theoretical risk. Regulators across Europe have issued fines for exactly this. Number four: not logging session data. For security incident response, you need to know which MAC address was assigned which IP address at what time. Your RADIUS server or WiFi controller should log this, and you should retain it for at least 90 days. Number five: treating guest WiFi bandwidth as unlimited. Set per-user bandwidth limits on the guest VLAN. Without them, a single guest running a torrent client can degrade the experience for everyone in the venue. Rapid-Fire Questions and Answers. Question: Do I need a separate physical network for guests, or is VLAN segmentation enough? Answer: VLAN segmentation is sufficient for the vast majority of deployments, provided your switches and access points are enterprise-grade and correctly configured. Consumer or prosumer hardware sometimes has incomplete VLAN support. That is a reason to use enterprise hardware, not to run separate physical cables. Question: Can I run guest WiFi on the same access points as staff WiFi? Answer: Yes. Enterprise access points support multiple SSIDs, each mapped to a different VLAN. A single Cisco Meraki or HPE Aruba access point can broadcast four or more SSIDs simultaneously, each with independent security policies. Question: What is the minimum viable security configuration for a small venue? Answer: VLAN separation between guest and internal traffic, WPA3 on the guest SSID, client isolation enabled, and a captive portal with GDPR-compliant consent collection. That covers the fundamentals. Question: How does Purple integrate with existing hardware? Answer: Purple is hardware-agnostic. We operate as a cloud overlay on top of Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet deployments. You keep your existing infrastructure and add Purple's captive portal, analytics, and marketing automation on top. Summary and Next Steps. To summarise. Proper guest WiFi architecture has three non-negotiable components. VLAN segmentation to isolate guest traffic from your internal network. Strong encryption and authentication standards: WPA3 for guests, 802.1X with EAP-TLS for staff. And a captive portal that collects identity data with full GDPR compliance. Get these three things right, and you have a network that is secure, compliant, and generating first-party data that your marketing team can actually use. If you want to go deeper, Purple's platform handles the captive portal, the analytics, and the marketing automation layer across all of this. We are live in more than 80,000 venues, we are ISO 27001 certified, GDPR and CCPA compliant, and we maintain 99.999% uptime. The guides linked below this episode cover specific hardware integrations and advanced configurations. Thanks for listening. If you have questions, the Purple team is at purple.ai.