Wie man ein Captive Portal erstellt: Ein Entwicklerhandbuch

Ein umfassender technischer Leitfaden für IT-Architekten und Netzwerkmanager zum Aufbau und zur Bereitstellung von Captive Portals. Dieser Leitfaden behandelt zugrunde liegende Protokolle, Authentifizierungsabläufe, Open-Source-Architekturen und einen Rahmen für die Entscheidung, wann man eine Unternehmensplattform selbst entwickeln oder kaufen sollte.

📖 6 Min. Lesezeit📝 1,311 Wörter🔧 2 Beispiele❓ 3 Fragen📚 8 Schlüsselbegriffe

🎧 Diesen Leitfaden anhören

Transkript anzeigen

How to Build a Captive Portal: A Developer's Guide
A Purple WiFi Intelligence Podcast — Approximately 10 Minutes

[INTRODUCTION & CONTEXT — 1 minute]

Welcome back. I'm speaking today as a senior solutions architect, and if you're listening to this, you're probably staring down a requirement to deploy guest WiFi at scale — a hotel group, a retail estate, a stadium, or perhaps a public-sector network — and someone has asked you: can we build this ourselves, or do we buy a platform?

That's exactly the question we're going to answer today. We'll cover what a captive portal actually does under the hood, walk through the open-source options available to you right now, explain the authentication flows and API integration patterns you need to understand, and give you a clear framework for deciding when to build versus when to buy. By the end of this, you'll have enough to brief your team and make a defensible decision this quarter.

Let's get into it.

[TECHNICAL DEEP-DIVE — 5 minutes]

First, the fundamentals. A captive portal is a network access control mechanism that intercepts unauthenticated HTTP or HTTPS traffic from a connected device and redirects it to a web-based authentication page — what most users know as the WiFi login splash screen. The underlying mechanics rely on a combination of DNS hijacking, HTTP 302 redirects, and firewall rules that block all outbound traffic until the authentication handshake completes.

When a device connects to your SSID, it typically sends an HTTP probe request — a lightweight check to see whether the network is open or gated. Your access point or gateway intercepts that probe and returns a redirect to your splash page URL. The user completes whatever authentication method you've configured — email capture, social login, SMS OTP, or a voucher code — and your portal then signals the network controller to open the firewall rule for that device's MAC address or IP. That's the core loop.

Now, the standards that govern this are worth knowing. The IEEE 802.11 standard covers the wireless layer, but the captive portal detection and redirection behaviour is largely governed by RFC 7710 and the CAPPORT working group's RFC 8908 and RFC 8910, which define the Captive Portal API — a structured, machine-readable way for devices to discover and interact with captive portals. If you're building from scratch in 2024, you should be implementing the CAPPORT API rather than relying purely on legacy HTTP redirect tricks, because modern iOS and Android devices handle it more gracefully and you'll see fewer authentication failures.

On the authentication side, you have several patterns to choose from. The simplest is a click-through or terms-of-service acceptance — no credentials required, just a button press. This is compliant with basic regulatory requirements in many jurisdictions but gives you no guest identity data. One step up is email gating — the guest enters their email address, you validate it optionally via a confirmation link, and you capture a marketing consent record. This is where GDPR becomes directly relevant: you need a lawful basis for processing that data, a clear consent mechanism, and a documented retention policy. If you're operating in the UK or EU, this is non-negotiable.

For higher-security environments — corporate guest networks, healthcare facilities, or any deployment that touches PCI DSS scope — you'll want IEEE 802.1X port-based authentication with a RADIUS back-end. The flow here is: device associates with the SSID, the access point acts as a RADIUS client and forwards the authentication request to your RADIUS server — FreeRADIUS is the most widely deployed open-source option — the RADIUS server validates credentials against your directory, and returns an Access-Accept or Access-Reject. You can layer EAP methods on top of this: EAP-TLS for certificate-based auth, PEAP for username and password with a server-side certificate. WPA3-Enterprise with 192-bit mode is the current gold standard for high-security deployments.

Now, let's talk about the open-source landscape, because there are real options here. pfSense with its built-in captive portal module is a solid starting point for single-site deployments — it handles RADIUS integration, per-user bandwidth throttling, and basic session management. OpenWRT with Nodogsplash is lightweight and works well on embedded hardware, but it has limited social authentication support and minimal GDPR tooling. Coova-Chilli is a more mature option — it implements the WISPr protocol, supports RADIUS, and can be extended with plugins for social login. PacketFence is the most feature-complete open-source network access control platform — it handles 802.1X, social auth, and has reasonable compliance tooling, though the operational overhead is significant.

The honest assessment: open-source captive portal software gives you the authentication plumbing, but it leaves you to build everything else — the splash page UI, the data capture forms, the consent management, the analytics pipeline, the CRM integrations, and the ongoing compliance posture. For a single venue with a small IT team, that's a manageable project. For a 50-site retail estate or a hotel group with 200 properties, the total cost of ownership of a self-built stack almost always exceeds a managed platform within 18 months.

That's where platforms like Purple come in. Purple's guest WiFi platform sits on top of your existing network infrastructure — it's hardware-agnostic, so it works with Cisco Meraki, Aruba, Ruckus, Ubiquiti, and most enterprise access point vendors. It handles the splash page, the authentication flows, the consent management, the data capture, and then feeds that data into a WiFi analytics layer that gives you footfall heatmaps, dwell time analysis, repeat visitor rates, and direct integrations with marketing automation platforms. For a hospitality operator, that means connecting guest WiFi data to your PMS and CRM. For a retailer, it means correlating footfall data with sales transactions.

[IMPLEMENTATION RECOMMENDATIONS & PITFALLS — 2 minutes]

Let me give you the implementation framework I use when advising clients on this decision.

Start with your compliance requirements. If you're in scope for PCI DSS — and any venue that processes card payments on the same network as guest WiFi potentially is — you need network segmentation as a baseline, and your captive portal needs to sit on an isolated VLAN. GDPR compliance requires consent records with timestamps, a clear privacy notice linked from the splash page, and a documented data retention schedule. Don't bolt these on after the fact.

Second, think about your authentication method relative to your audience. A stadium with 60,000 concurrent connections needs a lightweight click-through or social login — anything that adds friction at that scale will result in support calls and abandoned connections. A conference centre with 500 delegates who need to be individually tracked for compliance purposes needs email gating with verification. A hospital guest network needs 802.1X with certificate-based auth and strict VLAN segmentation from clinical systems.

Third, plan your API integration points before you write a line of code. If you're building custom, define your webhook endpoints for authentication events, your data schema for guest records, and your integration contracts with downstream systems — CRM, marketing automation, analytics — before you start on the portal UI. Retrofitting integrations is where self-build projects typically go over budget.

The most common failure modes I see: DNS rebinding attacks on poorly configured portals — always validate redirect URLs server-side. MAC address spoofing — don't rely on MAC as your sole session identifier. HTTPS interception issues — modern browsers and apps increasingly refuse to follow captive portal redirects on HTTPS connections, which is why implementing the CAPPORT API is important. And finally, bandwidth management — if you don't implement per-device rate limiting, a single guest running a software update can degrade the experience for everyone else on the network.

[RAPID-FIRE Q&A — 1 minute]

Can I use a Raspberry Pi as a captive portal gateway? Yes, with OpenWRT or Coova-Chilli for a single small venue — but don't put it in production at scale.

Do I need a RADIUS server for social login? No — social OAuth flows bypass RADIUS entirely. You need RADIUS for 802.1X certificate or credential-based authentication.

Is WPA3 mandatory for new deployments? Not legally mandatory, but it should be your default for any new infrastructure procurement. WPA2 is still widely supported but has known vulnerabilities.

How do I handle Apple's Captive Network Assistant? Implement the CAPPORT API and ensure your splash page loads cleanly within the CNA browser window — avoid JavaScript redirects that the CNA can't follow.

[SUMMARY & NEXT STEPS — 1 minute]

To summarise: building a captive portal from scratch is entirely feasible with open-source tools like pfSense, Coova-Chilli, or PacketFence — but the build cost is only part of the equation. The ongoing cost of maintaining compliance, integrating with marketing systems, and scaling across multiple sites is where self-build projects typically struggle.

For most enterprise venue operators, the right answer is a managed platform that handles the authentication plumbing, the compliance layer, and the analytics pipeline — and exposes a clean API for custom integrations where you need them.

If you want to go deeper on the technical architecture, there's a full written guide linked in the show notes — it covers the CAPPORT API implementation, RADIUS configuration, and GDPR consent flow in detail. And if you're evaluating Purple's platform, the guest WiFi and analytics documentation is a good starting point for understanding what the integration looks like in practice.

Thanks for listening. Until next time.

Zusammenfassung für Führungskräfte

Für Unternehmensnetzwerkarchitekten und IT-Direktoren ist die Bereitstellung eines Captive Portals selten nur eine Netzwerkübung – es ist eine kritische Schnittstelle von Netzwerksicherheit, Einhaltung gesetzlicher Vorschriften und Business Intelligence. Ob Sie ein Hospitality -Portfolio mit 200 Objekten, ein weitläufiges Retail -Immobilienportfolio oder ein Stadion mit hoher Dichte verwalten, die Entscheidung, ein benutzerdefiniertes Captive Portal zu erstellen oder eine verwaltete Plattform bereitzustellen, hat tiefgreifende Auswirkungen auf die Gesamtbetriebskosten (TCO) und das Betriebsrisiko.

Dieser Leitfaden bietet einen herstellerneutralen, technischen Einblick in die Architektur von Captive Portals. Wir werden die zugrunde liegenden HTTP-Umleitungsmechanismen, die moderne Captive Portal API (RFC 8908), 802.1X RADIUS-Authentifizierungsabläufe und die führenden Open-Source-Optionen untersuchen. Entscheidend ist, dass wir einen Rahmen für die Bewertung bieten, wann ein selbstgebauter Open-Source-Stack sinnvoll ist und wann der Compliance- und Integrationsaufwand eine Unternehmensplattform wie die Guest WiFi -Lösung von Purple erfordert.

Hören Sie sich unser begleitendes Audio-Briefing für einen strategischen Überblick an:

Technischer Einblick: Wie Captive Portals funktionieren

Bevor Softwareoptionen bewertet werden, ist es unerlässlich, die grundlegenden Netzwerkmechanismen zu verstehen. Ein Captive Portal ist im Wesentlichen ein Netzwerkzugriffskontrollmechanismus (NAC), der nicht authentifizierten HTTP/HTTPS-Verkehr abfängt und eine Umleitung zu einer webbasierten Authentifizierungsschnittstelle erzwingt.

Das ältere Abfangmodell

Historisch gesehen basierten Captive Portals auf einer Kombination aus DNS-Hijacking und HTTP 302-Weiterleitungen. Wenn sich ein Gastgerät mit einer SSID verbindet, sendet der Captive Network Assistant (CNA) des Betriebssystems eine Probe-Anfrage an einen bekannten Endpunkt (z.B. captive.apple.com für iOS).

DNS-Abfangen: Das lokale Gateway fängt die DNS-Anfrage für die Probe-URL ab und löst sie in die IP-Adresse des Captive Portals auf.
HTTP-Weiterleitung: Wenn kein DNS-Abfangen verwendet wird, fängt das Gateway die ausgehende HTTP GET-Anfrage ab und gibt einen HTTP 302 Found zurück, der den Client auf die Splash-Seite umleitet.
Firewall Walled Garden: Der gesamte andere ausgehende Datenverkehr wird von der Gateway-Firewall blockiert, bis die Authentifizierung abgeschlossen ist. Nur der Datenverkehr zum Portal und zu genehmigten externen Ressourcen (dem „Walled Garden“) ist erlaubt.

Für eine detailliertere Aufschlüsselung dieser Mechanismen siehe unseren Leitfaden: Wie funktioniert ein Captive Portal? Technischer Einblick .

Der moderne Standard: RFC 8908 (CAPPORT API)

Das ältere Abfangmodell hat Schwierigkeiten mit modernen HTTPS-überall-Architekturen. Browser kennzeichnen abgefangenen HTTPS-Verkehr zu Recht als Man-in-the-Middle (MitM)-Angriff, was zu Zertifikatswarnungen anstelle einer sauberen Splash-Seite führt.

Um dies zu lösen, entwickelte die IETF CAPPORT Arbeitsgruppe RFC 8908 und RFC 8910. Anstatt den Datenverkehr abzufangen, bewirbt das Netzwerk explizit die Präsenz eines Captive Portals über DHCP (Option 114) oder IPv6 Router Advertisements. Das Client-Gerät fragt eine JSON API ab, um die Portal-URL und ihren aktuellen Authentifizierungsstatus zu ermitteln. Wenn Sie ein modernes Portal erstellen, ist die Implementierung der CAPPORT API entscheidend für eine nahtlose Benutzererfahrung auf modernen iOS- und Android-Geräten.

Authentifizierungs- und Autorisierungsabläufe

Sobald die Splash-Seite bereitgestellt wird, bestimmt der Authentifizierungsablauf die Benutzererfahrung und die gesammelten Daten.

Click-Through (Nutzungsbedingungen): Der reibungsärmste Ansatz. Keine Anmeldeinformationen erforderlich, nur eine boolesche Akzeptanz der Bedingungen. Geeignet für Umgebungen mit hoher Dichte, in denen der Durchsatz gegenüber der Datenerfassung priorisiert wird.
Identitätserfassung (E-Mail/Sozial): Der Benutzer authentifiziert sich über OAuth (Google, Facebook) oder ein E-Mail-Formular. Dies erfordert eine sorgfältige Integration mit Identitätsanbietern und robuste GDPR-Konformitätsmechanismen.
802.1X und RADIUS: Für Umgebungen mit hoher Sicherheit (z.B. Healthcare oder Unternehmens-Gastnetzwerke) ist eine portbasierte Netzwerkzugriffskontrolle über IEEE 802.1X erforderlich. Der Access Point fungiert als RADIUS-Client und leitet Anmeldeinformationen an einen RADIUS-Server (wie FreeRADIUS) zur Validierung gegen einen Verzeichnisdienst weiter.

Implementierungsleitfaden: Open-Source vs. verwaltete Plattformen

Für Entwickler, die mit dem Aufbau eines Captive Portals beauftragt sind, bietet das Open-Source-Ökosystem mehrere robuste Grundlagen.

Diese Tools stellen jedoch die Netzwerk-Infrastruktur bereit, nicht die Geschäftslogik.

Führende Open-Source-Optionen

pfSense + Captive Portal: Eine beliebte Firewall-Distribution, die ein leistungsfähiges Captive Portal-Modul enthält. Es verwaltet die RADIUS-Integration, MAC-Adressfilterung und grundlegendes Bandbreiten-Shaping. Ideal für Einzelstandort-Bereitstellungen mit erfahrenen Netzwerktechnikern.
Coova-Chilli: Ein ausgereifter, funktionsreicher Access Controller, der das WISPr-Protokoll implementiert. Er zeichnet sich in komplexen RADIUS-Umgebungen aus und kann für Social Login erweitert werden, erfordert jedoch erhebliche Linux-Systemadministrationskenntnisse.
PacketFence: Eine umfassende Open-Source-NAC-Lösung. Sie unterstützt 802.1X, BYOD-Onboarding und die Integration mit Unternehmensverzeichnissen. Hoch skalierbar, aber mit einer steilen Lernkurve und erheblichem Betriebsaufwand verbunden.

Die „Selbst entwickeln vs. "Kauf"-Entscheidungsrahmen

Während Open-Source-Software "kostenlos" ist, steigen die Gesamtbetriebskosten für ein selbstgebautes Portal nicht-linear mit der Anzahl der Standorte und der Komplexität der Geschäftsanforderungen.

Wann selbst entwickeln:

Sie betreiben einen einzelnen Standort oder eine kleine Gruppe sehr homogener Standorte.
Ihre Anforderungen beschränken sich auf die grundlegende Akzeptanz von Nutzungsbedingungen oder einfachen WPA2-PSK-Zugang.
Sie verfügen über dedizierte, interne Linux- und Netzwerk-Engineering-Ressourcen.

Wann kaufen (Enterprise-Plattform):

Multi-Site-Skalierung: Sie implementieren über Dutzende oder Hunderte von Standorten mit unterschiedlicher zugrunde liegender Hardware (Cisco, Aruba, Meraki).
Compliance: Sie benötigen automatisiertes GDPR/CCPA-Einwilligungsmanagement, die Bearbeitung von Anträgen auf Auskunft durch betroffene Personen (DSAR) und nachweisbare Audit-Trails.
Business Intelligence: Sie müssen Netzwerkdaten in Marketingsysteme integrieren. Plattformen wie Purple bieten eine einheitliche WiFi Analytics -Schicht, die rohe MAC addresses in umsetzbare Frequenz- und Verweildauer-Metriken umwandelt.
Erweiterte Integrationen: Sie benötigen eine nahtlose Integration mit Property Management Systemen (PMS) oder Loyalitätsdatenbanken.

Ähnlich wie sich WAN-Architekturen von Unternehmen hin zu verwalteten SD-WAN-Lösungen entwickeln (siehe The Core SD WAN Benefits for Modern Businesses ), verlagert sich das Gast-WiFi von Unternehmen hin zu hardwareunabhängigen Cloud-Plattformen, die die Komplexität des Edge-Netzwerks abstrahieren.

Best Practices und Risikominderung

Wenn Sie eine Eigenentwicklung vorantreiben oder einen Anbieter evaluieren, stellen Sie sicher, dass diese architektonischen Best Practices erfüllt sind:

1. Netzwerksegmentierung und Sicherheit

Stellen Sie niemals ein Captive Portal im selben VLAN wie Ihr Unternehmens- oder Betriebstechnologie (OT)-Netzwerk bereit. Der Gastverkehr muss streng segmentiert werden. Wenn Ihr Standort Zahlungen verarbeitet (z.B. ein Transport -Hub mit Einzelhandelskonzessionen), führt eine fehlende Segmentierung des Gast-WiFi dazu, dass das gesamte Netzwerk in den PCI DSS-Geltungsbereich fällt, was die Compliance-Kosten erheblich erhöht.

2. Walled Garden Konfiguration

Ihr Walled Garden muss den Datenverkehr zu den für eine erfolgreiche Authentifizierung erforderlichen Domains explizit zulassen. Für Social Login bedeutet dies, den Zugriff auf accounts.google.com, graph.facebook.com und deren zugehörige CDNs zu erlauben. Ein falsch konfigurierter Walled Garden führt dazu, dass Benutzer auf einer leeren Splash Page hängen bleiben.

3. Bandbreiten- und Sitzungsmanagement

Implementieren Sie strenge Ratenbegrenzungen pro Benutzer und Sitzungs-Timeouts. Ein einzelner Benutzer, der ein großes OS-Update herunterlädt, kann den WAN-Uplink überlasten und die Erfahrung für alle Gäste beeinträchtigen. Verwenden Sie RADIUS-Attribute (z.B. WISPr-Bandwidth-Max-Down), um diese Grenzen dynamisch durchzusetzen.

4. MAC-Spoofing mindern

Sich ausschließlich auf MAC addresses für die Sitzungspersistenz zu verlassen, ist ein Sicherheitsrisiko, da MAC addresses leicht gefälscht werden können und moderne OS-Funktionen (wie iOS Private Wi-Fi Address) diese standardmäßig randomisieren. Stellen Sie sicher, dass Ihre Portalarchitektur die MAC-Randomisierung elegant handhaben kann, typischerweise indem eine erneute Authentifizierung erforderlich ist, wenn sich die MAC ändert, oder indem Passpoint/Hotspot 2.0 für nahtloses, sicheres Roaming genutzt wird.

ROI & Geschäftsauswirkungen

Ein Captive Portal sollte nicht nur als IT-Kostenstelle betrachtet werden; es ist ein kritischer Kanal zur Datenerfassung.

Bei korrekter Bereitstellung – oft über eine verwaltete Plattform – wird der ROI in drei Bereichen gemessen:

Wachstum der Marketingdatenbank: Ein nahtloser Onboarding-Flow mit klarem Wertetausch (z.B. "Kostenloses WiFi im Austausch für E-Mail") baut schnell eine konforme, erstklassige Marketingdatenbank auf.
Operative Intelligenz: Aus Verbindungsdaten abgeleitete Analysen liefern Standortbetreibern Heatmaps, Spitzenlastanalysen und Metriken zu wiederkehrenden Besuchern, die Personal- und Layoutentscheidungen direkt beeinflussen.
Risikoreduzierung: Ein zentralisiertes Compliance-Management reduziert das Risiko von behördlichen Bußgeldern im Zusammenhang mit unsachgemäßer Datenverarbeitung oder PCI DSS-Verstößen erheblich.

Letztendlich ist es das Ziel eines Entwicklers oder Architekten, ein sicheres, reibungsloses Netzwerkerlebnis zu liefern, das den strategischen Zielen des Unternehmens dient. Wählen Sie die Architektur, die es Ihrem Team ermöglicht, sich auf diese Ziele zu konzentrieren, anstatt die Infrastruktur zu verwalten.

Schlüsselbegriffe & Definitionen

Captive Portal

A web page that the user of a public-access network is obliged to view and interact with before access is granted.

The primary interface for guest network onboarding, used for terms acceptance, payment, or data capture.

RADIUS (Remote Authentication Dial-In User Service)

A networking protocol that provides centralized Authentication, Authorization, and Accounting (AAA) management for users who connect and use a network service.

The backend engine that validates credentials and tells the network equipment what permissions a guest should have.

Walled Garden

A limited environment that controls the user's access to external web content and services prior to full authentication.

Essential for allowing users to access identity providers (like Google or Facebook) to log in, before they have general internet access.

MAC Spoofing

The practice of altering a device's factory-assigned Media Access Control (MAC) address to masquerade as another device or bypass network restrictions.

A common method used to bypass captive portal time limits, requiring robust session management strategies to mitigate.

CAPPORT API (RFC 8908)

A modern IETF standard allowing devices to securely discover the captive portal URL and authentication status via DHCP or Router Advertisements, rather than relying on HTTP interception.

Critical for modern portal development to prevent HTTPS certificate errors and improve the user onboarding experience.

IEEE 802.1X

An IEEE Standard for port-based Network Access Control (PNAC), providing an authentication mechanism to devices wishing to attach to a LAN or WLAN.

Used in enterprise and high-security environments where simple web-based authentication is insufficient.

WISPr (Wireless Internet Service Provider roaming)

A draft protocol submitted to the Wi-Fi Alliance that allows users to roam between different wireless internet service providers.

Often implemented by access controllers to handle the XML-based authentication requests from the captive portal to the gateway.

VLAN Segmentation

The practice of partitioning a single layer-2 network to create multiple distinct broadcast domains.

A mandatory security practice to ensure guest WiFi traffic cannot access corporate or operational technology networks.

Fallstudien

A 200-room hotel needs to deploy guest WiFi. They require guests to authenticate using their room number and last name to access a premium bandwidth tier, while non-guests receive a throttled 2Mbps connection. The underlying network uses Cisco Meraki access points.

Configure the Meraki SSID to use an external captive portal (Splash page URL pointing to the custom portal). 2. Set up a RADIUS server (e.g., FreeRADIUS) and configure the Meraki APs as RADIUS clients. 3. Develop the captive portal web application to present a login form requesting Room Number and Last Name. 4. Integrate the portal backend with the hotel's Property Management System (PMS) via API. When credentials are submitted, the portal queries the PMS to validate the guest. 5. Upon successful validation, the portal backend sends a RADIUS Access-Accept message to the Meraki controller, including Vendor-Specific Attributes (VSAs) to apply the 'Premium' group policy (unthrottled bandwidth). 6. For non-guests, provide a 'Free Access' button that bypasses the PMS check and returns a RADIUS Access-Accept with VSAs applying the 'Throttled' group policy.

Implementierungshinweise: This approach correctly separates the network layer (Meraki) from the business logic (PMS integration). By utilizing RADIUS VSAs, the network dynamically applies bandwidth shaping based on the user's identity tier, satisfying the core requirement while maintaining a centralized control plane.

A national retail chain with 50 locations wants to implement a captive portal to collect customer emails for marketing. They are concerned about GDPR compliance and the operational overhead of managing 50 separate local portal instances.

Instead of deploying local captive portal software (like pfSense) at each site, deploy a centralized, cloud-hosted captive portal platform (like Purple). Configure the local branch routers/APs to redirect guest traffic to the centralized portal URL. Implement a standardized splash page with explicit opt-in checkboxes for marketing consent and a link to the privacy policy. The centralized platform handles the capture, timestamping, and secure storage of consent records, and integrates directly via API with the retailer's central CRM system.

Implementierungshinweise: A centralized architecture is essential for multi-site retail. Attempting to manage compliance and data aggregation across 50 distributed open-source instances is highly risky and operationally inefficient. The centralized platform ensures uniform compliance posture and real-time data synchronization.

Szenarioanalyse

Q1. You are deploying a captive portal in an airport. The primary goal is maximum throughput and minimizing support tickets from users unable to connect. Which authentication method should you prioritize?

💡 Hinweis:Consider the friction involved in verifying identities versus simply gaining legal consent.

Empfohlenen Ansatz anzeigen

A Click-Through (Terms of Service) portal. In high-density transit environments, requiring email verification or SMS OTP introduces significant friction and relies on external dependencies (cellular reception for SMS, existing email access). A simple Terms of Service acceptance minimizes support overhead while meeting basic legal requirements.

Q2. Your security team reports that users are bypassing the 2-hour free WiFi limit by changing their device's MAC address. How should you architect the network to mitigate this?

💡 Hinweis:MAC addresses are layer-2 identifiers that can be easily spoofed. You need a layer-7 identity verification.

Empfohlenen Ansatz anzeigen

Shift from a purely MAC-based session tracking model to an identity-based model. Require users to authenticate via a unique identifier (e.g., SMS OTP or a verified email address) and tie the session limit to that identity in the RADIUS backend, rather than the device's MAC address.

Q3. A hospital requires a guest WiFi network for patients and visitors. They also need a separate network for medical IoT devices. What is the most critical architectural requirement?

💡 Hinweis:Consider the impact if a compromised guest device could reach a medical device.

Empfohlenen Ansatz anzeigen

Strict VLAN segmentation. The guest WiFi network must be placed on a completely isolated VLAN that has no routing path to the clinical or IoT networks. The captive portal and guest traffic must be firewalled and routed directly to the internet.