Messages

76

German - Deutsch / Re: Bug? Kein Internet über OPNsense - vermutlich wegen NGINX Proxy

« on: December 03, 2021, 01:20:23 pm »

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.

77

German - Deutsch / Re: Bug? Kein Internet über OPNsense - vermutlich wegen NGINX Proxy

« on: December 03, 2021, 09:17:40 am »

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.

78

German - Deutsch / Re: Bug? Kein Internet über OPNsense - vermutlich wegen NGINX Proxy

« on: December 03, 2021, 08:52:21 am »

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.

79

German - Deutsch / Re: Bug? Kein Internet über OPNsense - vermutlich wegen NGINX Proxy

« on: December 03, 2021, 07:55:20 am »

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

Code: [Select]

# 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


80

German - Deutsch / Re: Bug? Kein Internet über OPNsense - vermutlich wegen NGINX Proxy

« on: December 02, 2021, 10:08:54 pm »

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:

Code: [Select]

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:

Code: [Select]

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

Code: [Select]

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?

81

German - Deutsch / Bug? Kein Internet über OPNsense - vermutlich wegen NGINX Proxy

« 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?

82

German - Deutsch / Re: 21.7.5 Update Fehler?

« on: November 12, 2021, 03:15:20 pm »

Hat jetzt geklappt. Hab's spaßeshalber deaktiviert, neugestartet, Mirror auf default gesetzt und nochmal preffer ipv4 aktiviert. Jetzt gehts. Danke!

83

German - Deutsch / Re: 21.7.5 Update Fehler?

« on: November 12, 2021, 03:06:16 pm »

Das gleiche problem hatte ich in der Vergangenheit schon mal und das war bereits angehakt:
Pv4 gegenüber IPv6 bevorzugen    Bevorzuge die Verwendung von IPv4 auch wenn IPv6 verfügbar ist

Daran kann das also eigentlich nicht liegen. ich kanns mal deaktiviert testen, aber das wird vermutlich nichts nützen.

84

German - Deutsch / Re: 21.7.5 Update Fehler?

« on: November 12, 2021, 03:01:48 pm »

Ich habe sogar den Mirror geändert und nochmal neugestartet, aber das scheint nicht zu helfen.

***GOT REQUEST TO AUDIT CONNECTIVITY***
Currently running OPNsense 21.7.5 (amd64/LibreSSL) at Fri Nov 12 15:00:55 CET 2021
Checking connectivity for host: mirror.fra10.de.leaseweb.net
PING 37.58.58.140 (37.58.58.140): 56 data bytes

--- 37.58.58.140 ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss
ping6: UDP connect: No route to host
Checking connectivity for URL: http://mirror.fra10.de.leaseweb.net/opnsense/FreeBSD:12:amd64/21.7
Updating OPNsense repository catalogue...
Fetching meta.conf: . done
Fetching packagesite.txz: .......... done
Processing entries: .......... done
OPNsense repository update completed. 764 packages processed.
Updating SunnyValley repository catalogue...
Fetching meta.conf: . done
Fetching packagesite.txz: .. done
Processing entries: .... done
SunnyValley repository update completed. 31 packages processed.
All repositories are up to date.
***DONE***

85

German - Deutsch / Re: 21.7.5 Update Fehler?

« on: November 12, 2021, 02:55:16 pm »

Wo genau finde ich den?
edit: habs gefunden. warte gerade bis der fertig ist.

86

German - Deutsch / Re: 21.7.5 Update Fehler?

« on: November 12, 2021, 02:51:05 pm »

Hmm.. habs gemacht. Hab nochmal nach updates gecheckt. Base und Kernel scheinen noch nicht geupdated. Jetzt hängt der wieder an der gleichen stelle. Da ist doch der wurm drin.

87

German - Deutsch / 21.7.5 Update Fehler?

« on: November 12, 2021, 02:40:29 pm »

Mein Update scheint fest zu hängen. Soll ich die Kiste neustarten, oder noch ein weilchen warten?

Code: [Select]

/var/cache/pkg/bind-tools-9.16.22~8ed803a563.txz
/var/cache/pkg/bind-tools-9.16.22.txz
The cleanup will free 41 MiB
Deleting files: .......... done
All done
Nothing to do.
Starting web GUI...done.
Generating RRD graphs...done.
Fetching base-21.7.5-amd64.txz: ...

88

German - Deutsch / Re: Firewall Verständnisfrage - Radius WLAN

« on: October 31, 2021, 08:32:53 am »

Ich kann schwer nachvollziehen wo und wie du deine Regeln gestaltet hast. Generell gilt die Frage, hat dein WLAN auch eigene Regeln. Schließlich müssen die WLAN Clients ja auch irgendwohin kommunizieren dürfen.
Wie sehen die Regeln da aus?

89

German - Deutsch / Re: Sensei stürzt ab (Swap)

« on: October 31, 2021, 08:12:24 am »

Zenarmor -> Konfiguration -> Updates & Health -> Swap Max Utilization (30-45%)
Vermutlich müsstest das anpassen. Sensei braucht nicht wenig wenn das flüssig laufen soll. Ich musste mehr RAM bei mir einbauen und die max swap ut. höher stellen damit der reibungslos läuft.

90

German - Deutsch / Re: Naxsi Rules erstellen - wie richtig whitelisten?

« on: October 31, 2021, 08:00:08 am »

Wo finde ich raus welche Regeln hier noch blocken? Ich habe bisher nur ID 17 gesehen und das habe ich bereits gewhitelisted. Im Learning mode tut sich leider nix mehr im error log.