Sophos Firewall Captive Portal einrichten und testen

Das Captive Portal meldet Benutzer an, die bereits mit einem LAN oder WLAN verbunden sind. Danach kann die Sophos Firewall deren Traffic einer Benutzeridentität zuordnen und Regeln für bestimmte Benutzer oder Gruppen anwenden.

Wichtig ist das Zusammenspiel: Das Portal erzeugt die Benutzerzuordnung, erlaubt aber nicht selbst den Internetzugriff. Dafür braucht es zusätzlich eine passende Firewall-Regel. Auch DNS, Routing, NAT und die Netztrennung müssen unabhängig davon funktionieren.

Der vollständige Ablauf lässt sich auf sechs Schritte reduzieren:

1. Authentifizierungsquelle und erlaubte Gruppe prüfen.
2. Captive Portal unter Administration > Device access für die Clientzone freigeben.
3. Bei einem externen DNS-Server eine schmale DNS-Regel ohne Benutzerbezug erstellen.
4. Benutzerregel mit Match known users und Use web authentication for unknown users anlegen.
5. Unter Authentication > Web authentication HTTPS, Zielseite und Abmeldung festlegen.
6. Login über Port 8090, Benutzer unter Live users und die Rule ID im Log Viewer kontrollieren.

Was Captive Portal leistet – und was nicht

Captive Portal passt für BYOD-Geräte, nicht verwaltete Clients oder Netze, in denen keine transparente Benutzererkennung verfügbar ist. Der Benutzer öffnet eine Webseite, wird zur Anmeldung umgeleitet und ist danach auf der Firewall mit seiner Quell-IP verknüpft. Diese Identität kann die Firewall als Match-Kriterium verwenden.

Andere Portal- und Authentifizierungsarten lösen andere Aufgaben:

• Ein Wireless Hotspot ist für Gästezugänge mit Voucher, Tagespasswort oder Nutzungsbedingungen gedacht. Der vollständige Ablauf steht unter Sophos Firewall Hotspot einrichten.
• Ein Guest user ist ein zeitlich begrenztes lokales Konto für das Captive Portal. Gastbenutzer erstellen und sicher betreiben erklärt Gruppe, Gültigkeit, Ausgabe, Selbstregistrierung und Bereinigung.
• Das VPN Portal gehört zu Remote Access. Captive Portal baut keinen VPN-Tunnel auf und sollte nicht als öffentliches Loginportal verwendet werden.
• STAS, AD SSO oder SATC erkennen Benutzer möglichst ohne Browser-Login. Captive Portal kann in solchen Umgebungen ein Fallback für Geräte sein, bei denen die transparente Erkennung nicht greift.
• Für einen Microsoft-Login gilt der separate Ablauf Captive Portal mit Microsoft Entra ID SSO.

Die Übersicht der Sophos Portale hilft, wenn User Portal, VPN Portal, WebAdmin und Captive Portal noch nicht klar voneinander getrennt sind.

⚠️ Captive Portal ersetzt keine Segmentierung. Ein BYOD- oder Gastnetz bleibt in einer eigenen Zone oder einem eigenen VLAN und erhält nur die wirklich benötigten Ziele und Services. Die Anmeldung verbessert die Benutzerzuordnung, macht ein zu breites Netz aber nicht automatisch sicher.

Voraussetzungen und Beispiel

Vor der Konfiguration sollten folgende Punkte feststehen:

• Eine lokale oder externe Authentifizierungsquelle funktioniert. Bei Active Directory sind Serververbindung und Gruppe bereits geprüft; die Einrichtung erklärt Active Directory mit Sophos Firewall verbinden.
• Clientzone, Quellnetz und erlaubte Benutzergruppe sind bekannt.
• Der Client erhält eine korrekte IP-Adresse, ein Gateway und funktionierende DNS-Server.
• Für den produktiven Portalnamen existieren ein DNS-Eintrag und ein von den Clients akzeptiertes Zertifikat.
• Eine bestehende MASQ-/SNAT-Regel und das Routing decken den später erlaubten Internettraffic ab.
• Ein erlaubter und ein nicht erlaubter Testbenutzer stehen für die Abnahme bereit.

Das Beispiel verwendet:

• Clientzone: LAN
• Clientnetz: 10.30.40.0/24
• Netzwerkobjekt: BYOD_10.30.40.0_24
• Firewall-IP der Clientzone: 10.30.40.1
• Benutzergruppe: BYOD_Internet
• Regelname: LAN-BYOD-to-WAN-Captive
• interner DNS-Server: 10.20.0.53
• Portalname: login.example.com

Diese Werte werden nicht ungeprüft übernommen. Zone und Netz müssen zum tatsächlichen Clientinterface passen, 10.30.40.1 wird durch dessen Firewall-IP ersetzt und die Gruppe muss aus der verwendeten Authentifizierungsquelle stammen. Der Portalname muss aus dem Clientnetz genau auf diese erreichbare Firewall-Adresse auflösen.

Captive Portal Schritt für Schritt einrichten

1. Authentifizierungsmethode auswählen

Unter Authentication > Services wird unter Firewall authentication methods festgelegt, welche Quellen die Firewall bei einer Anmeldung abfragt. Das kann die lokale Benutzerdatenbank oder ein bereits eingerichteter AD-, LDAP- oder RADIUS-Server sein. Normale lokale Benutzer anlegen und testen beschreibt Gruppe, Passwort, Local, Sign-in Restriction und Lifecycle dieses Modells. Die Reihenfolge ist relevant: Bei mehreren Servern prüft SFOS sie von oben nach unten.

Für das Beispiel muss die Gruppe BYOD_Internet auf der Firewall vorhanden sein. Bei Active Directory wird sie vorher importiert. Erst danach kann sie in der Benutzerregel ausgewählt und beim Test eindeutig zugeordnet werden.

Eine erfolgreiche Serververbindung allein genügt noch nicht. Ob Kennwort, Gruppe und Benutzerregel gemeinsam funktionieren, wird deshalb später mit einem echten Portal-Login geprüft.

2. Captive Portal für die Quellzone erlauben

Unter Administration > Device access in der Zeile Captive portal nur die Zonen aktivieren, aus denen sich Benutzer wirklich anmelden sollen. Im Beispiel ist dies LAN. Danach mit Apply speichern.

Device Access steuert den Zugriff auf einen lokalen Dienst der Firewall. Eine normale LAN-to-WAN-Regel kann diese Freigabe nicht ersetzen. Umgekehrt sollte Captive Portal nicht vorsorglich für WAN oder unbeteiligte interne Zonen geöffnet werden. Device Access und Local Service ACL erklärt auch den Web-Proxy-Sonderfall, bei dem lokale Portale trotz einer engeren Zonentabelle erreichbar sein können.

Verwenden die Clients die Firewall selbst als DNS-Resolver, muss in derselben Matrix auch DNS für ihre Zone erlaubt sein. Bei einem separaten DNS-Server ist stattdessen die folgende Transitregel nötig.

3. DNS vor der Anmeldung ermöglichen

Ein Browser kann login.example.com oder die ursprünglich gewünschte Webseite nur öffnen, wenn DNS bereits vor der Benutzeranmeldung funktioniert. Liegt der DNS-Server nicht auf der Firewall, wird unter Rules and policies > Firewall rules > Add firewall rule > New firewall rule eine eigene Regel erstellt:

• Action: Accept
• Source zones: LAN
• Source networks and devices: BYOD_10.30.40.0_24
• Destination zones: Zone des DNS-Servers
• Destination networks: Hostobjekt für 10.20.0.53
• Services: DNS
• Log firewall traffic: für die Abnahme aktivieren

Diese Regel erhält keinen Benutzerbezug, weil der Client zu diesem Zeitpunkt noch nicht authentifiziert ist. Erlaubt wird nur DNS zum vorgesehenen Resolver, nicht beliebiger Traffic vor dem Login. Nutzt die Umgebung mehrere DNS-Server, werden deren Hostobjekte gezielt aufgenommen.

Die DNS-Regel wird so positioniert, dass sie den Resolver bereits vor der Anmeldung erreicht. Im Beispiel steht sie unmittelbar vor der Benutzerregel und oberhalb jeder allgemeineren Regel, die DNS aus diesem Netz verwerfen oder anders verarbeiten würde. Danach mit Save speichern.

4. Benutzerregel erstellen

Nun wird die eigentliche Nutzregel angelegt. Im Beispiel erhält sie folgende Werte:

• Rule name: LAN-BYOD-to-WAN-Captive
• Action: Accept
• Source zones: LAN
• Source networks and devices: BYOD_10.30.40.0_24
• Destination zones: WAN
• Destination networks: die benötigten Internetziele oder Any
• Services: nur die benötigten Services
• Match known users: aktiviert
• Use web authentication for unknown users: aktiviert
• Users or groups: BYOD_Internet
• Log firewall traffic: aktiviert

Match known users macht die Identität zum Match-Kriterium. Use web authentication for unknown users sorgt dafür, dass eine passende, noch nicht authentifizierte Webanfrage zum Login führt. Die Gruppe bestimmt, wer die Regel nach erfolgreicher Anmeldung verwenden darf.

Bei Services ist Any nur dann sinnvoll, wenn die Gruppe nach dem Login wirklich vollständigen Client-Internetzugriff erhalten soll. Für einen engeren Zugang werden HTTP, HTTPS und weitere benötigte Protokolle bewusst ausgewählt. Nicht-webbasierter Traffic kann selbst keine Loginseite anzeigen; der Benutzer muss die Anmeldung zuerst mit einem Browser oder über die direkte Portal-URL auslösen.

Die Regel muss oberhalb einer breiten IP-basierten Allow-Regel stehen. Andernfalls wird der Traffic bereits vorher verarbeitet und erreicht die Benutzerregel gar nicht. Nach der Prüfung der Position mit Save speichern. Die grundlegende Auswertung erklärt Firewall-Regeln richtig planen.

5. HTTPS, Redirect und Abmeldung festlegen

Unter Authentication > Web authentication wird nicht die Erreichbarkeit des Portals aktiviert, sondern dessen Verhalten eingestellt.

Für eine produktive Konfiguration sind diese Entscheidungen wichtig:

• Use insecure HTTP instead of HTTPS bleibt deaktiviert. HTTP würde Zugangsdaten unverschlüsselt übertragen und funktioniert nicht mit Entra ID SSO.
• Show web page after sign-in kann den Benutzer zur ursprünglich gewünschten oder zu einer definierten internen Seite weiterleiten.
• Open web page: In new browser window lässt die Captive-Portal-Seite für Logout und Keepalives geöffnet. Wird dieselbe Registerkarte ersetzt, ist der Abmeldeablauf für Benutzer weniger sichtbar.
• When captive portal page is closed or redirected meldet den Benutzer ab, wenn die Firewall keine Keepalives mehr erhält. Das kann auch nach Sleep oder einem Netzwechsel passieren.
• When user is inactive passt besser, wenn eine Session nach einem festgelegten Inaktivitätskriterium enden soll.
• Never verlangt eine manuelle Abmeldung und kann veraltete Benutzer-IP-Zuordnungen länger bestehen lassen.

Es gibt keinen universell richtigen Timeout. Bei gemeinsam verwendeten Geräten und wechselnden Benutzern sind kürzere Sessions wichtiger; bei persönlich zugeordneten Geräten darf die Anmeldung weniger störend sein. Jede Wahl wird mit Sleep, WLAN-Wechsel und manueller Abmeldung getestet. Für Entra ID SSO gelten diese lokalen Sign-out-Optionen nicht.

Nach der Auswahl mit Apply speichern.

6. Portalname und Zertifikat prüfen

Die direkte Diagnose-URL lautet:

https://<Firewall-IP>:8090

Im Beispiel kann man zunächst https://10.30.40.1:8090 öffnen. Für den produktiven Betrieb ist https://login.example.com:8090 verständlicher, sofern der Name auf die Firewall auflöst und im Zertifikat enthalten ist.

Die IP-Adresse eignet sich nur für den Erreichbarkeitstest. Deckt das ausgewählte Zertifikat ausschliesslich login.example.com ab, zeigt der Browser beim Aufruf über 10.30.40.1 erwartungsgemäss eine Namenswarnung. Ob DNS und Zertifikat korrekt zusammenspielen, wird deshalb immer über den FQDN geprüft.

Die Einstellungen liegen unter Administration > Admin and user settings > Admin console and end-user interaction. Unter Redirect users wird Firewall’s configured hostname oder A different hostname gewählt; für das Beispiel wird dort login.example.com eingetragen. Unter Certificate folgt das Zertifikat, das diesen Namen abdeckt. Die Zertifikatsauswahl betrifft nicht nur Captive Portal, sondern auch andere lokale Firewall-Portale. Vor einem Wechsel deshalb WebAdmin, User Portal und VPN Portal mitprüfen.

Ein öffentlich vertrauenswürdiges Zertifikat vermeidet Warnungen auf nicht verwalteten Geräten. Bei einer internen oder von der Firewall signierten CA muss die CA auf allen Clients als vertrauenswürdig installiert sein. Zertifikatsname, vollständige Kette und sichere Zuweisung erklärt Zertifikate auf Sophos Firewall verwalten.

Login und Benutzerregel vollständig testen

Die Abnahme beginnt mit einem Client ohne bestehende Sitzung. Unter Current activities > Live users kann eine alte Testsitzung bei Bedarf getrennt werden.

1. Prüfen, ob der Client eine Adresse aus 10.30.40.0/24, das geplante Gateway und den richtigen DNS-Server erhalten hat.
2. https://10.30.40.1:8090 direkt öffnen, um die Portal-Erreichbarkeit unabhängig von einem automatischen Browser-Redirect zu prüfen. Eine Namenswarnung ist dabei erwartbar, wenn das Zertifikat nur login.example.com enthält. Anschliessend die FQDN-URL öffnen und damit DNS sowie Zertifikat validieren.
3. Ohne bestehende Sitzung eine normale HTTP-Seite öffnen und die Weiterleitung zum Captive Portal kontrollieren. Eine HTTPS-Seite mit gespeichertem HSTS-Verhalten ist dafür kein zuverlässiger Test.
4. Mit einem erlaubten Benutzer anmelden. Bei aktivierter lokaler Sophos-MFA muss der OTP-Token zuvor im User Portal registriert sein. Die Einrichtung steht unter MFA für Sophos Firewall aktivieren.
5. Unter Current activities > Live users Benutzername, Client-IP und Authentifizierungstyp kontrollieren.
6. Eine erlaubte Webseite und bewusst ein nicht freigegebenes Ziel oder einen nicht erlaubten Service testen.
7. Im Log Viewer nach der Client-IP filtern. Der Eintrag muss den erwarteten Benutzer und die Rule ID von LAN-BYOD-to-WAN-Captive zeigen.
8. Mit einem Benutzer ausserhalb von BYOD_Internet prüfen, dass die Anmeldung keinen Zugriff über diese Regel gewährt.
9. Abmeldung, Sleep oder Netzwechsel auslösen und kontrollieren, wann der Benutzer aus Live users verschwindet.

In einem Dual-Stack-Netz wird der Test für IPv4 und IPv6 separat durchgeführt. SFOS führt die beiden Benutzerzuordnungen getrennt; ein erfolgreicher IPv4-Test beweist deshalb noch keinen funktionierenden IPv6-Zugriff.

Typische Fehler gezielt eingrenzen

Das Portal erscheint nicht

Zuerst die direkte URL auf Port 8090 öffnen. Ist sie nicht erreichbar, Quellzone und Captive portal unter Device Access, Client-IP, Zone-Mapping, DNS und Portal-FQDN prüfen.

Ist die direkte URL erreichbar, der automatische Login aber nicht, wird der Traffic häufig vorher von einer allgemeineren Regel verarbeitet oder Use web authentication for unknown users fehlt. Ausserdem kann nur eine passende Webanfrage den Browser-Login auslösen. Nicht-webbasierte Programme zeigen keine Captive-Portal-Seite.

Der Login wird abgelehnt

Unter Authentication > Services Authentifizierungsquelle und Reihenfolge prüfen. Danach Serververbindung, Kennwort, Benutzergruppe, Quota und bei lokaler MFA die abgeschlossene OTP-Registrierung kontrollieren. Wiederkehrende erlaubte oder gesperrte Zugriffszeiten werden separat mit Access Time für Benutzer und Gruppen geprüft. Ob stattdessen verbrauchte Internetzeit oder Datenmenge ausgeschöpft wurde, zeigt der Ablauf für Surfing Quota und Network Traffic Quota.

Wenn das Fehlerbild nicht klar beim Portal liegt, trennt Sophos Firewall Authentifizierungsfehler systematisch beheben Erreichbarkeit, Dienstwahl, Live User, Main Group und späteren Traffic-Pfad.

Für klassische Loginversuche ist access_server.log relevant. oauth_sso_captive.log wird nur für den Microsoft-Entra-ID-SSO-Ablauf benötigt. Wie man die Dateien liest, ohne vorschnell Dienste neu zu starten, steht unter Sophos Firewall Service-Logs.

Login erfolgreich, aber kein Zugriff

Ein erfolgreicher Login bestätigt nur die Authentifizierung. Im nächsten Schritt müssen Clientzone, Quellnetz, Gruppe, Ziele, Services, Regelposition, NAT und Routing zur Benutzerregel passen. Der Log Viewer zeigt, welche Rule ID den Traffic tatsächlich verarbeitet. Für eine systematische Prüfung hilft Warum eine Sophos-Firewall-Regel nicht matched.

Der Benutzer wird unerwartet abgemeldet

Die gewählte Sign-out-Option, das geöffnete Portalfenster, Sleep, Netzwechsel und Inaktivität prüfen. Bei When captive portal page is closed or redirected endet die Zuordnung, nachdem die Keepalives ausbleiben; das muss nicht im Moment des Fenster-Schliessens sichtbar sein.

Die Anmeldung erscheint erst nach etwa zwei Minuten

Wenn im selben Netz STAS verwendet wird, kann dessen Lernphase die Weiterleitung verzögern. Dann zuerst den STAS-Zustand und die nicht authentifizierten Clients prüfen. Der allgemeine Captive-Portal-Ablauf ändert dafür keinen globalen CLI-Wert; die Zusammenhänge stehen im STAS-Artikel.

Mehrere Benutzer teilen dieselbe Quell-IP

Captive Portal ordnet die Benutzeridentität grundsätzlich einer Client-IP zu. IP-Adressen, die unter Multi-user hosts für Per-Connection AD SSO über den Direct Web Proxy eingetragen sind, können Captive Portal deshalb nicht verwenden. Per-Connection AD SSO für Multi-User-Hosts erklärt den passenden Ablauf und die separate Regel ohne Match known users für den übrigen Traffic.

Häufige Fragen