OpenVPN LDAPS-Authentifizierung schlägt plötzlich fehl

DarkMasta

Hallo Zusammen
Ich stehe aktuell vor einem sehr merkwürdigen Problem mit der OpenVPN-Authentifizierung via LDAPS auf unserer pfSense und hoffe auf eure Hilfe.

Ausgangslage:
Wir haben vor Kurzem unsere Domain Controller von Windows Server 2016 auf Windows Server 2025 migriert und im selben Zug alle 4 OpenVPN-Server auf der pfSense auf LDAPS umgestellt.

Problembeschreibung:
In unregelmäßigen Abständen (teilweise läuft es mehrere Tage am Stück völlig problemlos) schlägt die Authentifizierung spontan für alle 4 OpenVPN-Instanzen gleichzeitig fehl.

Fehlermeldung im Auth-Log:

/openvpn.auth-user.php: ERROR! Could not bind to LDAP server contriaINT. Please check the bind credentials.

Unter Diagnostics > Authentication schlägt der Verbindungstest in diesem Zustand ebenfalls fehl.
Obwohl zwei unterschiedliche LDAPS-Server als Auth-Quellen in pfSense hinterlegt sind, schlägt der Bind zu beiden fehl.

Das Phänomen ("Weckruf" durch WebGUI-Login):
Gestern Nachmittag fiel die Authentifizierung erneut aus. Als ich mich heute Morgen im Büro lokal auf der WebGUI der pfSense angemeldet habe, funktionierte die VPN-Authentifizierung schlagartig wieder – ohne, dass ich Einstellungen geändert oder Dienste neugestartet hätte. Es wirkt fast so, als würde der Log-in in die WebGUI einen blockierten Prozess, TCP-State oder Cache wieder "aufwecken".

Bisherige Lösungsversuche:

Timeouts: Das Server Timeout im Authentication Server auf 5 Sekunden angehoben (leider ohne Erfolg).
Hostname von Auth Server im DNS hinterlegt (Vorher war es nur ein Domain Override)

Hat jemand ein ähnliches Verhalten beobachtet oder eine Idee, warum die LDAPS-Verbindung sporadisch einfriert?

Systemumgebung:
pfSense Version: 2.8.1-RELEASE
LDAP-Server / Backend: Windows Server 2025 mit Active Directory
Verbindungsart: LDAPS (Port 636 über SSL/TLS encrypted)
OpenVPN Modus: Remote Access (User Auth)

Vielen Dank im Voraus für eure Hilfe!

Gruss

JeGr

Moin,

ich habe in der Erklärung nirgends was zum Zertifikat gelesen. Damit der Auth sauber und konsistent funktioniert, muss die Zertkette sauber sein und ordentlich funktionieren. Tut sie das nicht, hat man Auth Probleme weil die Verbindung zum Server fehl schlägt und nicht authentifiziert werden kann.

Haben beide Auth Server die hinterlegt sind eine saubere Zertifikatskette mit CA, die auf der Sense hinterlegt ist? Sind die Zertifikate auf den Servern fest und ändern sich nicht? Wir hatten den Fall auch schon dass Zertifikate auf dem Server von anderen Zerts "verdrängt" wurden (irgendein Windows Bullshit dass ein anderes Zert vorrang hatte und damit dann die Kette weil falsche CA gebrochen war). Solche Dinge vllt nochmal gegenprüfen.

Ansonsten auf der pfSense sicherheitshalber mal auf der Konsole WebUI und PHP-FPM neu starten nachdem die Verbindung geht, damit man prüfen kann, dass jeder PHP Thread auch sauber mit der aktuell für LDAPS gültigen CA ausstaffiert ist.

Einloggen in die UI startet aber nichts neu :) Entweder wurde da im Hintergrund gerade eh was neu gestartet oder beendet oder es war ein doofer Zufall aber sollte an der Stelle eigentlich nichts miteinander zu tun haben. Allerdings kennen wir sonst ja dein Setup nicht, insofern - ausgeschlossen ist es nicht ;)

Den meisten Trouble mit LDAPS haben wir eigentlich eher bei Umstellung auf LDAPS weil sowas wie die Cert-Kette bzw. die CA nicht stimmt. Das scheint ja aber zumindest manchmal zu passen, daher würde ich da eher Details suchen wie eben das Zert oder ggf. Prozesse die nicht alle neugestartet wurden nach Umstellung auf LDAPS.

Cheers :)

DarkMasta

Moin @JeGr
Danke dir für deinen Input! Den Teil mit den Zertifikaten hatte ich eingangs ausgelassen, da die Verbindung tagelang am Stück problemlos funktioniert. Daher bin ich davon ausgegangen, dass die Zertifikatskette grundsätzlich sauber ist.

Zu unserer Infrastruktur:

Wir betreiben eine interne Windows Enterprise CA. Das CA-Zertifikat ist auf der pfSense hinterlegt und bei den Authentication Servern als "Peer Certificate Authority" ausgewählt.
Die LDAP-Server sind in pfSense per FQDN hinterlegt. Die FQDNs werden von der pfSense sauber aufgelöst.
Die Server-Zertifikate werden alle 365 Tage erneuert. Da die Windows Server 2025 erst wenige Wochen alt sind, gab es bisher noch keine Zertifikats-Rotation.
Der Befehl openssl s_client -connect <DC_IP>:636 -showcerts liefert aktuell (im funktionierenden Zustand) exakt das erwartete LDAP-Zertifikat zurück.

Was mich extrem stutzig macht und eher gegen ein Zertifikatsproblem spricht:
Wenn der Ausfall auftritt, betreffen die Fehlschläge zeitgleich alle 4 OpenVPN-Instanzen. Diese nutzen zwei unterschiedliche LDAP-Server mit jeweils eigenen CAs. Dass beide DCs zeitgleich ein Zertifikatsproblem entwickeln und sich zeitgleich wieder fangen, erscheint mir unwahrscheinlich.

Es wirkt für mich eher so, als gäbe es ein gemeinsames Nenner auf der pfSense – zum Beispiel, dass pfSense nach X Stunden in ein Socket-/Timeout-Problem läuft oder der DNS-Resolver / PHP-FPM blockiert.

Heisst wenn es zu einem erneuten Ausfall kommt:
-Testen ob der Hostname noch aufgelöst werden kann
-Testen ob der Hostname noch Pingbar ist
-Testen welches Zertifikat mit dem obenstehenden Befehl geliefert wird
-/etc/rc.php-fpm_restart ausführen
-Eventuell DNS Resolver neu starten

Hast du vielleicht noch weitere Checks bei einem Ausfall oder spezifische Logs wo helfen könnten?

Gruss

DarkMasta

Update
Heute Morgen ist der Fehler erneut aufgetreten. Hier der relevante Auszug aus dem Authentifizierungs-Log:

Jul 27 08:58:52	openvpn	64884	/openvpn.auth-user.php: ERROR! Could not bind to LDAP server contriaINT. Please check the bind credentials.
Jul 27 08:58:45	openvpn	64884	user 'User_3 could not authenticate.
Jul 27 08:58:45	openvpn	64884	/openvpn.auth-user.php: ERROR! Could not bind to LDAP server contriaINT. Please check the bind credentials.
Jul 27 08:58:40	openvpn	64884	user 'User_3' could not authenticate.
Jul 27 08:58:40	openvpn	64884	/openvpn.auth-user.php: ERROR! Could not bind to LDAP server contriaINT. Please check the bind credentials.
Jul 27 08:42:45	openvpn	64884	user 'User_4' could not authenticate.
Jul 27 08:42:45	openvpn	64884	/openvpn.auth-user.php: ERROR! Could not bind to LDAP server contriaINT. Please check the bind credentials.
Jul 27 08:38:10	openvpn	54810	user 'User_1' authenticated
Jul 27 08:38:00	openvpn	33838	user 'User_1' authenticated
Jul 27 08:37:58	openvpn	28831	user 'User_5' authenticated
Jul 27 08:37:53	openvpn	64884	user 'User_1' could not authenticate.
Jul 27 08:37:53	openvpn	64884	/openvpn.auth-user.php: ERROR! Could not bind to LDAP server contriaINT. Please check the bind credentials.
Jul 27 08:36:56	php-fpm	84141	/index.php: Successful login for user 'admin' from: 10.49.255.204 (Local Database)
Jul 27 08:36:45	php-fpm	84141	/index.php: Session timed out for user 'admin' from: 10.49.255.204 (Local Database)
Jul 27 08:17:36	openvpn	84141	user 'User_2' authenticated

Spannendes Detail im Log:
Während der PHP-Prozess mit der PID 64884 dauerhaft fehlschlägt, konnten andere PIDs (28831, 33838, 54810) dazwischen erfolgreich authentifizieren. Das Problem betrifft also offenbar gezielt hängende PHP-Worker-Prozesse bzw. veraltete Socket-Handles.

Ich habe sofort folgende Tests auf der pfSense-Konsole durchgeführt, während der Fehler aktiv war:

Ping auf den Hostnamen des DCs: Erfolgreich.
DNS-Auflösung des DCs: Funktionierte, wirkte aber gefühlt etwas verzögert ("hat ein wenig gedauert").
Zertifikat via OpenSSL: openssl s_client -connect <DC_IP>:636 -showcerts hat sofort das korrekte LDAPS-Zertifikat geliefert.
PHP-FPM Restart: Ich habe /etc/rc.php-fpm_restart ausgeführt. Direkt danach funktionierte die OpenVPN-Authentifizierung sofort wieder für alle Benutzer!

Hat jemand eine Idee, wie ich dieses Problem in den Griff bekomme?

JeGr

@DarkMasta das klingt extrem seltsam. Und das Verhalten ist jedes Mal dasselbe? Also dass ein Thread Probleme mit der Authentifizierung hat?
Zumal das kein PHP Prozess war. 64884 war ein OpenVPN Prozess, kein PHP-FPM. Das verwundert mich dann schon.
Wenn das wieder auftritt, kannst du dann ggf. noch ein ps auxwwd auf der Konsole oder via Commands abfeuern, dann könnte man schauen, welcher OVPN Prozess in der Hierarchie da vllt. ein Problem hat oder ob das alles Main Threads sind.

Ich habe Auth Probleme schon gehabt aber immer nur bei Änderungen an der LDAPS Konfiguration und danach dann weil ggf. ein PHP Prozess noch nicht geschnallt hatte, dass es was Neues gibt. Durchtreten vom FPM war dann aber das Problem weg. Und die OVPN Prozesse sollten gar kein Problem haben, die reichen das eigentlich nur weiter.

Sehr merkwürdig. Ansonsten müsste man das als potential bug eskalieren, damit sich das zumindest mal jemand von Netgate anschauen kann.

Cheers