OPNsense Forum
International Forums => German - Deutsch => Topic started by: W0nderW0lf on December 02, 2021, 09:45:15 pm
-
Hi
Der Titel mag etwas komisch klingen, beschreibt aber mein Problem ziemlich genau.
Ich finde leider keine Antwort darauf.
Mein Netz:
WAN / Internet
:
: Kabel
:
.-----+-----.
| Gateway | (Fritzbox)
'-----+-----'
|
WAN | IP or Protocol
|
.-----+------. private DMZ .------------.
| OPNsense +--------------------+ unRAID | (Navidrome"Musik") https://musik.example.com
'-----+------' 192.168.200.0/26 '------------'
|
LAN | 192.168.1.0/24
Seit heute habe ich wieder meinen unRAID im Betrieb der länger wegen eines Defekts ausgefallen ist. Auf meinem unRAID habe ich 2 Container am laufen wovon einer eben Musik Streaming anbietet. Navidrome nennt sich das Ding. Damit ich von überall darauf zugreifen kann, habe ich auf OPNsense den NGINX reverse proxy eingerichtet. Das hatte vor ein paar Wochen auch wunderbar geklappt. Lief alles. Keine nennenswerte Fehler mehr im Log... Long story short:
Wenn ich über meinen Browser musik über https://musik.example.com streame, kann es vorkommen das nach ein paar sekunden bis minuten nichts mehr geht. Also genauer gesagt keine DNS Auflösung mehr. Zumindest Richtung Internet. Im LAN kann ich noch alles bis zur OPNsense und unRAID auflösen. Alles andere ist dann erstmal tot. Das einzige was hier abhilfe schafft, ist ein reboot von OPNsense.
Ich verwende DoT mit unbound DNS, aber da finde ich nichts auffälliges. Das tut laut protokoll weiterhin normal anfragen auflösen, bis auf eben die meiner Clients. Z.B. ein "ping oder whois cloudflare.com" schlägt fehl.
NGINX und Unbound neuzustarten hat leider nichts gebracht. DNS flush cache habe ich auch aktiviert, aber scheint nichts zu nützen. Lediglich OPNsense reboot schafft hier abhilfe.
Wenn ich den Container über die https://IP:Port verwende habe ich keine probleme. Das wäre zwar generell auch in Ordnung, aber verstehen möchte ich trotzdem warum das passiert. In den Logs von NGINX finde ich rein gar nichts was auf die Ursache schließen lässt. Es wird schlicht einfach nichts zu dem Zeitpunkt geloggt.
Meine anderen Clients im LAN haben dann ebenfalls kein Internet mehr. Über das WLAN meiner Fritzbox funktioniert normal alles weiterhin. Also hängt es ausschließlich an OPNsense.
Habt ihr ne idee wonach ich gucken könnte?
-
Vielleicht habe ich den Übeltäter gefunden.
Ich habe für meine example.com wie viele andere auch, eine Wildcard für *.example.com in meiner Lets encrypt Config.
Ich sehe nämlich seit eben folgenden Fehler im allgemeinen NGINX Log:
2021/12/02 20:50:00 warn 81735#100805 "ssl_stapling" ignored, host not found in OCSP responder "r3.o.lencr.org" in the certificate "/usr/local/etc/nginx/key/ncloud.example.com.pem"
2021/12/02 20:50:00 warn 81735#100805 "ssl_stapling" ignored, host not found in OCSP responder "r3.o.lencr.org" in the certificate "/usr/local/etc/nginx/key/mstream.example.com.pem"
Was mich wundert:
2021-12-02T20:12:00 opnsense[64758] AcmeClient: validation for certificate failed: example.com
2021-12-02T20:12:00 opnsense[64758] AcmeClient: domain validation failed (dns01)
2021-12-02T20:11:01 php[78431] AcmeClient: running automation (configd): restart proxy
2021-12-02T20:11:01 php[78431] AcmeClient: running automations for certificate: example.com
2021-12-02T20:11:01 opnsense[78431] AcmeClient: updated ACME X.509 certificate: example.com
2021-12-02T20:11:01 opnsense[78431] AcmeClient: successfully issued/renewed certificate: example.com
acme.log
2021-12-02T20:12:00 acme.sh[87113] { "type": "urn:ietf:params:acme:error:orderNotReady", "detail": "Order's status (\"valid\") is not acceptable for finalization", "status": 403 }
2021-12-02T20:12:00 acme.sh[40347] Sign failed, finalize code is not 200.
2021-12-02T20:12:00 acme.sh[33746] code='403'
Ich hatte um 20:11 das Zertifikat resettet und einen renewal beantragt. Scheinbar hat das nix genützt. Ne Ahnung wo hier der Schuh drückt?
-
Erst einmal - wenn du das nicht konfigurierst, interagiert der nginx maximal mit dem am System konfigurierten DNS server um die Verbindung ins Backend aufzubauen. Ist also sehr unwahrscheinlich.
Was sein kann, ist dass du auf deiner OPNsense ein bisschen Speicherknappheit hast und irgendein Service dann wenn er mal mehr Speicher braucht den OOM-Killer triggert.
Der nginx kann dir auf keinem Fall die Firewall komplett zu machen (außer du hast das so konfiguriert (der spezielle automatisch gepflegte Alias)). In dem Fall würde ich eher ein Problem mit der IDPS ("Einbruchserkennung") vermuten.
-
Also an einer Ressourcen Knappheit zweifel ich. (siehe bild)
In suricata kann ich leider nichts erkennen was auf einen totalen Block hinweisen würde.
Ich vermute wirklich das es mit dem Zertifikat zusammenhängt. Nach meinem renewal gestern lief alles kurzzeitig besser, bis eben die Validierung eine Minute später fehlgeschlagen ist.
Allerdings verstehe ich nicht wo er das Problem hat, denn nach dem renewal hat ACME erstmal gemeldet "OK" und später eben Überprüfung fehlgeschlagen. Da das Problem ausschließlich dann auftritt wenn ich über die subdomain auf den container zugreife, muss es meiner Meinung nach mit dem OCSP und der fehlgeschlagenen Überprüfung zusammenhängen.
Suricata Protokoll
# OPNsense neustart
2021-12-02T22:01:56 suricata[9256] [100308] <Notice> -- This is Suricata version 6.0.4 RELEASE running in SYSTEM mode
2021-12-02T21:59:13 suricata[62155] [100298] <Notice> -- Signal Received. Stopping engine.
# Bevor ich neugestartet habe
2021-12-02T21:16:34 suricata[62155] [100298] <Notice> -- all 12 packet processing threads, 4 management threads initialized, engine started.
2021-12-02T21:15:53 suricata[62155] [100298] <Error> -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "drop tcp $EXTERNAL_NET any -> $HOME_NET $FILE_DATA_PORTS (msg:"SERVER-WEBAPP Pulse Connect Secure template injection attempt"; flow:to_server,established; content:"/dana-admin/auth/custompage.cgi"; fast_pattern:only; http_uri; file_data; content:"LoginPage.thtml"; metadata:policy balanced-ips drop, policy max-detect-ips drop, policy security-ips drop, service ftp-data, service http, service imap, service pop3; reference:cve,2020-8243; reference:url,kb.pulsesecure.net/articles/Pulse_Security_Advisories/SA44588; classtype:attempted-admin; sid:57452; rev:1;)" from file /usr/local/etc/suricata/opnsense.rules/snort_vrt.server-webapp.rules at line 4720
2021-12-02T21:15:53 suricata[62155] [100298] <Error> -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - Can't use file_data with flow:to_server or flow:from_client with http.
2021-12-02T21:15:53 suricata[62155] [100298] <Error> -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "drop tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"SERVER-WEBAPP Oracle GlassFish Server authentication bypass attempt"; flow:to_server,established; content:"GET"; nocase; http_method; content:"/applications/upload"; http_uri; pcre:"/^(Frame)?\.jsf/R"; content:!"JSESSIONID="; flowbits:set,glassfish_unauth_attempt; metadata:policy max-detect-ips drop, service http; reference:bugtraq,47438; reference:cve,2011-0807; classtype:attempted-admin; sid:20159; rev:9;)" from file /usr/local/etc/suricata/opnsense.rules/snort_vrt.server-webapp.rules at line 3542
2021-12-02T21:15:53 suricata[62155] [100298] <Error> -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - pcre with /R (relative) needs preceding match in the same buffer
-
Also mein Verdacht hat sich bestätigt. Es lag an dem Fehler mit OCSP Stapling.
Ich habe das Zertifikat nochmal erneuern lassen. Diesmal scheint es dauerhaft gültig zu sein. Kein Überprüfungsfehler mehr. Nun läuft das ganze jetzt seit ein paar Minuten.
Mir stellt sich jetzt die Frage ob das nicht doch ein Bug ist, denn immerhin hat es die gesamte Kommunikation lahm gelegt.
-
Hab mich wohl zu früh gefreut.
Also es lief ne halbe stunde gut. Dann plötzlich ging nix mehr. Keine Ahnung warum. Ich sehe nix in den logs. total strange.
-
Also es muss doch mit Lets Encrypt zusammenhängen.
Nach meiner wiederholten Erneuerung habe ich im NGINX Log immer noch die OCSP Warning von oben erhalten.
Ich habe nochmal nen reset aller Zertifikate gemacht + die gespeicherten Zertifikate gelöscht und neu beantragt. Zusätzlich habe ich OCSP Stapling und verify nur für den Streaming Server deaktiviert. Nun läuft das seit 1 Stunde ohne probleme. Die Warnung kommt auch nicht mehr. Aber wer weiß... Ich lass das jetzt mal den Tag lang laufen.
-
So... also der Server ist nun ein paar Stunden ohne Probleme gelaufen. Lag scheinbar wirklich am OCSP Stapling. Ich habe selber keine Zertifikatsmeldung gesehen. Scheinbar ist das wirklich ein bug. Der wird aber auch nur dann hervorgerufen, wenn man mit der WebUI interagiert und gleichzeitig streamen will.
Komisches phänomen, aber zumindest weiß ich jetzt was die Ursache war. Falls jemals jemand das gleiche Problem haben sollte... weiß er nun bscheid' ^^