Sophos Firewall RADIUS-Server einrichten und testen

RADIUS verbindet die Sophos Firewall mit Microsoft NPS, einem MFA-Gateway oder einem anderen zentralen Authentifizierungsdienst. Zuerst bereitet man Gegenstelle und Netzwerkpfad vor. Danach legt man den Server unter Authentication > Servers an und ordnet ihn unter Authentication > Services nur den benötigten Anmeldediensten zu. Die Abnahme erfolgt mit einem echten Login samt Benutzer-, Gruppen- und Regelkontrolle.

Für klassische Benutzer- und Gruppenabfragen aus einer Windows-Domäne eignet sich häufig die direkte Active-Directory-Anbindung an Sophos Firewall. Für moderne Remote-Access-Szenarien kann Microsoft Entra ID SSO für Sophos Connect und VPN Portal die passendere Architektur sein. Soll die Firewall bereits authentifizierte WLAN-Benutzer anhand eingehender Accounting-Pakete erkennen, gilt ein anderer Ablauf: RADIUS SSO mit Accounting auf Sophos Firewall einrichten.

Wann RADIUS sinnvoll ist

Die Firewall sendet Benutzername und Anmeldeinformationen an den RADIUS-Server. Dort entscheiden Benutzerquelle, Network Policy und gegebenenfalls MFA über Access-Accept oder Access-Reject. Erst danach bestimmen die lokale Benutzergruppe, VPN-Policy und Firewall-Regeln, welche Ressourcen erreichbar sind.

Authentifizierungs- und Autorisierungsdaten liegen im RADIUS-Modell in Benutzerprofilen. Eine Dienstfreigabe setzt voraus, dass die Anfrage zu den vorgesehenen Attributen passt, beispielsweise zur IP-Adresse des anfragenden RADIUS-Clients. Das Shared Secret schützt dabei die Benutzerkennwörter; daraus folgt keine Verschlüsselung des gesamten RADIUS-Transports.

Typische Einsatzfälle sind:

• Remote Access VPN mit Microsoft NPS oder einem MFA-Dienst;
• zentrale Anmeldung an User Portal, VPN Portal oder Captive Portal;
• ein Übergang, wenn AD oder LDAP nicht direkt an die Firewall angebunden werden soll;
• mehrere Netzwerkgeräte, die denselben RADIUS-Dienst verwenden.

Ein auf der Firewall verwaltetes Enterprise-WLAN verwendet zusätzlich die Serverauswahl unter Wireless > Wireless settings. Der vollständige 802.1X-Ablauf steht deshalb unter WLAN direkt auf Sophos Firewall einrichten.

Im SFOS-verwalteten Enterprise-WLAN enthalten Accounting Request und Accounting Response Sitzungs- und Accounting-Informationen. Sie sind von den Access-Anfragen, -Antworten und -Challenges für die Anmeldung getrennt. Für diesen Wireless-Pfad dokumentiert Sophos Accounting-Unterstützung auf allen Wi-Fi-fähigen Geräten; das Wireless Network muss 802.1X verwenden und Accounting auf dem RADIUS-Server muss aktiviert sein. Die getrennten Ports und die fehlenden Interim Accounting Updates erklärt die verlinkte WLAN-Anleitung. Eine Accounting-Unterstützung ist keine Zusage für einen sekundären RADIUS-Server.

Ausgangszustand und Rückweg festhalten

Bevor man einen produktiven Dienst umstellt, notiert man unter Authentication > Services für jeden betroffenen Abschnitt:

• ausgewählte Server und ihre Reihenfolge;
• den Zustand von Set authentication methods same as firewall, Same as VPN oder Same as firewall;
• die bisherige Default group bei der Firewall-Authentifizierung;
• einen Benutzer, mit dem die bisherige Methode nachweislich funktioniert.

Für Administrator-Logins bleibt während der Umstellung eine bestehende WebAdmin-Sitzung offen. Zusätzlich prüft man einen lokalen Super-Administrator über einen bereits erlaubten Managementpfad. Die Serverauswahl für Administratoren gilt nicht für diesen Super-Administrator, dennoch sollte ein externer Admin-Login nie ohne bestätigten lokalen Rückweg umgestellt werden.

RADIUS-Verbindung planen

Rollen, Netzwerkpfad und Protokolle

In einer NPS-Umgebung ist die Sophos Firewall der RADIUS-Client und NPS der RADIUS-Server. NPS prüft die Anfrage gegen seine Connection Request Policy und Network Policy sowie meist gegen Active Directory. Eine nachfolgende VPN- oder Firewall-Regel entscheidet weiterhin über den eigentlichen Zugriff.

Die allgemeine SFOS-22-Hilfe beschreibt die Kommunikation zwischen Firewall und RADIUS-Server mit PAP. Unter Authentication > Services führt Sophos für L2TP- und PPTP-Verbindungen jedoch PAP, CHAP und MSCHAPv2 auf. Diese Protokollmatrix belegt nicht dieselben Methoden für IPsec oder andere Anmeldepfade. Deshalb müssen Dienst, Client und erlaubte Methode auf dem RADIUS-Server gemeinsam geprüft werden.

Klassisches RADIUS nutzt UDP und bietet in der dokumentierten SFOS-Maske keine TLS- oder Zertifikatsfelder. Der Verkehr gehört deshalb auf einen kontrollierten internen oder anderweitig geschützten Pfad. Ein starkes Shared Secret ersetzt weder Segmentierung noch eine enge Freigabe zwischen Firewall und RADIUS-Server.

Ältere Gegenstellen können abweichende Ports wie 1645/UDP und 1646/UDP erwarten. Massgebend sind die tatsächlich konfigurierten Ports auf beiden Seiten, nicht diese historischen Werte.

Beispielwerte bewusst wählen

Diese Anleitung verwendet:

• Servername NPS-HQ-RADIUS;
• Server-IP 10.20.30.15;
• Authentication-Port 1812;
• Accounting-Port 1813;
• Time-out 5 Sekunden;
• Domain name corp.example.

10.20.30.15 und corp.example müssen durch die interne Adresse und die eigene Namenskonvention ersetzt werden. Fünf Sekunden sind ein Startwert für eine direkte Kennwortprüfung, kein Sophos-Default. Bei Push, Telefonanruf oder einer externen Challenge muss der Wert innerhalb des von SFOS erlaubten Bereichs von 1 bis 60 Sekunden zum Anbieter und zum echten Client passen.

Das Shared secret ist das gemeinsame technische Geheimnis des RADIUS-Clients und -Servers, nicht das Kennwort eines Benutzers. Sophos begrenzt es auf 48 Zeichen. Der Wert wird über einen geschützten separaten Weg ausgetauscht, sicher gespeichert und auf beiden Seiten exakt gleich eingetragen; RADIUS sendet das Secret selbst nicht über das Netzwerk.

RADIUS-Server unter Authentication anlegen

Der Menüpfad lautet Authentication > Servers.

1. Add öffnen und bei Server type die Option RADIUS server wählen.
2. Als Server name beispielsweise NPS-HQ-RADIUS eintragen.
3. Unter Server IP die interne IP-Adresse des RADIUS-Servers eintragen, im Beispiel 10.20.30.15.
4. Authentication port auf den Server abstimmen, normalerweise 1812.
5. Time-out setzen. Für den ersten direkten Test verwendet das Beispiel 5 Sekunden.
6. Enable accounting nur aktivieren, wenn die Gegenstelle Accounting-Daten verarbeiten soll. Dann auch Accounting port, normalerweise 1813, abstimmen.
7. Das Shared secret exakt wie auf der Gegenstelle eintragen.
8. Optional Domain name setzen. Bei paralleler AD- und RADIUS-Nutzung verhindert eine einheitliche Domain, dass derselbe Mensch als unterschiedliche lokale Benutzerobjekte erscheint. Mit Domain name wird beim ersten Login automatisch ein lokaler Eintrag im Format user@domainname angelegt. Ohne diesen Wert entsteht bei RADIUS ein Benutzer ohne Domain, während AD einen domainqualifizierten Eintrag anlegt; so können zwei lokale Einträge für dieselbe Person entstehen.
9. Group name attribute nur eintragen, wenn die Gegenstelle das erwartete Attribut nachweislich liefert. Die Sophos-Hilfe bezeichnet es als Alias für den konfigurierten Gruppennamen, dokumentiert aber hier keine allgemeine Abbildung beliebiger NPS-Attribute auf lokale Gruppen.
10. Nur bei einer passenden Policy Enable additional settings öffnen. NAS-identifier identifiziert den anfragenden Network Access Server, zum Beispiel mit einem FQDN. NAS-port-type beschreibt den Porttyp der Anmeldung.
11. Test connection mit einem eigenen Pilotbenutzer ausführen und anschliessend Save wählen.

Die Firewall unterstützt insgesamt höchstens 20 konfigurierte Authentifizierungsserver. Auch pro Authentifizierungsmethode unter Authentication > Services können höchstens 20 Server ausgewählt werden.

API-Hinweis für SFOS 23: Die API-Referenz zum Hinzufügen und Bearbeiten von RADIUS-Servern ergänzt den optionalen Parameter EmailAddressAttribute (Zeichenfolge, maximal 50 Zeichen) und führt ihn im XML-Beispiel für RADIUSServer auf. Ein Standardwert ist nicht angegeben. Dieser Hinweis betrifft die API-Dokumentation, nicht ein zusätzliches WebAdmin-Feld.

Accounting richtig einordnen

Mit Enable accounting sendet die Firewall bei unterstützten Clienttypen beim Login eine Accounting-Start-Meldung und bei einer normalen Abmeldung eine Accounting-Stop-Meldung. Sophos nennt dafür Windows client, HTTP client, Linux client, Android, iOS, iOS HTTP client, Android HTTP client und API client. Die Start- und Stop-Anfragen enthalten jeweils auch den Zeitpunkt der Anmeldung beziehungsweise Abmeldung.

Beim Herunterfahren oder Neustart der Firewall wird kein Accounting-Stop gesendet. Bleibt auf dem RADIUS-Server eine Sitzung offen, prüft man deshalb den Neustartzeitpunkt zusammen mit den RADIUS-Logs. Diese ausgehende Accounting-Funktion ist nicht das eingehende RADIUS SSO Accounting, mit dem die Firewall fremde Sitzungen lernt.

Microsoft NPS als Gegenstelle vorbereiten

Auf NPS muss die Sophos Firewall als RADIUS-Client vorhanden sein. Der Mindestcheck in der Konsole Network Policy Server lautet:

1. RADIUS Clients and Servers > RADIUS Clients öffnen.
2. Einen New RADIUS Client mit einem eindeutigen Friendly name wie Sophos-Firewall-HQ anlegen.
3. Unter Address (IP or DNS) die Adresse eintragen, von der NPS die Anfrage tatsächlich erhält.
4. Als Vendor üblicherweise RADIUS standard wählen.
5. Dasselbe Shared secret wie auf der Firewall eintragen.
6. In der passenden Connection Request Policy und Network Policy Bedingungen, Zugriffsentscheidung und zulässige Authentifizierungsmethode für den Pilotbenutzer prüfen.
7. Event Viewer und NPS-Accounting-Logs für die Abnahme bereithalten.

Bei HA-Clustern, gerouteten Verbindungen oder NAT darf man die NPS-Clientadresse nicht aus der Topologie erraten. Ein erster Test zeigt in NPS, welche Quell-IP wirklich ankommt. Fehlt die Anfrage vollständig oder kann NPS sie nicht validieren, prüft man zuerst Routing, UDP-Freigabe, RADIUS-Clientadresse und Shared Secret. Ein reguläres Access-Reject verweist dagegen auf Benutzer, Policy oder Authentifizierungsmethode.

RADIUS den richtigen Diensten zuordnen

Nach dem Speichern ist das Serverobjekt noch für keinen Login aktiv. Unter Authentication > Services stehen in SFOS 22 diese Abschnitte zur Verfügung:

• Firewall authentication methods;
• User portal authentication methods;
• VPN portal authentication methods;
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods;
• Administrator authentication methods;
• SSL VPN authentication methods.

Beim User Portal, VPN Portal, VPN und bei Administratoren kann die Serverauswahl an die Firewall-Authentifizierung gekoppelt sein. SSL VPN bietet Same as VPN und Same as firewall. Vor einer Änderung prüft man deshalb zuerst, ob der betroffene Abschnitt eine eigene Liste oder eine gekoppelte Liste verwendet.

Für einen begrenzten Pilotbetrieb fügt man NPS-HQ-RADIUS nur im benötigten Abschnitt hinzu, setzt ihn an die geplante Position und wählt Apply. Die Firewall fragt mehrere Server in der angezeigten Reihenfolge ab. Kann sich derselbe Benutzer schon über einen früheren Server erfolgreich anmelden, wird eine nachgelagerte RADIUS-MFA-Policy nicht erreicht.

Captive Portal und Default Group

Das Captive Portal besitzt unter Authentication > Services keinen eigenen Abschnitt. Es verwendet Firewall authentication methods. Zusätzlich müssen die vorgesehene Zone unter Administration > Device access für Captive portal freigegeben und eine benutzerbasierte Firewall-Regel passend konfiguriert sein. Ein offizieller Funktionstest ist die Anmeldung unter https://<firewall-ip>:8090.

Die Default group unter Firewall authentication methods ist sicherheitsrelevant. Ein externer Benutzer wird beim ersten erfolgreichen Login für einen Firewall-Dienst unter Authentication > Users angelegt. Gibt es keine passende lokale Gruppenzuordnung, greift die konfigurierte Default Group. Vor dem Pilotbetrieb prüft man die Richtlinien der Gruppe und alle Regeln, in denen sie verwendet wird; eine zu weit berechtigte Default Group darf nicht unbemerkt zum Fallback werden.

Challenge-MFA nach Dienst abgrenzen

Das VPN Portal unterstützt laut SFOS-22-Hilfe keine RADIUS-Authentifizierung mit challenge-basierter MFA. Ein erfolgreicher Test connection sagt daher nichts über diesen Portalpfad aus. Push, Call, OTP und Challenge sind ebenfalls nicht austauschbar: Jeder vorgesehene Client und Dienst wird separat getestet. Für lokale Sophos-Firewall-MFA gilt der eigene Ablauf unter MFA für Sophos Firewall WebAdmin, VPN Portal und Remote Access aktivieren.

Konfiguration abnehmen

1. Verbindung und Gegenstelle

Unter Authentication > Servers öffnet man NPS-HQ-RADIUS und führt Test connection mit dem Pilotbenutzer aus. Gleichzeitig prüft man in NPS oder in den Logs der anderen Gegenstelle:

• Anfrage kommt von der erwarteten Firewall-Adresse;
• die richtige Policy verarbeitet sie;
• Ergebnis ist Access-Accept;
• erwartete Rückgabeattribute sind vorhanden.

Der Test bestätigt Credentials und Serverkommunikation. Er bestätigt noch keine Service-Reihenfolge, VPN-Policy, lokale Gruppe oder Firewall-Regel.

2. Echten Dienst testen

Danach meldet man denselben Benutzer über genau den vorgesehenen Dienst an. Für Captive Portal, SSL VPN, IPsec, User Portal und WebAdmin gelten unterschiedliche Voraussetzungen. Beim WebAdmin muss der externe Benutzer zusätzlich das vorgesehene Administratorprofil erhalten; eine erfolgreiche RADIUS-Anmeldung allein erteilt keine Administratorberechtigung. Nicht benötigte Pfade bleiben unverändert. Für SSL VPN führt Sophos Firewall SSL VPN Remote Access einrichten durch Policy, Device Access und Firewall-Regel.

Nach erfolgreicher Anmeldung prüft man:

1. Unter Authentication > Users den lokalen Benutzer, Domain und die tatsächliche Main Group.
2. Unter Current activities > Live users die aktive Sitzung; dort kann man sie bei Bedarf mit Disconnect beenden.
3. Im Log viewer rechts oben in WebAdmin das Modul Authentication öffnen und nach Benutzer, Quell-IP und einem engen Testzeitraum filtern.
4. Im Traffic-Log die tatsächliche Firewall Rule ID und nur die erlaubte Zielressource.
5. Mit einem Benutzer ausserhalb der erlaubten NPS-Policy den Negativfall.

Wenn die Anmeldung funktioniert, aber die Anwendung unerreichbar bleibt, prüft man Zone, VPN-IP-Pool, Gruppe, Regelposition, NAT und Routing. Sophos Firewall-Regel greift nicht: Ursachen prüfen führt durch diesen Datenpfad. Wenn schon Identität, Dienstwahl oder Main Group unklar ist, hilft Sophos Firewall Authentifizierungsfehler systematisch beheben.

Fehler nach Beobachtung eingrenzen

Auf der Gegenstelle kommt keine Anfrage an

Zuerst die unter Server IP und Authentication port konfigurierten Werte prüfen. Danach Routing und die Freigabe für UDP 1812 zwischen der von der Firewall verwendeten Quelladresse und 10.20.30.15 kontrollieren. Ein RADIUS-Serverobjekt erzeugt nicht automatisch eine Transit-Firewall-Regel.

Bei einem von SFOS verwalteten Wireless-Netzwerk dokumentiert Sophos einen eng begrenzten Sonderfall: Ist der RADIUS-Server über einen IPsec-Tunnel mit der Firewall verbunden, wird für die Access-Point-Netze eine Source-NAT-Zuordnung benötigt. Sie übersetzt die Quell-IP auf genau die IP-Adresse der Firewall, über die diese den RADIUS-Server erreicht. Die Wireless-Hilfe verweist dafür auf eine Konfiguration über die Shell mit sys-traffic-nat; sie liefert hier jedoch keinen vollständigen ausführbaren Befehl. Vor einer Änderung müssen AP-Netze, tatsächlich verwendete Quelladresse, Firewall-Adresse für die Quellübersetzung, Tunnel, Rückweg und RADIUS-Logs belegt sein. Die konkrete Shell-Konfiguration einschliesslich Kontrolle und Rückbau bleibt ohne dafür bestätigte Syntax ein Fall für die gezielte technische Eskalation. Für andere RADIUS-Pfade belegt diese Wireless-Anleitung kein allgemeines NAT-Erfordernis. Eine LAN-zu-VPN-Regel oder ein Forwarding-IPsec-Route-Beispiel ersetzt diesen Systemtraffic-Ablauf nicht.

NPS antwortet mit Access-Reject

Ein Reject zeigt, dass Netzwerkpfad und Port grundsätzlich funktionieren. Nun prüft man in NPS den Reason Code, die passende Network Policy, den Benutzerstatus und die erlaubte Authentifizierungsmethode. Ein falsches Shared Secret gehört dagegen zu fehlenden, ungültigen oder nicht verifizierbaren Antworten.

Test connection funktioniert, der Dienstlogin nicht

Unter Authentication > Services den richtigen Abschnitt, Kopplungsschalter, Serverreihenfolge und Apply prüfen. Beim Captive Portal zusätzlich Device access und die benutzerbasierte Firewall-Regel kontrollieren. Bei SSL VPN müssen Policy Member, SSL-VPN-Zugriff unter Device Access und die erforderliche Firewall-Regel stimmen.

Login funktioniert, aber die falsche Gruppe greift

Unter Authentication > Users Domain und Main Group ansehen. Dann Group name attribute, Rückgabeattribute der Gegenstelle und Default group vergleichen. Eine erfolgreiche Authentifizierung ist kein Beweis für die erwartete Autorisierung. Der Negativbenutzer muss deshalb nachweislich an der Gruppen- oder NPS-Bedingung scheitern.

Push oder Challenge endet im Timeout

Den echten Client verwenden und die Zeitpunkte in Firewall-, NPS- und MFA-Provider-Logs vergleichen. Den SFOS-Timeout nur innerhalb von 1 bis 60 Sekunden erhöhen und den kleinsten Wert wählen, der den normalen Challenge-Ablauf zuverlässig abdeckt. Am VPN Portal lässt sich challenge-basierte RADIUS-MFA nicht durch einen längeren Timeout reparieren, weil dieser Pfad von Sophos nicht unterstützt wird.

Sicher zurückbauen

Wenn der Pilotbetrieb scheitert, stellt man im betroffenen Abschnitt unter Authentication > Services die zuvor notierte Serverliste samt Reihenfolge sowie die Kopplungsschalter und die Default group wieder her und wählt Apply. Danach wird der Vergleichsbenutzer über die ursprüngliche Methode angemeldet und der lokale Super-Administrator geprüft.

Erst wenn alle betroffenen Dienste wieder funktionieren, entfernt man NPS-HQ-RADIUS aus weiteren Service-Zuordnungen. Das Serverobjekt unter Authentication > Servers wird nur gelöscht, wenn keine geplante Verwendung mehr besteht. Auf NPS setzt man Client, Policy und Shared Secret auf den dokumentierten Vorzustand zurück. Bereits angelegte lokale Benutzerobjekte bleiben separat zu prüfen; ihr Entfernen beendet nicht automatisch jede bestehende Sitzung, daher kontrolliert man zusätzlich Current activities > Live users.

Betrieb

RADIUS ist ein produktiver Identitätsdienst. Nach Änderungen an NPS, MFA-Provider, AD oder Service-Reihenfolge gehört ein echter Positiv- und Negativlogin zur Abnahme. Das Shared Secret wird geschützt dokumentiert und geplant rotiert. Für die Gegenstelle richtet man Monitoring ein und legt die Aufbewahrung ihrer Entscheidungslogs fest. So bleibt erkennbar, ob ein Fehler vor der Firewall, bei der Authentifizierung oder erst in der Autorisierung entstanden ist.

FAQ