Sophos Firewall RADIUS-Server einrichten

RADIUS ist auf der Sophos Firewall eine wichtige Brücke zu bestehenden Authentifizierungsdiensten. Typische Beispiele sind Microsoft NPS, ein MFA-Gateway, ein Identity-Provider mit RADIUS-Schnittstelle oder eine zentrale Authentifizierungsplattform, die bereits für VPN, WLAN oder andere Netzwerkdienste genutzt wird.

Der Artikel erklärt, wie man einen RADIUS-Server unter Authentication > Servers hinzufügt, welche Felder wichtig sind, wie Microsoft NPS als Gegenstelle vorbereitet wird und wie man die Konfiguration danach sinnvoll testet. Für klassische Benutzer- und Gruppenabfragen aus einer Windows-Domäne passt oft Active Directory mit Sophos Firewall verbinden. Für moderne Remote-Access-Szenarien kann auch Microsoft Entra ID SSO für Sophos Connect und VPN Portal besser passen.

Wann RADIUS sinnvoll ist

RADIUS lohnt sich, wenn die Sophos Firewall nicht selbst die komplette Identitätslogik tragen soll. Die Firewall fragt dann den RADIUS-Server an. Der RADIUS-Server entscheidet, ob Benutzername, Kennwort, Gruppenbedingung, MFA oder Policy passen.

Typische Einsatzfälle:

• Remote Access VPN mit Microsoft NPS.
• Externe MFA-Lösung über RADIUS.
• Zentrale Authentifizierung für VPN Portal, SSL VPN, IPsec Remote Access oder Captive Portal.
• Übergangslösung, wenn AD/LDAP nicht direkt an die Firewall angebunden werden soll.
• Gemischte Umgebungen mit mehreren Netzwerkgeräten, die denselben RADIUS-Dienst verwenden.

RADIUS ist aber kein Ersatz für saubere Zugriffsregeln. Nach erfolgreicher Authentifizierung müssen Firewall-Regeln, VPN-Zonen, Gruppen, IP-Pools und Logging weiterhin stimmen. Für Remote Access passt ergänzend Sophos Firewall SSL VPN Remote Access einrichten, für MFA-Designs MFA für Sophos Firewall WebAdmin, VPN Portal und Remote Access aktivieren.

Vor der Einrichtung planen

Vor dem Klick auf Add sollte klar sein, welche Rolle RADIUS genau übernimmt. Sonst sieht der Verbindungstest zwar erfolgreich aus, der produktive Login scheitert aber später am falschen Dienst, an der falschen Gruppe oder an einem Timeout.

Identitätsquelle und Gegenstelle

In Microsoft-Umgebungen ist RADIUS häufig ein Microsoft NPS-Server. NPS kann Benutzer gegen Active Directory prüfen, Network Policies auswerten und Accounting schreiben. Microsoft beschreibt NPS als RADIUS-Server für zentrale Authentifizierung, Autorisierung und Accounting. In der Praxis bedeutet das: Die Sophos Firewall ist der RADIUS Client, der NPS-Server ist der RADIUS Server.

Wichtig ist diese Rollenverteilung:

• Sophos Firewall: sendet die Authentifizierungsanfrage.
• RADIUS Server: prüft Benutzer, Kennwort, Policy und optional MFA.
• Active Directory oder Identity Provider: liefert Benutzer- und Gruppeninformationen im Hintergrund.
• Firewall-Regel oder VPN-Konfiguration: entscheidet nach dem Login, wohin der Benutzer wirklich darf.

Netzwerkpfad und Ports

Der RADIUS-Server muss von der Firewall aus erreichbar sein. Meistens werden diese Ports verwendet:

Ältere Umgebungen oder einzelne Produkte können noch 1645/UDP und 1646/UDP verwenden. Das sollte man nur übernehmen, wenn die Gegenstelle es wirklich so erwartet.

Shared Secret und Timeouts

Das Shared secret ist das gemeinsame Geheimnis zwischen Firewall und RADIUS-Server. Es ist kein Benutzerpasswort, sondern das technische Geheimnis für den RADIUS-Client. Sophos nennt für dieses Feld ein Limit von 48 Zeichen.

Der Timeout muss zum Anwendungsfall passen. Für reine Kennwortprüfung reicht oft ein kurzer Wert. Bei Push-MFA, Telefonanruf oder externer Challenge kann ein zu kurzer Timeout den Login abbrechen, obwohl Benutzer und Kennwort korrekt sind. Sophos erlaubt für Time-out Werte von 1 bis 60 Sekunden.

RADIUS-Server auf Sophos Firewall hinzufügen

Der Menüpfad lautet:

Authentication > Servers

Vorgehen:

1. Add öffnen.
2. Bei Server type die Option RADIUS server auswählen.
3. Einen eindeutigen Server name vergeben, zum Beispiel NPS-HQ-RADIUS oder MFA-RADIUS.
4. Unter Server IP die IP-Adresse des RADIUS-Servers eintragen.
5. Authentication port prüfen, normalerweise 1812.
6. Time-out setzen. Für einfache Logins zum Beispiel 3 bis 5 Sekunden, für MFA je nach Anbieter eher höher.
7. Enable accounting nur aktivieren, wenn der RADIUS-Server Accounting verarbeiten soll.
8. Falls Accounting aktiviert ist, Accounting port prüfen, normalerweise 1813.
9. Shared secret exakt wie auf dem RADIUS-Server eintragen.
10. Optional Domain name setzen, besonders wenn AD und RADIUS parallel genutzt werden.
11. Optional Group name attribute eintragen, wenn der RADIUS-Server Gruppeninformationen passend liefert.
12. Bei Bedarf Enable additional settings öffnen und NAS-identifier oder NAS-port-type setzen.
13. Test connection mit einem echten Testbenutzer ausführen.
14. Speichern.

Der Verbindungstest prüft, ob Firewall und RADIUS-Server grundsätzlich zusammenarbeiten. Er beweist aber noch nicht, dass VPN Portal, SSL VPN, IPsec Remote Access, Captive Portal oder WebAdmin im produktiven Ablauf funktionieren. Diese Dienste müssen separat getestet werden.

Domain name bewusst setzen

Das Feld Domain name wirkt unscheinbar, ist aber in gemischten Umgebungen wichtig. Wenn RADIUS ohne Domain arbeitet und Active Directory Benutzer mit Domain anlegt, können auf der Firewall doppelte lokale Benutzereinträge entstehen.

Wir empfehlen deshalb: Wenn AD und RADIUS parallel genutzt werden, sollte ein passender Domain Name gesetzt und anschliessend geprüft werden, wie neue Benutzer unter Authentication > Users erscheinen.

Group name attribute nicht raten

Das Group name attribute muss zur Gegenstelle passen. Bei NPS- oder MFA-Integrationen hängt es davon ab, welche Attribute der RADIUS-Server tatsächlich zurückliefert und wie die Firewall sie auswerten soll. Ein zufällig eingetragener Wert erzeugt oft schwer verständliche Gruppenprobleme.

Wenn die Gruppe wichtig ist, sollte man den kompletten Ablauf testen:

1. Benutzer am Zielportal oder VPN anmelden.
2. Prüfen, ob der Benutzer unter Authentication > Users mit erwarteter Gruppe erscheint.
3. Im Log Viewer prüfen, welche Firewall-Regel und welcher Benutzer für den Traffic sichtbar sind.
4. Bei NPS zusätzlich Event Viewer und Network Policy prüfen.

Microsoft NPS als Gegenstelle vorbereiten

Wenn Microsoft NPS verwendet wird, muss die Sophos Firewall auf dem NPS-Server als RADIUS Client eingetragen werden. Microsoft beschreibt dafür den Bereich RADIUS Clients and Servers > RADIUS Clients in der NPS-Konsole.

Minimaler Ablauf auf dem NPS-Server:

1. Network Policy Server öffnen.
2. RADIUS Clients and Servers > RADIUS Clients öffnen.
3. New RADIUS Client erstellen.
4. Friendly name vergeben, zum Beispiel Sophos-Firewall-HQ.
5. Unter Address (IP or DNS) die IP-Adresse der Sophos Firewall eintragen, von der die RADIUS-Anfragen kommen.
6. Als Vendor meist RADIUS standard verwenden.
7. Dasselbe Shared secret wie auf der Sophos Firewall eintragen.
8. Passende Connection Request Policy und Network Policy erstellen oder prüfen.
9. Event Viewer und NPS-Logs für spätere Tests bereithalten.

Bei HA-Clustern oder mehreren Firewalls muss man bewusst prüfen, welche Quell-IP beim NPS ankommt. Wenn der NPS eine andere Quell-IP sieht als eingetragen, wird die Anfrage abgelehnt oder gar nicht der erwarteten Policy zugeordnet.

RADIUS für Firewall-Dienste aktivieren

Nach dem Speichern des RADIUS-Servers ist er noch nicht automatisch für alle Logins aktiv. Die Zuordnung erfolgt unter:

Authentication > Services

Dort muss man pro Dienst entscheiden, ob RADIUS verwendet werden soll:

• Firewall authentication methods: allgemeine Firewall-Authentifizierung.
• VPN portal authentication methods: Login am VPN Portal.
• SSL VPN authentication methods: Login für SSL VPN.
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods: relevante Remote-Access-VPN-Methoden.
• Captive portal authentication methods: Anmeldung über Captive Portal.

Die Reihenfolge der Server ist wichtig. Wenn mehrere Server ausgewählt sind, fragt die Firewall sie in der konfigurierten Reihenfolge ab. Das kann gewollt sein, kann aber auch dazu führen, dass Benutzer über AD statt über RADIUS authentifiziert werden und MFA nicht greift.

Validierung nach dem Speichern

Ein guter Test besteht aus mehreren Ebenen. Nur Test connection reicht nicht.

Verbindungstest

Unter Authentication > Servers den RADIUS-Server öffnen und Test connection mit einem Testbenutzer ausführen. Wenn dieser Test fehlschlägt, zuerst Netzwerkpfad, Quell-IP, Shared Secret, NPS-Client, Port und Benutzerkennwort prüfen.

Diensttest

Danach den echten Zielablauf testen:

1. VPN Portal mit Testbenutzer öffnen.
2. SSL VPN oder Sophos Connect mit Testprofil anmelden.
3. Captive Portal testen, falls es verwendet wird.
4. Bei Admin-Zugriff prüfen, ob lokale Admin-Berechtigungen, Rolle und Authentifizierung zusammenpassen.

Bei RADIUS-MFA muss der komplette Challenge- oder Push-Ablauf mit dem echten Client getestet werden. Ein erfolgreicher Server-Test ist kein Nachweis, dass Sophos Connect, VPN Portal oder WebAdmin das Challenge-Verhalten gleich behandeln.

Logs prüfen

Für die Fehleranalyse sind mehrere Stellen relevant:

• Log Viewer auf der Sophos Firewall für Authentifizierungs- und Traffic-Entscheidungen.
• Authentication > Users für automatisch angelegte Benutzer und Gruppenzuordnung.
• NPS Event Viewer auf Windows für erfolgreiche oder abgelehnte Anfragen.
• RADIUS- oder MFA-Provider-Logs, wenn ein Drittanbieter beteiligt ist.
• Firewall-Regel-Logs, wenn der Login funktioniert, aber kein Traffic erlaubt wird.

Wenn der Benutzer authentifiziert ist, aber keine Anwendung erreicht, ist RADIUS meist nicht mehr die erste Ursache. Dann sollten VPN-Zone, IP-Pool, Firewall-Regel, Gruppenbedingung, NAT und Routing geprüft werden. Für diesen Teil passt Sophos Firewall Regel greift nicht: Ursachen prüfen.

Typische Fehler

Test connection schlägt fehl

Häufige Ursachen sind falsche Quell-IP, falsches Shared Secret, blockierter UDP-Port, fehlender RADIUS Client auf NPS oder eine NPS-Policy, die den Testbenutzer nicht erlaubt. Auf Windows sollte man im Event Viewer prüfen, ob die Anfrage überhaupt ankommt.

Test connection funktioniert, VPN Login nicht

Dann ist der RADIUS-Server grundsätzlich erreichbar, aber der verwendete Dienst ist wahrscheinlich nicht korrekt auf RADIUS gesetzt. Unter Authentication > Services prüfen, ob der richtige Server bei VPN Portal, SSL VPN oder IPsec Remote Access ausgewählt ist und an der erwarteten Position steht.

MFA-Push kommt zu spät oder gar nicht

Bei externer MFA sind Timeouts häufig der Knackpunkt. Der Timeout auf der Sophos Firewall, die NPS-Policy, das MFA-Gateway und der Client müssen zusammenpassen. Bei Push- oder Telefon-MFA sollte man nicht mit zu aggressiven drei Sekunden starten.

Benutzer wird doppelt angelegt

Das passiert oft, wenn AD und RADIUS parallel verwendet werden und RADIUS ohne Domain name arbeitet. Dann entstehen unterschiedliche lokale Benutzereinträge, obwohl fachlich derselbe Benutzer gemeint ist. Domain Name, Loginformat und Serverreihenfolge prüfen.

Login funktioniert, aber die Regel matcht nicht

Dann muss man Benutzer- und Gruppenmatching prüfen. Relevant sind die importierte Gruppe, der lokale Benutzereintrag, die Regelposition, die Source Zone, der VPN-IP-Pool und der tatsächliche Traffic im Log Viewer.

Betrieb und Sicherheit

RADIUS sollte wie ein produktiver Identitätsdienst betrieben werden. Wenn der RADIUS-Server ausfällt, kann Remote Access oder Portalzugriff betroffen sein.

Wichtige Betriebspunkte:

• Shared Secret sicher dokumentieren und bei Personal- oder Providerwechsel bewusst rotieren.
• NPS- oder RADIUS-Logs ausreichend lange aufbewahren.
• RADIUS-Server überwachen, nicht nur die Firewall.
• MFA-Timeouts nach Client- und Portaltyp testen.
• Fallback-Adminzugang definieren, aber nicht breit exponieren.
• Nach Änderungen an AD, NPS, MFA-Provider oder Firewall-Services einen echten Login testen.

RADIUS ist ein guter Baustein, wenn er sauber betrieben wird. Ohne Monitoring, klare Serverzuordnung und echte Diensttests verschiebt man Loginprobleme nur von der Firewall auf ein anderes System.

FAQ