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.

Auch die aktuelle SFOS-23-Hilfeseite Edit guest user führt SSL-VPN- und IPsec-Remote-Access-Felder auf. Die SFOS-23-Hilfeseiten für SSL-VPN-Policies und IPsec-Einstellungen schliessen Guest users und Guest groups für diese beiden Remote-Access-Verfahren jedoch ausdrücklich aus. Das ist ein ungelöster Dokumentationswiderspruch innerhalb derselben Version, kein belegter Versionswechsel. Die Felder sind daher kein Nachweis für unterstützten Gast-VPN-Zugang; für SSL VPN und IPsec bleibt die Empfehlung ein normaler Benutzer. Aus diesen Ausschlüssen lässt sich keine Aussage zur Gastberechtigung für Clientless SSL VPN, L2TP oder PPTP ableiten; diese Angaben der Edit-Seite bleiben ungeklärt.

Der gleiche Widerspruch besteht in den SFOS-22-Hilfeseiten. Die Edit-Seiten beider Versionen beschreiben ausserdem Browser-Bookmarks für Clientless SSL VPN policy und optionale zugewiesene IP-Adressen für IPsec remote access, L2TP und PPTP. Diese Feldbeschreibungen sind keine Freigabe, solche Verfahren für Gäste einzuschalten. Für den hier beschriebenen Internetzugang werden keine Remote-Access-Berechtigungen hinzugefügt. Ein separater VPN-Bedarf wird mit einem regulären Benutzer und dem passenden VPN-Runbook umgesetzt; die ungeklärten Gastoptionen werden nicht versuchsweise produktiv aktiviert.

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.

Bei API-Automation: Die API-Dokumentation für SFOS 22 und 23 begrenzt UserNamePrefix auf 10 Zeichen; guest- bleibt innerhalb dieser Grenze. Das ist eine dokumentierte API-Grenze, kein Nachweis für die Validierung jeder GUI-Version. Die Empfehlung für Passwortlänge 16 bleibt bestehen. Vor einer Änderung die aktuellen Einstellungen lesen und mit einem einzelnen Pilotkonto die tatsächlich erzeugten Zugangsdaten, Gruppe und Gültigkeit prüfen.

Die API-Beispiele sind nicht durchgehend konsistent: Bei PasswordComplexity stehen symbolische Werte im Beispiel einer Integer-Angabe in der Attributtabelle gegenüber; bei AutoPurgeOnExpiry nennt das Beispiel Enable/Disable, die Tabelle nur Enable. Diese Werte nicht erraten. Vor einem schreibenden API-Aufruf das unterstützte Schema für die konkrete Appliance-Version klären; andernfalls die dokumentierten GUI-Felder verwenden. API-Defaults und Stellenzahl-Angaben belegen keine allgemeinen GUI-Defaults oder Gültigkeitsgrenzen.

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 in Tagen festlegen.
• Default country code: Zum tatsächlichen Benutzerkreis passend wählen. Dieser Standardwert wird auf der Gastregistrierungsseite beim Mobilnummernfeld angezeigt.
• 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. Die GUI-Hilfe beschreibt Number prefix mit alphanumerischen Zeichen und ASCII-Sonderzeichen. Das ist keine pauschale Zusage für die API: Deren Feld CellNumberPreFix schliesst Kommas ausdrücklich aus.

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. Get sendet eine Anfrage an die angegebene Ressource; Post übermittelt Daten zur Verarbeitung. Die Auswahl richtet sich nach der Provider-API, nicht nach einer allgemeinen Vorliebe. 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.

Response format beschreibt nur, wie die Antwort zerlegt wird. Eine Antwort wie status=302&message=Limit Exceeded zeigt im Dokumentationsbeispiel einen überschrittenen Grenzwert, keinen erfolgreichen SMS-Versand. Den Erfolgs- oder Fehlerstatus anhand der Providerbeschreibung und den tatsächlichen Empfang prüfen. Zuerst das Gateway mit Save speichern, dann Test connection mit einer kontrollierten Mobilnummer ausführen.

API-Grenzen und doppelte Parameter: Für SFOS 22 und 23 dokumentiert die API bei Gateway-Name maximal 100 Zeichen und kein Komma, bei ResponseFormat maximal 255 Zeichen. Das sind Dokumentationsgrenzen der API, keine hier geprüften GUI-Limits. In den Request- und Response-Listen werden doppelte ParameterName- und ParameterValue-Einträge nicht ignoriert. Daher jedes Name/Wert-Paar auf versehentliche Dopplungen prüfen; beabsichtigte Wiederholungen nur gemäss Provideranforderung übernehmen. Daraus folgt weder eine bestimmte Provider-Auswertung noch automatisch ein mehrfacher SMS-Versand. Die API-URL-Tabelle nennt auch FTP und IPv4-Adressen, während die GUI-Hilfe HTTP/HTTPS beschreibt. Das erweitert diese Anleitung nicht um FTP oder unverschlüsselte Übertragung: Für Secrets bleibt ausschliesslich HTTPS vorgesehen. Ein API-Operationsstatus 200 ersetzt keinen tatsächlichen SMS-Empfang und keinen vollständigen Registrierungstest. Eine kontrollierte Testnummer nur mit Zustimmung verwenden; Providerkosten sind möglich.

Unter Administration > Messages > SMS customization wählt man Edit, trägt eine Nachricht ein, die dem vom Provider akzeptierten Template entspricht, und speichert sie mit Apply. Dort stehen für den Nachrichtentext {username}, {password} und {expirydate} zur Verfügung. Das ist ein eigener Speicherschritt für den Nachrichtentext. Ein nicht passendes Template kann dazu führen, dass der Provider die Nachricht ablehnt und Test connection fehlschlägt.

Der Provider-Test ist nur eine Teilprüfung: Im Pilottest verbindet sich ein Gast mit dem Gast-WLAN, öffnet Register for internet access, füllt das Formular aus, löst das CAPTCHA und speichert mit Save. Nach erfolgreicher Registrierung erscheint die Anmeldeseite. Die tatsächlich empfangene SMS muss Username und Passwort enthalten; mit diesen Werten meldet sich der Gast an. 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. 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 erzeugt die Konten ohne Ausdruck. Add and print erzeugt die Konten und die zugehörigen Ausdrucke.

Bei Erstellung über die API: Für NoOfUsers ist in SFOS 22 und 23 der Bereich 1–100 pro Aufruf dokumentiert. Das ist kein hier bestätigtes Maximum für Add multiple in der GUI. Grössere Ausgaben in bewusst dimensionierte API-Batches aufteilen. Vorher Sollzahl, globale Vorlage und Gültigkeitsbeginn festhalten und ein einzelnes Konto prüfen. Nach jedem Aufruf die tatsächlich erzeugten Usernames und Ausdrucke abgleichen; bei unklarer Antwort zuerst die Kontoliste lesen, statt den Erstellungsaufruf blind zu wiederholen. Das API-Beispiel lässt das laut Tabelle obligatorische NoOfUsers weg und erklärt die Werte 1/2/3 bei Expirty Period type nicht. Deshalb keine vollständige Anfrage oder Zuordnung der Ablaufwerte daraus ableiten; zuerst das versionspassende Schema klären. Name nicht in Username umdeuten, sondern die erzeugten Zugangsdaten kontrolliert ausgeben.

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. Traffic shaping ordnet dem Benutzer eine QoS-Policy zu. Diese kann die Policy-Zuordnung, Priorität und getrennte Upload- und Downloadlimits festlegen.

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. Das Feld begrenzt die gleichzeitig erlaubten Sessions; man kann den globalen Wert übernehmen oder einen individuellen Wert festlegen.
• MAC binding: Für wechselnde Gäste normalerweise deaktiviert. Die Firewall bindet Remote-Access-VPN-Benutzer ohnehin nicht über MAC-Adressen. Bei Aktivierung sind Anmeldungen nur über die angegebenen Geräte erlaubt; deren MAC-Adressen müssen in MAC address list eingetragen werden.
• Quarantine digest: Nur aktivieren, wenn das Konto tatsächlich Mail Protection und einen definierten Quarantäneprozess verwendet. Der Digest sendet die Liste der zurückgehaltenen E-Mails an den Posteingang des Benutzers.
• 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.

DNS und Benutzerregel getrennt konfigurieren

Unter Rules and policies > Firewall rules wählt man das passende IP-Protokoll und Add firewall rule > New firewall rule. Die SMS-Beispielanleitung verwendet zwei Regeln von WiFi nach WAN: eine für DNS, die zweite für Benutzerverkehr mit Any. Für das reale Gastnetz werden diese breiten Beispielwerte eingeschränkt:

1. Die DNS-Regel erhält Action: Accept, Source zones: Guest, als Source networks and devices das Netz 10.30.40.0/24, unter Destination networks nur die vorgesehenen Resolver und unter Services nur DNS. Destination zones muss zur tatsächlichen Lage der Resolver passen; WAN ist nur für externe Resolver richtig. Für diese notwendige Namensauflösung wird keine vorherige Benutzeranmeldung verlangt.
2. Die Benutzerregel erhält ebenfalls Action: Accept, dieselbe Gastzone und dasselbe Quellnetz, Destination zones: WAN sowie nur die vorgesehenen Internetziele und Dienste. Match known users aktivieren, unter Users or groups Guest_Internet auswählen und Use web authentication for unknown users aktivieren. Die SMS-Hilfeseiten für SFOS 22 und 23 nennen diese letzte Option noch Show captive portal to unknown users; die aktuellen Firewall-Regel-Seiten beider Versionen verwenden Use web authentication for unknown users. Die unterschiedliche Beschriftung ist kein Nachweis für anderes Verhalten.
3. Log firewall traffic aktivieren und jede Regel mit Save speichern. Ihre Position so prüfen, dass keine vorherige breite Freigabe die Benutzerprüfung umgeht und die bestehenden Sperren für interne Netze und Managementdienste wirksam bleiben. NAT und Portalzugriff werden weiterhin separat geprüft. Eine Verbindung ohne Anmeldung darf ausser den ausdrücklich benötigten Voranmeldediensten keinen freien Internetzugang erhalten.

Guest und 10.30.40.0/24 stehen für die bereits vorbereitete Zone und deren reales Netz. Resolver, Internetziele und Dienste werden anhand des Gästezwecks gewählt, nicht pauschal auf Any gesetzt. Nutzt man die Firewall selbst als DNS-Resolver, betrifft das einen lokalen Dienst: Dafür wird der DNS-Zugriff unter Administration > Device access nur aus der Gastzone erlaubt, statt eine WAN-DNS-Regel nachzubauen.

Anmeldung und Grenzen überprüfen

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: Die vorgesehenen Benutzer in der Liste auswählen und ihre 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.

SMS-Gateway sicher ausser Betrieb nehmen: Vorher den exakten vorhandenen Profilnamen, die Auswahl unter Guest user registration settings und den Bedarf für Resend credentials erfassen. Die Konfiguration ohne Secrets dokumentieren und benötigte Secrets separat geschützt aufbewahren, damit eine manuelle Neuerstellung vorbereitet ist; das macht die Löschung nicht reversibel. Solange Registrierung oder erneuter Versand benötigt werden, zuerst einen Ersatz auswählen und SMS-Empfang, vollständige Registrierung, Anmeldung und erneuten Versand mit einem kontrollierten Pilotkonto prüfen. Wird die Selbstregistrierung beendet, sie vor dem Entfernen des Profils deaktivieren; das allein erledigt noch keine Verpflichtung zum erneuten Versand. Ist ein benötigter SMS-Pfad nicht nachgewiesen, bleibt das alte Profil erhalten.

Eine autorisierte API-Löschung benötigt den exakten Name des alten Profils; keine ungezielte Löschung senden. Die dokumentierte Operation belegt weder einen bestimmten GUI-Löschknopf noch eine automatische Abhängigkeitsprüfung. Nach der Änderung Profilliste und Gateway-Auswahl erneut lesen und die weiterhin benötigten Registrierungs- und Versandwege prüfen. Diese Reihenfolge ist eine sichere Betriebsempfehlung, kein Bericht über durchgeführte Appliance-Tests.

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