Sophos Firewall: .ovpn fehlt oder hat 0 Byte

Wenn im Sophos Firewall VPN Portal keine verwendbare .ovpn-Datei ankommt, muss zuerst das genaue Fehlerbild geklärt werden. Drei Fälle sehen ähnlich aus, haben aber unterschiedliche Ursachen:

Der Download fehlt vollständig: Meist ist der Benutzer keiner passenden SSL-VPN-Policy zugeordnet oder die erwartete Gruppenmitgliedschaft greift nicht.
Der Download ist sichtbar, aber die Datei hat 0 Byte oder enthält nur eine Fehlermeldung: Erzeugung oder Auslieferung des Profils ist fehlgeschlagen. Dann sind Zertifikatsgenerierung, Logs, Firmwarestand und bei HA der aktive Node relevant.
Die Datei ist nicht leer, aber eine vorhandene Verbindung funktioniert nicht mehr: Das ist normalerweise kein Downloadfehler. Nach Änderungen an Protocol, SSL server certificate, Override hostname oder Port muss ein aktuelles Profil importiert werden.

Diese Trennung spart unnötige Eingriffe. Insbesondere sollte man weder die Default CA auf Verdacht erneuern noch alte Reparaturbefehle aus Community-Beiträgen ausführen.

Fehlerbild im VPN Portal einordnen

Für die erste Prüfung meldet man sich mit dem betroffenen Benutzer am VPN Portal an und öffnet VPN > VPN configuration. Danach werden vier Ergebnisse getrennt dokumentiert: Portal erreichbar, Anmeldung erfolgreich, SSL-VPN-Eintrag sichtbar und heruntergeladene Dateigrösse.

Am aussagekräftigsten ist ein Vergleich mit einem funktionierenden Referenzbenutzer aus derselben SSL-VPN-Policy:

Exakte Testzeit und betroffenen Benutzernamen notieren.
Prüfen, ob der SSL-VPN-Download unter VPN configuration erscheint.
Datei herunterladen und im Betriebssystem die Grösse kontrollieren.
Den gleichen Ablauf mit einem bekannten funktionierenden Benutzer wiederholen.
Festhalten, ob der Fehler nur einen Benutzer, eine Gruppe oder alle Benutzer betrifft.

Funktioniert der Referenzbenutzer, liegt die Ursache eher bei Policy-Zuordnung, Gruppe, User ID oder der Zertifikatsgenerierung des einzelnen Benutzers. Scheitert der Download für alle, werden das gemeinsame SSL-VPN-Zertifikat, Speicher, Pattern, Firmware und bei HA der aktive Node wahrscheinlicher.

Eine .ovpn kann Zertifikats- und Schlüsselmaterial enthalten. Ihr Inhalt gehört nicht in Screenshots, E-Mails oder Supporttickets. Für die Diagnose genügen Dateiname, Grösse, Zeitpunkt und sichtbare Fehlermeldung.

Scheitert bereits der Portalzugriff oder die Anmeldung, liegt der Fehler noch vor der Profilerzeugung. Dann werden Administration > Device access, die VPN-Portal-Authentifizierung und vpnportal.log beziehungsweise access_server.log geprüft. Die vollständige Firewallkonfiguration beschreibt SSL VPN Remote Access einrichten.

Wenn die .ovpn-Datei vollständig fehlt

Die Firewall zeigt SSL-VPN-Konfigurationen nur Benutzern an, die einer Remote-Access-SSL-VPN-Policy zugeordnet sind. Ein erfolgreicher Login am Portal allein beweist diese Berechtigung noch nicht.

Policy und Gruppenmitgliedschaft prüfen

Remote access VPN > SSL VPN öffnen.
Die erwartete Policy bearbeiten.
Unter Policy members kontrollieren, ob der Benutzer oder seine tatsächliche Gruppe eingetragen ist.
Unter Authentication > Users beziehungsweise Authentication > Groups die Gruppenmitgliedschaft gegenprüfen.
Mit dem betroffenen Benutzer neu am VPN Portal anmelden und VPN configuration erneut öffnen.

Ein Benutzer kann sich über eine andere Portalberechtigung erfolgreich anmelden und trotzdem keine SSL-VPN-Konfiguration erhalten. Gastbenutzer und Gastgruppen sind keine gültigen Policy members für Remote Access SSL VPN. Bei identischen direkten Benutzer- oder Gruppenmitgliedern entfernt Sophos Firewall diese beim Speichern der neueren Policy aus der früheren Policy. Deshalb werden die tatsächlich verbliebenen Policy members und überlappende Gruppenmitgliedschaften geprüft.

Nur neue oder einzelne Benutzer sind betroffen

Dann lohnt sich zusätzlich ein Blick auf die interne User ID unter Authentication > Users > Show additional properties. Sophos Firewall unterstützt Benutzer- und Gruppen-IDs nur bis 65535. Eine höhere ID kann den Download verhindern; die sichere Prüfung und Bereinigung steht unter Sophos Firewall User-ID-Limit.

Ein nachweislich erfolgreicher VPN-Portal-Login spricht gegen das User-ID-Limit als primäre Ursache. Entscheidend bleibt jedoch die sichtbare ID des betroffenen Kontos, nicht die Anzahl der Benutzer in der Liste.

Zusätzlich werden Benutzername sowie Subject-Felder von Zertifikat und CA auf Sonderzeichen geprüft. Sophos empfiehlt für diesen Ablauf ASCII-Benutzernamen und keine UTF-8-Zeichen in Zertifikat- oder CA-Feldern. Der Benutzername fliesst in den .ovpn-Dateinamen und in das pro Benutzer erzeugte Zertifikat ein. Ein funktionierender Testbenutzer mit einfachem ASCII-Namen hilft bei der Abgrenzung; produktive AD- oder Entra-Identitäten werden dafür nicht spontan umbenannt.

Wenn der Download 0 Byte hat oder nicht erzeugt wird

Eine leere Datei bedeutet, dass der Downloadlink vorhanden ist, die Erzeugung oder Auslieferung aber keine verwendbare Konfiguration geliefert hat. Sophos nennt unvollständige Zertifikat- oder CA-Konfigurationen als mögliche Ursache. Bevor etwas regeneriert wird, werden Logs und Systemzustand gesichert.

Logs direkt zum Testzeitpunkt sichern

Unter Diagnostics > Tools > Troubleshooting logs lassen sich die relevanten Dateien ohne Eingriff in die Advanced Shell herunterladen. Je nach Fehlerphase sind wichtig:

vpnportal.log für den Abruf im VPN Portal;
access_server.log für die normale Authentifizierung;
oauth_sso_vpn.log bei Microsoft Entra ID SSO;
peruser_cert_sslvpn.log für die benutzerspezifische Zertifikatsgenerierung;
vpncertificate.log für Zertifikate und Certificate Authorities;
sslvpn.log für den SSL-VPN-Dienst.

Die Logs werden auf die zuvor notierte Testzeit und den Benutzernamen eingegrenzt. Wenn Portal und Authentifizierung erfolgreich sind, aber peruser_cert_sslvpn.log zur selben Zeit einen Fehler zeigt, liegt der nächste sinnvolle Prüfpunkt bei Zertifikat und CA. Betrifft der Fehler erst seit einem Upgrade oder HA-Failover alle Benutzer, werden zusätzlich Firmwarestand, aktiver Node und Zeitpunkt des Rollenwechsels dokumentiert. Die Einordnung weiterer Dateien erklärt Sophos Firewall Services und Logs.

Temporären Speicher prüfen

Auch eine volle temporäre Partition kann die Profilerzeugung verhindern. Nach der SSH-Anmeldung an der Sophos Firewall öffnet man 5 Device Management > 3 Advanced Shell und liest den freien Platz aus:

df -kh /tmp

Entscheidend sind die Spalten Avail und Use% für das Dateisystem, auf dem /tmp liegt. Ist praktisch kein Platz mehr frei, werden keine unbekannten Dateien manuell gelöscht. Stattdessen sichert man Logs und Systemzustand und klärt, welcher Prozess den Speicher belegt. Sophos hat mit NC-142397 bereits einen älteren Fehler behoben, bei dem SSL VPN die /tmp-Partition füllte; die Bug-ID ist deshalb ein Versionshinweis, aber keine automatische Diagnose für aktuelle Builds.

SSL-VPN-Zertifikat und Signing CA kontrollieren

Unter Remote access VPN > SSL VPN > SSL VPN global settings zeigt das Feld SSL server certificate, welches Zertifikat die Firewall für den SSL-VPN-Tunnel verwendet. Dieses Zertifikat ist nicht mit dem HTTPS-Zertifikat des VPN Portals unter Administration > Admin and user settings zu verwechseln.

Öffentliche Zertifikatslaufzeiten richtig einordnen

Die angekündigte Verkürzung öffentlich vertrauenswürdiger TLS-Zertifikate bis auf 47 Tage betrifft nicht automatisch die pro Benutzer in der .ovpn eingebetteten X.509-Zertifikate. Diese werden standardmässig von der internen SFOS-CA signiert und gehören nicht zur öffentlichen Web-PKI. Dafür ist weder ein monatlicher Profildownload noch ein Wechsel auf eine öffentliche CA nötig.

Das HTTPS-Zertifikat des VPN Portals und das SSL server certificate des Tunnels bleiben getrennte Rollen. Das Portalzertifikat muss als öffentlich erreichbarer Browserdienst rechtzeitig erneuert werden; dafür kann ein automatisiert erneuertes Let’s-Encrypt-Zertifikat passen. Eine Änderung von Protocol, SSL server certificate, Override hostname oder Port wird dennoch erst nach neuem Download und Import der .ovpn zuverlässig wirksam. Diese Trennung verhindert, dass aus einer verkürzten öffentlichen Laufzeit unnötig die interne SSL-VPN-PKI umgebaut wird.

Danach unter Certificates > Certificates und Certificates > Certificate authorities prüfen:

Ist das ausgewählte SSL-Serverzertifikat vorhanden und noch gültig?
Ist seine ausstellende CA vorhanden und vertrauenswürdig?
Wurde bei einem externen Zertifikat die vollständige Kette aus Intermediate- und Root-CA importiert?
Passt der Fehlerzeitpunkt zu einer Zertifikatsänderung, einem Restore oder einer Migration?

Standardmässig verwendet die Firewall das eingebaute ApplianceCertificate, das von der Default CA signiert wird. Das erklärt die normale Abhängigkeit, beweist aber noch nicht, welches Zertifikatsobjekt den konkreten Fehler verursacht. Ein Fehler in peruser_cert_sslvpn.log darf insbesondere nicht automatisch als defektes ApplianceCertificate interpretiert werden.

Sophos empfiehlt bei einer 0-Byte-Datei, die tatsächlich verwendete Signing CA und das von ihr erzeugte betroffene Zertifikat zu prüfen. Die konkrete Reparatur ist jedoch je nach Zertifikat unterschiedlich:

ApplianceCertificate: Nur für dieses eingebaute Zertifikat dokumentiert Sophos die Aktion Regenerate unter Certificates > Certificates. Sie wird nur verwendet, wenn das ApplianceCertificate als SSL-Serverzertifikat ausgewählt und durch Logmeldung oder Sophos Support als betroffen bestätigt ist.
Externes SSL-Serverzertifikat: Zertifikat, privater Schlüssel, Intermediate-CA und Root-CA als zusammengehörige Kette prüfen und bei belastbarer Fehlermeldung kontrolliert neu importieren. Hier gibt es keinen pauschalen Regenerate-Schritt.
Benutzerspezifisches SSL-VPN-Zertifikat: Ein Fehler in peruser_cert_sslvpn.log betrifft nicht automatisch das SSL-Serverzertifikat. Für das Zurücksetzen dieses Benutzerzertifikats beschreibt Sophos aktuell keinen allgemeinen UI-Ablauf. Die gesicherten Logs werden deshalb an Sophos Support übergeben; alte Shell- oder Datenbankanweisungen werden nicht übernommen.

Ist das betroffene Objekt eindeutig bestimmt, erfolgt die Reparatur kontrolliert:

Aktuelles Firewall-Backup erstellen.
Ausgewähltes SSL-Serverzertifikat, ausstellende CA, konkrete Logmeldung und verwendende Dienste dokumentieren.
Passende Aktion aus den drei Fällen in einem Wartungsfenster ausführen; ist der Fall nicht eindeutig, an Sophos Support eskalieren.
Mit einem Pilotbenutzer eine neue .ovpn herunterladen, importieren und den Tunnel testen.
Erst nach erfolgreichem Pilottest neue Profile an alle betroffenen Benutzer verteilen und weitere betroffene Dienste prüfen.

⚠️ Nicht stattdessen auf Verdacht die Default CA bearbeiten. Beim Speichern wird diese CA neu erzeugt. Das kann deutlich mehr Zertifikate und Vertrauensstellungen betreffen als das einzelne SSL-VPN-Serverzertifikat. Sophos Firewall Default CA kontrolliert erneuern erklärt Inventur, Wartungsfenster, Profilwechsel und Rückweg.

Pattern, Firmware und HA prüfen

Unter Backup & firmware > Pattern updates sollten die automatisch installierten Komponenten einen aktuellen Zeitstempel und Success zeigen. Ein einzelner manueller Abruf mit Update pattern now ist sinnvoll, wenn ein Patternfehler sichtbar ist; wiederholtes Klicken ersetzt keine Diagnose. Der vollständige Ablauf steht unter Pattern-Updates konfigurieren und prüfen.

Auch der exakte Firmware-Build gehört zur Einordnung. Sophos führt NC-149642 – Benutzer konnten die SSL-VPN-Konfiguration nicht aus dem VPN Portal herunterladen – in den behobenen Problemen von SFOS 21.0 MR2 Build 349 und SFOS 22.0 GA Build 411. Weitere ältere Fixes betrafen Downloads nach Upgrades oder HA-Failover. Eine historische Bug-ID beweist die aktuelle Ursache nicht, zeigt aber, warum ein veralteter Build vor tieferen Reparaturen mit den Release Notes verglichen werden sollte. Ein Update wird geplant und nicht während der laufenden Fehlersuche improvisiert; dazu dient Sophos Firewall SFOS-Firmware aktualisieren.

In einem HA-Cluster werden Rolle, aktiver Node und letzter Failover-Zeitpunkt notiert. Tritt der Fehler erst nach einem Rollenwechsel auf, werden die VPN- und HA-Logs des betroffenen Nodes gesichert. Interne Verzeichnisse, Datenbankeinträge oder Symlinks unter /content/sslvpn werden nicht manuell repariert. Solche Eingriffe gehören mit dem gesicherten Fehlerbild zu Sophos Support.

Wenn die Datei vorhanden, aber veraltet ist

Eine nicht leere .ovpn kann korrekt erzeugt und trotzdem nicht mehr zum aktuellen Firewallzustand passen. Nach Änderungen an Protocol, SSL server certificate, Override hostname oder Port muss die Datei erneut heruntergeladen und im Client neu importiert werden. Ist Override hostname leer, können die freigegebenen Interface-Adressen im Profil stehen; auch dann muss ein geändertes Profil neu bezogen werden.

Änderungen an Policy members oder Permitted network resources erfordern dagegen normalerweise nur eine neue Verbindung. Eine .pro-Provisioning-Datei lädt die verfügbare Konfiguration automatisch; bei der Diagnose sollte trotzdem getrennt geprüft werden, ob der manuelle .ovpn-Download funktioniert.

Bei Microsoft Entra ID SSO wird unter Authentication > Services für VPN portal authentication methods und SSL VPN authentication methods derselbe Entra-ID-Server ausgewählt. Danach muss die .ovpn neu heruntergeladen werden. Provisioniert eine .pro zusätzlich IPsec, wird auch VPN (IPsec/dial-in/L2TP/PPTP) authentication methods mit demselben Server geprüft. Die vollständige Abhängigkeit beschreibt Microsoft Entra ID SSO für Sophos Connect und VPN Portal.

Ergebnis prüfen und sauber eskalieren

Der Fehler gilt erst als behoben, wenn derselbe Ablauf mit einem normalen Pilotbenutzer vollständig funktioniert:

Anmeldung am VPN Portal ist erfolgreich.
Erwarteter SSL-VPN-Eintrag ist unter VPN configuration sichtbar.
Heruntergeladene .ovpn ist nicht leer und enthält keine Fehlermeldung.
Neues Profil lässt sich im vorgesehenen Client importieren.
Tunnel wird aufgebaut und erhält eine Adresse aus dem erwarteten SSL-VPN-Pool.
Ein erlaubtes internes Ziel funktioniert per IP-Adresse und Hostname.
Ein absichtlich nicht erlaubtes Ziel bleibt blockiert.

Bleibt die Erzeugung auf einem aktuellen Firmwarestand fehlerhaft, sollte das Supportpaket mindestens Modell, Firmware-Build, HA-Rolle, Fehlerzeit, Benutzer und Gruppe, betroffene Policy, Dateigrösse, sichtbare Fehlermeldung, letzte Änderungen sowie die genannten Logs enthalten. Die eigentliche .ovpn wird nicht mitgeschickt. Für einen reproduzierbaren Fall ist diese Evidenz wertvoller als riskante Änderungen an internen Dateien.