Sophos Firewall Gastbenutzer erstellen und sicher betreiben

Mit Guest users erstellt man auf der Sophos Firewall zeitlich begrenzte Konten für Personen ohne reguläres Benutzerkonto. Das passt beispielsweise für Besucher, externe Techniker oder Schulungsteilnehmer, die sich über das Captive Portal anmelden und nur einen klar begrenzten Internetzugang erhalten sollen.

Der sichere Kurzweg lautet:

1. Eine restriktive Gastgruppe mit den benötigten Policies vorbereiten.
2. Unter Authentication > Guest user settings Präfix, Gruppe, Passwort und Bereinigung festlegen.
3. Entscheiden, ob ein Admin einzelne oder mehrere Konten erstellt oder ob Selbstregistrierung mit SMS wirklich benötigt wird.
4. Gültigkeit auf Immediately oder After first login setzen und Zugangsdaten geschützt übergeben.
5. Captive Portal, Benutzerregel, Netztrennung und ein erlaubtes sowie ein gesperrtes Ziel testen.
6. Konto nach Ablauf deaktivieren oder bereinigen und bestehende Sessions sowie Logs separat prüfen.

⚠️ Ein Gastkonto ist nur eine Identität. Es trennt kein Netzwerk und öffnet keinen Datenpfad. Gäste gehören in eine eigene Zone oder ein eigenes VLAN und erhalten eine enge, protokollierte Firewall-Regel. Zugangsdaten, Ausdrucke und SMS werden wie Passwörter behandelt.

Gastbenutzer, Voucher und normale Benutzer unterscheiden

Ein Gastbenutzer ist ein temporärer lokaler Benutzerdatensatz. Die Firewall erzeugt Benutzername und Passwort aus den globalen Gastbenutzer-Einstellungen. Nach der Anmeldung kann sie den Traffic dieser Identität zuordnen und die Policies der gewählten Gruppe anwenden.

Andere Zugangsmodelle lösen andere Aufgaben:

• Normaler lokaler oder externer Benutzer: Passt für wiederkehrende Personen mit dauerhaftem Konto, zentraler Benutzerquelle oder MFA. Das direkt auf der Firewall gepflegte Modell erklärt normale lokale Benutzer erstellen und verwalten.
• Guest user: Passt für eine zeitlich begrenzte Person mit eigenem Konto, individueller Gültigkeit und optionaler Nutzungskontrolle.
• Hotspot Voucher: Ist ein Code für einen Wireless Hotspot. Voucher-Gültigkeit, Onlinezeit, Datenmenge und Gerätezahl werden im Hotspot-Modell verwaltet. Die Einrichtung steht unter Sophos Firewall Hotspot mit Voucher oder Tagespasswort.
• Clientless User: Ordnet eine feste IP-Adresse einem Gerät zu, ohne dass sich eine Person anmeldet. Dieser Ablauf steht unter Sophos Firewall Clientless Users einrichten.

Gastbenutzer sind nicht für Remote Access SSL VPN oder IPsec Remote Access vorgesehen. Die aktuelle SSL-VPN-Policy erlaubt weder Guest users noch Guest groups als Policy members. Für Remote Access wird ein normaler Benutzer aus einer passenden lokalen oder externen Benutzerquelle verwendet. Die Einrichtung eines regulären VPN-Zugangs beschreibt SSL VPN Remote Access einrichten.

Die ältere SFOS-22-Hilfeseite Edit guest user zeigt weiterhin Felder für Remote-Access-Policies. Die neueren Hilfeseiten für IPsec und SSL VPN schliessen Guest users und Guest groups jedoch ausdrücklich aus. Die älteren Felder sind daher kein Nachweis für einen unterstützten VPN-Zugang und sollten nicht verwendet werden.

Beispielkonfiguration und Voraussetzungen

Das folgende Beispiel verwendet ein separates Gastnetz und ein Konto für einen eintägigen Besuch:

• Zone: Guest
• Netz: 10.30.40.0/24
• Portalname: login.example.com
• Gastgruppe: Guest_Internet
• Username prefix: guest-
• Password length: 16
• Simultaneous sign-ins: 1
• Validity period: 1 day
• Validity start: After first login

10.30.40.0/24 ist ein privates Beispielnetz und wird durch das reale Gastnetz ersetzt. login.example.com ist ein Dokumentationsname. Er wird durch einen FQDN ersetzt, der aus dem Gastnetz auf die erreichbare Firewall-Adresse auflöst und vom Portalzertifikat abgedeckt wird. Die Gruppe erhält nur die Policies, welche für diesen Gästezugang tatsächlich vorgesehen sind.

Vor der Erstellung müssen diese Voraussetzungen erfüllt sein:

1. Gastnetz, DHCP, DNS, Routing und NAT sind mit einer eng begrenzten temporären Testregel geprüft. Diese Regel wird vor dem Authentifizierungstest entfernt; eine separate DNS-Regel darf nur den benötigten Resolververkehr erlauben.
2. Interne Netze und Managementdienste sind aus der Gastzone gesperrt.
3. Das Captive Portal ist nur aus der vorgesehenen Zone erreichbar.
4. Eine eigene Gruppe bündelt Access Time, Quoten, Traffic Shaping und Sign-in Restriction.
5. Ein Adminzugang und ein unabhängiger Managementpfad bleiben während des Tests verfügbar.
6. Ausgabe, Ablauf, Widerruf und Aufbewahrung der Gastzugangsdaten sind organisatorisch geklärt.

Globale Gastbenutzer-Einstellungen festlegen

Vor dem Anlegen des ersten Kontos öffnet man:

Authentication > Guest user settings

Diese Werte gelten als Vorlage für neu erzeugte Gastkonten. Eine Änderung an der Vorlage wird deshalb zuerst mit einem Testkonto geprüft.

General settings sicher wählen

Unter Guest user general settings werden folgende Felder festgelegt:

1. Username prefix: Im Beispiel guest-. Ein neutraler Präfix ist besser als Firmen-, Standort- oder Kundennamen, die unnötige Informationen verraten.
2. Group: Guest_Internet auswählen. Gastbenutzer erben die Policies dieser Gruppe.
3. Password length: Im Beispiel 16. Sophos erlaubt für Benutzername und Passwort am Captive Portal jeweils maximal 50 Zeichen. Die Länge wird so gewählt, dass sie ausreichend stark und im vorgesehenen Ausgabeweg zuverlässig nutzbar ist.
4. Password complexity: Die stärkste mit dem Ausgabe- und Anmeldeprozess kompatible Variante wählen.
5. Disclaimer: Dieser Text wird unter die erzeugten Zugangsdaten gedruckt. Kurze Nutzungsbedingungen, Zuständigkeit und einen Kontakt nennen. Reale Zugangsdaten oder interne technische Details gehören nicht hinein. Die globale Pflege von Admin-, Authentication-, SMTP- und SMS-Texten erklärt Sophos Firewall Login-Disclaimer und Messages konfigurieren.
6. Auto purge on expiry: Nur aktivieren, wenn abgelaufene Benutzerdatensätze automatisch entfernt werden sollen und der betriebliche Nachweis anderweitig geregelt ist.
7. Mit Apply speichern.

Auto purge on expiry löscht die Gastbenutzerdetails nach Ablauf, nicht die zugehörigen Logs. Das ist wichtig für Datenschutz und Fehlersuche: Kontobereinigung und Logaufbewahrung sind zwei getrennte Prozesse.

Wie Gruppen-Policies, Main Group und Benutzer-Overrides zusammenspielen, erklärt Benutzergruppen auf Sophos Firewall sicher verwalten. Für Gäste sollte die Default-Gruppe nicht beiläufig verwendet werden. Eine eigene restriktive Gruppe macht Wirkung und Rückbau nachvollziehbar.

Selbstregistrierung nur bei echtem Bedarf aktivieren

Unter Guest user registration settings kann die Selbstregistrierung eingeschaltet werden. Sie ist aufwendiger als die kontrollierte Ausgabe durch einen Admin oder Empfang und benötigt einen belastbaren SMS-Prozess:

• Enable guest users registration: Nur aktivieren, wenn Gäste sich selbst registrieren sollen.
• SMS gateway: Den vorher getesteten Provider auswählen.
• Guest username: Entweder die Mobilnummer verwenden oder den Namen aus dem Username prefix erzeugen lassen.
• User validity: Die maximale Gültigkeit für selbst registrierte Konten festlegen.
• Default country code: Zum tatsächlichen Benutzerkreis passend wählen.
• CAPTCHA verification: Aktiv lassen, damit automatisierte Registrierungen erschwert werden.
• Mit Apply speichern.

Die Firewall unterstützt HTTP- und HTTPS-basierte SMS-Gateways. HTTPS ist vorzuziehen, damit Zugangsdaten und Providerparameter nicht unverschlüsselt übertragen werden. URL, HTTP-Methode, Mobilnummernformat, Request-Parameter und Response-Format müssen exakt zur Dokumentation des eigenen SMS-Providers passen. Beispiel-URLs aus einer Anleitung werden nicht produktiv kopiert.

Test connection sendet eine Testnachricht an eine Mobilnummer. Bei einem privaten SMS-Gateway mit interner IP-Adresse kann dieser Test laut Sophos fehlschlagen, obwohl der reale Ablauf funktioniert. Dann wird nicht einfach von Erfolg ausgegangen, sondern die komplette Registrierung mit einem Mobilgerät, Providerlog und tatsächlicher SMS geprüft.

SMS-Gateway-Parameter korrekt abbilden

Unter Authentication > Guest user settings > SMS gateway > Add werden Name, URL, HTTP method mit Get oder Post, Cell number format und gegebenenfalls Use country code with mobile phone number sowie Number prefix eingetragen.

Jeder Request-Parameter erhält Name und Value; {mobileno} und {msg} ersetzt SFOS durch Mobilnummer und Nachricht. Für die Antwort ordnet man Parameter index und Name dem Response format zu. Die Parameterbezeichnungen sind keine SFOS-Vorgabe, sondern müssen exakt zum Provider passen. Dieses Schema verwendet ausschliesslich reservierte Beispielwerte:

URL: https://sms.example.net/send
HTTP method: Post
mobile = {mobileno}
message = {msg}
Response format: status={0}&message={1}
0 = status; 1 = message

sms.example.net, mobile, message und status werden durch die Angaben des realen SMS-Providers ersetzt. Sonderzeichen in vom Provider verlangten URL-Werten müssen percent-encoded sein, beispielsweise @ als %40. Zugangsdaten in URL oder Request sind Secrets und gehören weder in Screenshots, Tickets noch Logs; falls der Provider sie verlangt, wird ausschliesslich HTTPS verwendet und ihr Ablauf dokumentiert. Unter Administration > Messages > SMS customization muss die Nachricht zudem dem vom Provider akzeptierten Template entsprechen. Dort stehen für den Nachrichtentext {username}, {password} und {expirydate} zur Verfügung. Anschliessend wird das Gateway mit Save gespeichert.

Der Provider-Test ist nur eine Teilprüfung: Im Pilottest öffnet ein Gast Register for internet access, speichert das Formular mit Save, löst das CAPTCHA und empfängt tatsächlich eine SMS. Danach müssen der Datensatz unter Authentication > Guest users und die Anmeldung unter Current activities > Live users sichtbar sein. Der Verkehr muss mit dem erwarteten Benutzer und der Firewall Rule ID protokolliert werden. Die Benutzerregel verwendet Match known users und Use web authentication for unknown users. Die ältere SMS-Hilfeseite nennt die zweite Option noch Show captive portal to unknown users; für SFOS 22 ist die aktuelle Bezeichnung massgebend. Eine breite Any-Regel ist kein Ersatz für diesen Nachweis.

Wenn kein SMS-Gateway, keine verantwortliche Stelle oder kein sauberer Schutz der Registrierungsseite vorhanden ist, bleibt Selbstregistrierung deaktiviert. Dann erstellt eine zuständige Person die Konten kontrolliert.

Einzelne oder mehrere Gastkonten erstellen

Einzelnes Konto mit Name und E-Mail erstellen

Für einen konkreten Besucher öffnet man Authentication > Guest users > Add single:

1. Bei Name beispielsweise Visitor Zurich 2026-08-11 eintragen. Dieses Feld ist der Name des Datensatzes, nicht der spätere Username.
2. Die zuständige E-Mail-Adresse eintragen. Das Feld versendet die Zugangsdaten nicht; dafür dokumentiert Sophos Add and print beziehungsweise SMS.
3. Validity period auf den benötigten Zeitraum setzen, im Beispiel 1 day.
4. Validity start bewusst wählen.
5. Mit Add speichern oder mit Add and print speichern und die Zugangsdaten drucken.

Immediately startet die Gültigkeit beim Anlegen. Das passt, wenn die Zugangsdaten sofort übergeben und verwendet werden. After first login startet den Zeitraum bei der ersten erfolgreichen Anmeldung. Diese Variante ist für vorbereitete Besucherkonten meist besser, weil die Gültigkeit nicht schon vor der Ankunft abläuft.

Nach dem Erstellen zeigt die Liste den generierten Username. Bei der Übergabe verwendet man diesen Wert und nicht den Datensatznamen.

Mehrere Konten für eine Veranstaltung erzeugen

Unter Authentication > Guest users > Add multiple werden Number of users, Validity period und Validity start festgelegt. Add and print erzeugt die Konten und die zugehörigen Ausdrucke.

Mehrere Konten sollten nur für einen konkreten Anlass erzeugt werden. Ausdrucke werden gezählt, geschützt aufbewahrt und einem Verantwortlichen übergeben. Nicht ausgegebene oder abgelaufene Konten werden deaktiviert oder bereinigt. Ein grosser Vorrat an unzugeordneten Zugangsdaten schwächt die technische Begrenzung.

Gruppe, Policies und Anmeldegrenzen prüfen

Ein neu angelegtes Gastkonto erbt zuerst die unter Guest user settings ausgewählte Gruppe. Unter Authentication > Guest users > Edit kann man Name, Passwort, Mobilnummer, E-Mail, Gruppe und einzelne Policies kontrollieren und mit Save speichern.

Benutzerspezifische Policies haben Vorrang vor den Gruppen-Policies. Ein Override ist deshalb nur für eine dokumentierte Ausnahme sinnvoll. Für ein einheitliches Gastmodell bleiben Access Time, Surfing Quota, Network Traffic, Traffic Shaping und Sign-in Restriction normalerweise in Guest_Internet gebündelt.

Für das Beispiel gelten diese Grenzen:

• Sign-in restriction: User group nodes übernimmt die Begrenzung der Gastgruppe. Für eine individuelle Ausnahme Selected nodes oder Node range auf die real benötigten Quellen beschränken. Any node passt nur, wenn Anmeldungen aus allen Netzen wirklich beabsichtigt und separat abgesichert sind.
• Simultaneous sign-ins: 1, solange ein Gastkonto nicht ausdrücklich für mehrere Geräte freigegeben wird.
• MAC binding: Für wechselnde Gäste normalerweise deaktiviert. Die Firewall bindet Remote-Access-VPN-Benutzer ohnehin nicht über MAC-Adressen.
• Quarantine digest: Nur aktivieren, wenn das Konto tatsächlich Mail Protection und einen definierten Quarantäneprozess verwendet.
• Remote access policies: Für Gastbenutzer nicht als VPN-Zugang planen.

Die Kontogültigkeit löst eine andere Aufgabe als Zeit- und Verbrauchspolicies:

• Validity period bestimmt, wie lange das Gastkonto verwendbar ist.
• Access Time erlaubt oder sperrt Internetzugriff in wiederkehrenden Zeitfenstern.
• Surfing Quota und Network Traffic Quota begrenzen Onlinezeit oder Datenvolumen.
• Eine Firewall-Regel bestimmt, welche Zonen, Ziele und Dienste überhaupt erreichbar sind.

Kontogültigkeit, Zeit- und Verbrauchslimits ersetzen keine restriktive Firewall-Regel. Ein gültiges Konto darf keinen internen Server erreichen, wenn die Regel dies nicht ausdrücklich erlaubt.

Captive Portal und Datenpfad verbinden

Gastbenutzer melden sich normalerweise über das Captive Portal an. Dafür müssen Device Access, DNS, HTTPS, Benutzerregel und die ausgewählte Authentifizierungsmethode zusammenpassen. Das Portal selbst erlaubt noch keinen Internetzugriff.

Für das Gastnetz wird ein vollständiger Positiv- und Negativtest durchgeführt:

1. Client erhält Adresse, Gateway und DNS aus dem Gastnetz.
2. https://login.example.com:8090 ist erreichbar und zeigt ein passendes Zertifikat.
3. Eine normale Webanfrage führt zum Portal.
4. Ein gültiges Gastkonto kann sich anmelden.
5. Unter Current activities > Live users erscheinen Username und Quell-IP.
6. Der erlaubte Internettest trifft die erwartete Benutzerregel und Firewall Rule ID.
7. Ein internes Ziel und ein nicht erlaubter Service bleiben gesperrt.
8. Ein abgelaufenes, deaktiviertes oder absichtlich falsch eingegebenes Konto wird abgewiesen.

In einem Dual-Stack-Gastnetz wird dieser Ablauf getrennt für IPv4 und IPv6 geprüft, weil SFOS die Webanmeldung für IPv4- und IPv6-Ziele getrennt behandelt. Ausserdem wird unter Authentication > Web authentication > Sign out user festgelegt und getestet, wann die Session endet. Never passt nicht zu einem zeitlich begrenzten Gastzugang.

Der vollständige Regel-, Device-Access- und HTTPS-Ablauf steht in Sophos Firewall Captive Portal einrichten und testen. Das Portal-Handbuch grenzt User Portal, VPN Portal und Captive Portal voneinander ab.

Zugangsdaten ausgeben und Konten betreiben

Unter Authentication > Guest users stehen mehrere Betriebsaktionen zur Verfügung:

• Print: Zugangsdaten kontrolliert ausgeben.
• Resend credentials: Zugangsdaten über das konfigurierte SMS-Gateway erneut senden.
• Change status: Konto aktiv oder inaktiv setzen.
• Change password: Bei Verlust oder Verdacht ein neues Passwort vergeben.
• View usage: Internetnutzung und Quotenstatus kontrollieren.
• Reset user accounting: Verbrauchszähler zurücksetzen und die Network Traffic Quota neu starten.

Reset user accounting ist eine Zustandsänderung. Vorher werden Konto, aktueller Verbrauch, Zeitpunkt und Grund dokumentiert. Der Reset wird nicht als erster Troubleshooting-Schritt verwendet, weil er die Beweislage verändert und dem Gast erneut Kontingent geben kann.

Beim Offboarding wird ein Konto zuerst deaktiviert. Unter Current activities > Live users wird seine aktive Session ausgewählt und mit Disconnect beendet; danach werden erneute Anmeldung und Datenpfad negativ getestet. Anschliessend werden ungenutzte Ausdrucke, SMS-Zugriff und mögliche benutzerspezifische Overrides geprüft. Erst wenn keine Abhängigkeit mehr besteht, wird der Datensatz gelöscht oder durch Auto purge on expiry entfernt.

Globale Einstellungen, SMS-Gateway, Gruppe und Regel werden vor dem Pilottest dokumentiert. Für den Rückbau werden die geänderten Einzelwerte zurückgesetzt; alternativ werden Selbstregistrierung und Pilotregel deaktiviert. Ein vollständiger Backup-Restore ist dafür kein schneller Undo-Schritt: Er ersetzt die aktuelle Konfiguration und startet die Firewall neu; in HA verursacht auch der Restore auf dem Primary eine Unterbrechung. Er bleibt dem dokumentierten Notfallverfahren vorbehalten.

Fehler systematisch eingrenzen

Datensatzname funktioniert nicht als Username

Bei Add single ist Name nur die Bezeichnung des Benutzerdatensatzes. Der eigentliche Username wird aus den Guest user settings erzeugt und steht in der Liste beziehungsweise auf dem Zugangsdaten-Ausdruck. Genau diesen Wert zusammen mit dem generierten oder geänderten Passwort verwenden.

Konto ist sofort oder noch nicht gültig

Validity start und Validity period prüfen. Bei Immediately läuft die Zeit ab dem Anlegen, bei After first login ab der ersten erfolgreichen Anmeldung. Zusätzlich Firewall-Zeit und Zeitzone kontrollieren. Ein abgelaufenes Konto wird nicht durch eine breitere Firewall-Regel repariert.

Selbstregistrierung sendet keine SMS

Prüfen, ob Enable guest users registration aktiv ist, der richtige SMS gateway ausgewählt wurde und Mobilnummer, Country code, URL, HTTP-Methode, Request-Parameter sowie Response-Format zum Provider passen. Danach Providerlog und tatsächlichen SMS-Empfang kontrollieren.

Ein erfolgreicher Test connection beweist noch nicht den gesamten Registrierungs- und Captive-Portal-Ablauf. Umgekehrt ist ein fehlgeschlagener Test bei einem privaten internen Gateway laut Sophos nicht automatisch der Beweis für einen defekten SMS-Pfad. In beiden Fällen wird mit einem realen Pilotkonto geprüft.

Anmeldung klappt, aber der Internetzugriff nicht

Unter Current activities > Live users prüfen, ob der Gast mit der erwarteten Quell-IP sichtbar ist. Danach Gruppe, benutzerspezifische Overrides, Gültigkeit, Access Time und Quoten kontrollieren. Im Log Viewer muss der Testtraffic die erwartete Benutzerregel und Firewall Rule ID treffen.

Fehlt der Benutzer unter Live users, wird zuerst der Loginpfad mit access_server.log und dem dokumentierten Testzeitpunkt geprüft. Ist der Benutzer sichtbar, liegt der nächste Schritt bei Regel, Routing, NAT, DNS oder Schutzpolicy. Authentifizierungsfehler systematisch beheben trennt diese Fehlerphasen.

Gastkonto kann nicht für SSL VPN ausgewählt werden

Das ist erwartetes Produktverhalten. Guest users und Guest groups sind keine gültigen Policy members für Remote Access SSL VPN oder IPsec Remote Access. Für einen externen Techniker mit VPN-Bedarf wird ein normaler, eng berechtigter Benutzer mit passender MFA- und Remote-Access-Policy verwendet.

Abschlusskontrolle

• Der Gast erreicht nur die vorgesehenen Ziele; interne Netze und Managementdienste bleiben gesperrt.
• Gültigkeit, Access Time, Quoten und Overrides entsprechen dem Ausgabeprozess.
• Selbstregistrierung bleibt ohne bestandenen SMS- und CAPTCHA-Pilottest deaktiviert.
• Live users, Regel-ID sowie Positiv- und Negativtest bestätigen die erwartete Zuordnung.
• Offboarding trennt aktive Sessions und entfernt nicht mehr benötigte Zugangsdaten und Ausdrucke.
• Reset user accounting wird nur mit dokumentiertem Grund ausgeführt.

Häufige Fragen