Messages

Sorry, hatte mich nicht genau ausgedrückt. Auf der OPNsense im RZ habe ich von HTTP auf DNS umgestellt. Das scheint auch geklappt zu haben, nun meinte ich das ich auf dem Docker Container (hinter NAT für Port 80 von der ext. Alias Adresse auf den internen Docker Container) verwenden zu können.

Ich kann auch die Seite von extern per HTTP und HTTPS (dann natürlich ohne gültiges LE-Zertifikat) zugreifen - jedoch kann der Container keine eigne ACME HTTP Challenge ausführen (Meldung oben).

Da der HTTP Zugriff möglich ist, gehe ich davon aus das immer noch das Challenge von der OPsense "schluckt".

Ich hoffe, ich könnte mich verständlich ausdrücken.

Danke für deine/eure Hilfe.

@meyergru: Noch mal eine andere Frage - ich habe noch eine zweite OPNsense in einem Rechenzentrum, dort habe ich kein HAProxy am laufen, jedoch den ACME Client, damit das Webgui Zertifikat auch gültig ist (LE).

Nun habe ich eine WAN Alias IP und NAT forwarder für HTTP/HTTPS auf die Adresse.

Jetzt habe ich den OPNsense ACME Client (für das Webui) jedoch auf DNS umgestellt - jedoch bekomme ich weiterhin die Meldung in dem weitergeleiteten ACME Client im Docker Container "Confirmed A record with IP 84.19.x.x, but HTTP validation failed".

Woran könnte das liegen? Kann es immer noch sein, das der ACME Client der OPNsense immer noch die http Anfragen für das verify "schluckt"? Wird der Verify auch für die Alias Adressen verwendet?

Danke für deine/eure Hilfe :).

Wenn Du den Setup wie im HAproxy-Tutorial verwendest, dürfte in den Rules für den Public HTTP eine mit dem Namen "redirect_acme_challenges" vorhanden sein. Aktuell prüft die nur den Pfad ("/.well-known..."), Du müsstest die Regel mit UND verknüpfen mit einem Test auf Deine Domains, die hinter der OpnSense liegen.

Wenn das alle betrifft, kannst Du die Regel auch im HTTP-Frontend wegnehmen, die wird automatisch angelegt, wenn Du für das ACME-Plugin die HAproxy-Integration aktivierst.

Allerdings funktioniert das so pro Domain nur entweder-oder per HTTP-01, weil für die Domain eben entweder das ACME-Plugin auf der OpnSense den Request bekommt oder aber Dein Backend.

Eine andere Variante wäre, die Zertifikate nicht mit HTTP-01, sondern per DNS-01 zu verifizieren, wenn Dein Backend und Dein DNS-Provider das können. Dann kann sogar jeder sein eigenes Zertifikat bekommen.

Eine kleine Warnung: Dovecot und Postfix können kein OCSP-Stapling. Eine gemeinsame Nutzung eines Domain-Zertifikats für HTTPS und für STARTTLS geht dann also nur mit OCSP-Stapling "off".

Vielen lieben Dank für die schnelle Hilfe - ich werde das mal ausprobieren.

Danke dir :).

Hallo,

ich habe eine Problem mit einer Seite. Ich habe mehrere Seiten über OPNsense mit HAProxy veröffentlicht.

Soweit, so gut - nun möchte ich gerne Mailcow installieren auf einem Docker Container. Da ich jedoch nur eine öffentliche IP Adresse habe, muss nun Lets Encrpyt aus dem Container ausgeführt werden, da die Zertifkate auch für andere Dinge wie SMTPS, IMAPS usw. genutzt werden.

Wenn ich jedoch den ACME Client in dem Container starte, kommt ein internal Error - ich vermute mal, das das Deploy nicht durch kommt und vom HAProxy abgefangen wird.

Meine Frage ist nun, kann ich im HAProxy einstellen, das eine bestimmte Site durchgelassen wird und so der ACME Client durchläuft?

Danke für eure Unterstützung.

Das ist ja der Hammer, danke dir vielmals - das war das Problem. Ich hatte noch die 4.4.1 drauf, nach Update auf 4.7.1 funktionierte es auf Anhieb. Darauf muss man erst mal kommen. Ich habe Stundenlang gesucht, aber darauf bin ich einfach nicht gekommen.

Danke dir vieeeeeeelmals!

Hallo liebe Mitstreiter,

ich hoffe ihr könnt mir bei meinem Problem weiterhelfen.

Ich habe einen Wazuh Server in einem VLAN angebunden an meiner OPNsense. Es gibt eine Floating Rule, die Verbindungen zuläßt für TCP/UDP 1514,1515,55000 (Agent und API) zu meinem Wazuh Server.

Wenn ich das Wazuh Agent Plugin auf der OPNsense installiere und einrichte, dann erscheint der Wazuh Agent im Wazuh, jedoch mit der Meldung never connected.

Auf der OPNsense sehe ich in der Datei /var/ossec/var/run/wazuh-agentd.state den Status pending. Somit ist zwar schon mal eine Verbindung da, jedoch scheint das Registrieren nicht richtig zu funktionieren.

Mit nc -zv 192.168.50.10 zu den Ports 1514, 1515, 55000 bekomme ich jeweils die Information "succeded", somit sollte die Verbindung da sein.

Wenn ich die ossec.conf vergleiche mit einem funktioniereneden System, dann sehe ich das diese sich ein wenig unterscheidet - auch nach dem Anpassen von:

Code Select Expand

  <client>
    <server>
      <address>192.168.50.10</address>
    </server>
    <crypto_method>aes</crypto_method>
  </client>


nach:

Code Select Expand

  <client>
    <server>
      <address>192.168.50.10</address>
      <port>1514</port>
      <protocol>tcp</protocol>
    </server>
    <config-profile>debian, debian8</config-profile>
    <crypto_method>aes</crypto_method>
  </client>


und Neustart des Dienstes brachte keinen Erfolg.

Leider kann ich auch in den ossec.log nicht nachschauen, da diese ein Symlink auf sich selber ist und beim Öffnen die Fehlermeldung erscheint, das zu viele redirects verwendet werden.

Wenn ich im Live-Log schaue, dann sehe ich auch keine Verbindungen ankommen.

Nun bin ich mit meinem Latein am Ende, kann mir jemand helfen, oder einen Tipp geben oder hat gar das Wazuh-Agent-Plugin auf der OPNsense laufen?

Danke für eure Hilfe.

If this is needed, edit /var/ossec/etc/ossec.conf and add the <agent_name> Entry - then restart the Wazuh Service on the OPNsense.

Alternativ sieht das hier vielversprechend aus, habe ich mir aber noch nicht im Detail angeschaut: https://okxo.de/how-to-add-2fa-in-opnsense-nginx-reverse-proxy/

Dann würde ich auch schauen, ob ich statt dem HAProxy komplett auf NGINX umstelle - Vorteil wäre dann auch, das ich dann noch eine WAF hätte.

Eine weitere Lösung wäre noch:

d) Denn Zugriff auf das Backend auf bestimmte Netze (interne- und VPN Netze) beschränken, dann wäre sichergestellt das man von extern nicht zugreifen kann.

Ein Smartphone oder Tablett können automatisch eine Verbindung aufbauen sofern kein OTP-Code an das Passwort hängen möchte (alternativ könnte man als 2. Faktor dann ein Zertifikat verwenden). VPN Clients für Rechner/Laptops müssten das auch können (man muss nur dran denken, das man dann keine Default Route verwendet).

Eine entsprechende Einstellung habe ich schon im Backend gefunden, aber weiß nicht genau wie das geht.

Die von dir genannte Lösung mit Authelia habe ich auch schon gesehen - da bei mir der HA Proxy verwendet wird, würde ich das so machen, das ich eine eine neue Site auf HA einrichte und dann diese auf den NGINX weiterleite, damit dieser angepasst werden kann. Frage wäre sogar ob man dann NGINX sogar in einem eigenen Container macht (Docker) - da mir das aussah, als wenn man doch sehr tief eingreift mit den Einstellungen, dann würde man in der OPNsense nichts verwurschteln.

In der Sophos war das immer sehr einfach, man konnte einfach eine AUTH Seite davorschalten und dort dann erst den Zugriff mit 2FA abwickeln und dann die Zugangsdaten durchreichen - z.B. zu einem Exchangeserver. Im Prinzip so, wie bei der Authelia.

Der Vorteil bei Authelia wäre dann, das man die Lösung mit weiteren Seiten nutzen könnte - ich habe z.B. Verwaltungsseiten, die ich auch nicht direkt über das Internet zugreifebar haben möchte.

Hallo,

ich habe schon mal im englischem Forum nachgefragt, aber keine Lösung bzw. keine weiteren Antworten mehr erhalten.

Deswegen würde ich es mal hier gerne nachfragen mit der Hoffnung, das ihr mir weiterhelfen könnt.

Ausgangslage ist, das ich einige Webanwendungen mit dem HAProxy veröffentliche - unter anderem einige die ich nicht direkt ohne "Schutz" über das Internet direkt erreichbar haben möchte.

Deshalb würde ich gerne diese Seiten schützen - dazu habe ich mehrere Ideen, jedoch weiß ich nicht, welche sich wie realisieren lassen.

a) Benutzerauthentifizierung mit OTP
b) WAF mit 2 FA versehen
c) VPN mit 2 FA und dann nur denn Zugriff aus dem VPN oder LAN

Was könnte wie funktionieren, oder habt ihr gar andere Ideen?

Danke vielmals für eure Unterstützung.

Danke Patrick für die Infos und auch dir Monviech vielen Dank - hat auf Anhieb geklappt.

Ihr beiden seid für mich heute "Hero of the Day" :).

Hallo zusammen,

habt ihr zufällig ein Beispiel oder gar eine Anleitung wie man zwischen zwei OPNsense ein WireGuard VPN einrichtet in der aktuellen Version? Die Doku und auch die YouTube Videos zeigen immer nur die Konfiguration der alten GUI (wo noch aufgeteilt ist zwischen den Tabs mit Local, Endpoints usw.) - die ist anders, als in der neuen GUI.

Weiterhin würde ich gerne wissen, ob WireGuard funktioniert, wenn eine Seite eine dynamische Adresse verwendet? Wenn ich es recht verstanden habe, muss die Adresse auch in das Feld Allowed IPs rein, das nimmt aber keine DNS Namen, sondern möchte IP Adressen, aber die ändern sich ja nach jeder Zwangstrennung.

Danke vielmals für eure Unterstützung.

Die OPNsense muss eine Source-Adresse verwenden, die auch im Tunnel ist. Also z.B. bei deinem Service angeben, dass die LAN-Adresse genommen werden soll.

Oder dem Tunnel selbst ein Transfer-Netzwerk geben und diese natürlich auf beiden Seiten zum Bestandteil des Tunnels machen.

Vielen lieben Dank für deine schnelle Antwort. Daraus ergeben sich ein paar Fragen:

a) Verwendet die OPNsense ausgehend die LAN Adresse für die eigenen Plugins (sofern man nichts auswählen kann - bei Unbound DNS kann ich ja einstellen, welche Netze genutzt werden soll - aber nicht beim Wazuh Agent Plugin)?
b) Ist das Transfernetz ist doch das "IPv4 Tunnel Network", oder?
c) Von der OPNsense im RZ kann ich die lokale Tunnel IP Pingen, nicht jedoch die Tunnel IP von der Remoteseite (OPNsense Home) - wenn ich jedoch einen Server aus dem RZ Netz nehme, kann ich die Remote Seite jedoch pingen). Muss ich hier noch was anpassen?

Hast du vielleicht sogar ein Beispiel oder ein Link dazu? Habe im Web und in der Doku nichts gefunden - vielleicht habe ich aber auch nur falsch gesucht :(.

Danke dir vielmals.

Hallo, ich kenne mich noch nicht so sehr mit der OPENsense aus - mit den anderen Firewalls, die ich zuvor genutzt hatte, hatte ich auf der Firewall, wenn ich einen Tunnel einrichte auch selber direkt auf den Tunnel zugreifen konnte, nicht jedoch so die OPNsense.

Hintergrund ist, ich habe zwei Netze (Home und RZ). Von den Servern aus kann ich auf die entsprechenden Ressourcen in beiden Netzen zugreifen. In dem Homenetz habe ich meinen WAZUH Server (SIEM). Die Server im RZ können ohne Probleme auf meinen Wazuh Server zuhause zugreifen. Die OPNsense im RZ jedoch nicht, ich wäre davon ausgegangen das die OPNsense auch auf Wazuh zugreifen kann.

Was aber nicht so ist, das VPN und Firewallregeln haben die interne IP der Firewall mit eingebunden. Alles kann problemlos auf Wazuh zugreifen, nur die OPNsense im RZ nicht.

Die Meldung, die ich bekomme ist: ERROR: (1208): Unable to connect to enrollment service at '[192.168.x.x]:1515' (x sind von mir!)

Auf der Shell kann ich weder den Wazuhserver noch die anderen Hosts im Homenetz pringen, ein Tracroute kommen schon sternchen schon nach dem ersten Knoten, die IP vom Tunnel kann ich jedoch pingen. Ein "nc ip 1515" bringt genauso wenig details, auch nicht zu anderen Ressourcen im Home Netz.

Für mich sieht es irgendwie so aus, als wenn die OPNsense selber zwar den Tunnel aufbaut - jedoch nicht selber darauf zugreifen kann.

Ist das Verhalten normal oder muss ich erst noch was einrichten?

Bei der Sophos UTM war das immer problemlos möglich (habe von der UTM zu OPNsense gewechselt).

Danke für eure Hilfe :).

Eine Bedingung mit Source IP matches XXX (bzw negieren) und dann eine Rules wenn diese matched einen http-request-deny. Diese dann dem Backendpool zuweisen.

Sollte eigentlich klappen.

Hallo Mimugmail, hast du ein paar weitere Infos diesbezüglich oder ein paar Links, die mir dabei weiterhelfen? Hatte mir das ein wenig einfacher vorgestellt. Danke dir.