Messages

Okay... Ich hab hier einen Vault, das ist ein Server, der Vault von Hashicorp laufen hat. Dies beinhaltet den ACME Endpunkt, den ich von der OpnSense mit dem ACME-Plugin erreichen will. Dieser Vault hat ein Zertifikat von einer Kompletten CA, die in OpnSense verfügbar ist, also im Trust gespeichert.
Wenn ich das ACME-Plugin daraufhin konfiguriere, von diesem Vault-Server (NICHT von der opnsense) zu holen, dann fliegt er auf die Nase, weil CURL das Zertifikat nicht validieren kann. Auf dem Vault-Server ist ein valides Zertifikat hinterlegt (Name, Gültigkeit etc). Die dazugehörige CA im OpnSense unter trust. Gibt es also in der OpnSense eine möglichkeit dem curl noch zusätzlich ein Zertifikat hinzuzufügen, damit er kein Problem mit dem Endpunkt hat?

Ich benutze auf der OpnSense in der Tat das ACME Plugin. Das ist ja "under the hood" ein Shell-Skript, was zu bestimmten Tasks curl verwendet. Soweit ist alles okay.

Bislang hab ich nur lets encrypt für extern erreichbare Seiten verwendet. Nun möchte ich, dass OpnSense für eine interne Seite ein internes Zertifikat verwendet.
Dazu müsste das Plugin über die URL einer Custom CA von dem Vault sich das Certifikat holen (Ja, da passiert mehr, aber für die Verdeutlichung reicht es glaub ich :)). Wenn es allerdings versucht das zu tun, schlägt es mit der Fehlermeldung CURLE_PEER_FAILED_VERIFICATION (60) fehl. Da der Vault über ein aktuelles und korrektes Zertifikat verfügt kann ich mir nicht vorstellen das es daran liegt. Dieses Zertifikat ist ausgestellt von der gleichen internen CA, die Komplett (Root-CA + Intermediate CA + Intermediate CA Cloud) auch im Trust/Authorities importiert ist.

Was ich vermute bzw. wonach ich gefragt hab: Kann es sein, dass das curl eben nicht die Chains aus dem Trust/Authorities verwendet? Das wäre für mich die einzige vernünftige Erklärung, warum es zu diesem Fehler kommt.

Hoffe das ich mich besser ausgedrückt hab. :D

Hi,

ich hab zwei interne CAs (Vault). Die per ACME certifikate ausstellen können. Beide haben custom Zertifikate, die von der OpnSense ausgestellt wurden. D.h. die komplette chain ist in OpnSense verfügbar. Wenn ich nun über den ACME-Client ein Zertifikat von einem der Vault holen will, dann fällt das auf die Nase. Ich erhalte den Errorcode 60, der besagt, dass das Zertifikat nicht gültig ist. (CURLE_PEER_FAILED_VERIFICATION (60)).
Kann es sein, dass ich die Ca-Chain noch anders in OpnSense importieren muss? Das es über das Web-Frontend nicht reicht und curl damit die chain damit nicht nutzen kann?

Muss ich die Ca-chain noch irgendwo importieren? Also wie bei ubuntu über den update-ca-certificates prozess?

Danke für Tipps

m.

When enabling auth in the postfix service, it complains about:

warning: /usr/local/etc/postfix/smtp_auth: logical line must not start with whitespace: " username:password"

when looking into the file, there is a leading whitespace.

When I'm looking in the config.xml there is no leading whitespace (as well as in the gui of opnsense)

I think it looks like a but

cheers

marc

Ja, die Empfehlung ist nicht nur die von franco... Grundsätzlich sollte/muss alles nicht benötigte abgeschaltet werden. So ist das bei mir auch... NUR: Wenn ich halt das Binding von unbount an das WLAN-Interface deaktiviere, dann resolvd er nicht mehr... Zumindest auf dem LAN. Auf localhost resolved er noch. Und ja, UDP/TCP für DNS ist vom gesamten LAN-Netz erreichbar, also freigegeben. Nur halt: WLAN in unbound zusätzlich an, apply gedrückt dann geht alles. WLAN als interface aus der unbound-Konfig rausgenommen (haken weg), apply => Keine Resolution mehr... :(

Eine opnsense mit einem WAN und einem LAN Interface. Wenn ich unbound auf dem WAN interface deaktiviere antwortet unbound nicht mehr... ok, wenn das einen netzwerkplan braucht male ich einen. [emoji2] Screenshots kommen


Gesendet von iPhone mit Tapatalk

Eigentlich brauche ich auf dem WAN Interface keinen DNS Server laufen, muss ich aber...
Die opnsense hängt in zwei Netzen. WAN und LAN. Wenn ich nun den unbound nur auf dem LAN Interface aktiviere, nicht auf dem wan dann resolvt er nicht mehr. Er lauscht noch auf dem lan Port aber antwortet nicht mehr. Aktiviere ich den WAN im unbound dann geht wieder alles...

Ist das so gewollt?!? [emoji38]


Gesendet von iPhone mit Tapatalk

Oh doch... Das Logging ist nicht aktiv... Das hat mich ja so irritiert.
Das betrifft die Regelnummern 64 und 65... Aber beide haben kein Logging aktiviert... :(

Hallo Franco,

danke für den Hinweis. Nur kann ich bei den Regel ja lediglich das Logging Aktivieren (Log packets that are handled by this rule) ABER: Wenn ich mir die Regel anschaue, die einschlägig ist, ist da kein Haken.. Sie dürfte eigentlich nicht loggen... Oder steht das wo anders? Wo kann ich das dann noch ausschalten?

Hallo,

kann man das was in der Firewall-Live-View angezegt bekommen eigentlich auch mit Ausschlüssen versehen?

Hab den Traffic vom Admin-Frontend per NGINX anderweitig verfügbar gemacht. Jetzt: Hab ich den Traffic vom nginx zum admin-frontend ständig drin. Und gerade wenn ich die Live-View anschaue, dann pumpt das ja ordentlich durch, weil es sich selbst ja auch darstellen möchte... Und das vervielfacht ja alles.

Ich würd gern das was von dem nginx zu dem port auf einem nicht-WAN Interface geht ausschließen. Kann man das irgendwie bewerkstelligen?

Moin, bin die ganze Zeit am suchen, ob man dies setting über die ui setzen kann. Vielleicht bin ich nur blind.

Hab halt eine self signed root ca und zwei intermediates bis hin zum Client cert, mit dem ich mich authentifizieren muss. Bislang komm ich nur zu einem 400er beim request. Denke mal, dass es an der verify depth liegt...

Cheers
M.

Hi Franco,

meine wiederholte Frage, war die: "wie testet ihr, wie ist eure Strategie/QA"?
Ach ja, um es zu quantifizeren: Die Frage war etliche male von mir in diesem Thread von mir gestellt worden.
UND NEIN, ich hab nicht um Hilfe nachgesucht!! (um auch dies zu quantifizieren)

"Prompt" ist übrigens auch etwas was man unter qualitativen und quantitativen Aspekten beleuchten sollte! ;)

Für mich ist damit klar geworden, wie die Test-Strategie aussieht...

[ein]

In den Docs selbst ist kaum was zu tests zu finden. In den Makefiles gibt's was zu Regressionstests. Damit endet das Thema Tests in der Doku.
Ja acme.sh gehört zu einem Plugin, war aber auch nur ein Beispiel von zweien, das andere gehörte in den Core.

Tests gehören zum Alltag von Softwareentwicklern und, ja, auch zu Community-Projekten. Es sei denn, man steht auf dem Standpunkt, dass Community-Projekte so cool sind, dass sie ohne Tests auskommen.
Sorry, das kann man durchaus anders sehen.

Naja, mittlerweile hab ich meine Portweiterleitungen wieder gefixt, die offenbar nichts mit meiner Config zu tun gehabt haben. Es war ein Core-Modul, was die alten Configs ignoriert hat, nach Neuanlage der Rules lief es durch. Aber gut, brauchen ja keine Tests, sind ja community...  ;D 8)

Ja, natürlich weil es ein community Projekt ist, stelle ich die Frage nach z. B. Tests. Heißt ja nicht, weil etwas community ist kommt es ohne aus. Eher im gegenteil. Viele Projekte aus der community sind deutlich stabiler und besser abgesichert als kommerzielle Produkte. Das liegt gerade daran, dass die maintainer ein hohes Interesse an der Stabilität haben. Insofern habe ich gehofft, dass ich auf die Frage auch ein einfaches "schau mal, hier sind die Tests und so arbeiten wir hier mit ihnen" als Antwort bekomme.
Wenn die Leute von Cisco oder sophos einen nicht so guten Job machen, sollte uns das nicht wirklich interessieren, auch sollten wir uns dann daran auch nicht messen.

Wir investieren einen hohen Anteil unserer Arbeit unter anderem in Tests, das ist nicht wenig, um die testpyramide weitestgehend abzudecken. Eine Firewall ist sicher nicht das einfachste System, um es komplett unter test zu stellen. Aber für ein dermaßen wichtiges System ist es unerlässlich. Vor allem, wenn man auch noch einen gewissen kommerziellen Erfolg haben möchte.