Topics

Hallo,

auf meiner Heiminstallation von OPNsense habe wollte ich nun Caddy versuchen, weil es hier im Forum vielfach als einfach zu konfigurierender Reverse-Proxy bejubelt wird und meinen Anforderungen hier wohl genügt.
Bislang macht mein primärer Webserver (Apache) den Reverse-Proxy für die wenigen Anfragen, die auf andere Hosts gehen sollen. Und auf diesem läuft auch der ACME-Client. Funktioniert eigentlich alles zu gut, als dass ich mich allzu lange mit Alternativen beschäftige. Aber jetzt ist gerade Zeit und auf der OPNsense wäre das auch vielleicht schöner gelöst.

Mit dem Reverse-Proxy muss aber auch der ACME-Client auf die OPNsense übersiedeln. Doch der Client meldet einen Timeout beim Versuch, ein Zertifikat anzufordern.
Mir auch nicht klar, wie HTTP-01 Challenge zusammen mit Caddy überhaupt funktionieren soll. Dieser bekommt ja die HTTP Anfragen und müsste sie dahin weiterleiten, wo der ACME-Client die Challenge deponiert. Hinweise darauf, dass das auch passiert, konnte ich nicht finden.

Nun der ACME-Client bietet hierfür nur "OPNsense Web Service (automatic port forward)". Anders als das HAproxy Plugin stellt Caddy hier ja kein eigenes Service bereit.
Wie soll das nun funktionieren? Ist hier eine entsprechende Weiterleitung manuell in Caddy zu konfigurieren? Wenn ja, wie?

Im Web konnte ich dazu nichts finden. Ich bin nur mehrfach auf Loblieder gestoßen, dass Caddy alles automatisch machen würde. So dachte ich mir, vielleicht trifft das hier auch zu, ist ja wohl keine seltene Herausforderung, und habe mal versucht, ein Zertifikat anzufordern, aber da kommt nichts.
Der ACME-Client loggt

Code Select Expand

Invalid status. Verification error details: <WAN IP>: Fetching http://host.mydomain.tld/.well-known/acme-challenge/yvQjtqi_r-FZsC6gsmn1QWQx389QJ3OkCFsbJOk0MHU: Timeout during connect (likely firewall problem)Auch im 'debug 2' Level findet sich kein genauerer Anhaltspunkt.
Und Hinweise im Web deuten meist auf ein Firewall-Problem hin, das hier wohl nicht zutrifft. Die Firewall-Regeln habe ich überprüft, Geo-Blocker habe ich deaktiviert und auch den Zugriff von außen getestet.

Letztendlich habe ich während der Zertifikatsanforderung Pcap am WAN laufen lassen. Da sehe ich die Pakete von Let's Encrypt auf meine WAN-IP Port 80 mit der Länge 0, es kommt aber keine Antwort.
Rufe ich selbst den o.g. Pfad von außen auf, sehe ich die Antwortpakete.
Ja, das riecht nach Geo-Blocking. Die Regel hatte ich aber deaktiviert. Die Qell-IP (USA) sollte ohnehin nicht im Alias enthalten sein.
Was ist es dann??
Ich habe das Logging sämtlicher Regeln am WAN aktiviert, ebenso das der Default-Deny Regel und sehe den versuchten Zugriff nicht im Log.
So stellt sich die Frage, was kann die Pakete nach dem Pcap und vor den Filter-Regeln blockieren?

Was mir in diesem Zusammenhang auch ziemlich seltsam erscheint: Caddy beantwortet jede Anfrage auf http://host.mydomain.tld/<egal-was> mit 200.
Die Zusatzfrage wäre also: Kann vielleicht jemand den Sinn dieses erklären?

Vielleicht sollte ich auch noch erwähnen: Caddy funktioniert ansonsten offenbar. Services, die nicht TLS nutzen, habe ich bereits vor Tagen migriert und sind von intern und extern erreichbar. Diese laufen auf Port 80, was mir sagt, dass dieser auf Caddy ankommt. Den zuständigen Reverse-Proxy auf meinem Webserver habe ich deaktiviert.

Hat jemand eine Erklärung für dieses Phänomen?

Grüße

Hallo,

nachdem ich bereits 2 Business Editions betreibe, habe ich mich nun daran gewagt, auch meine Heim-Firewall von pfSense auf OPNsense zu migrieren.
Damit sehe ich mich erstmals mit einer dynamischen WAN IP (PPPoE) bei OPNsense konfrontiert. Den IP-Wechsel zum selbst gewählten Zeitpunkt habe ich hinbekommen, doch würde ich gerne passiv über eine neue IP informiert werden.

Gibt es eine Möglichkeit, dass mir OPNsense automatisch ein Mail mit der neuen WAN IP nach der IP-Erneuerung schickt?
Ist dafür etwa schon ein Prozess implementiert, den ich noch nicht entdeckt habe?

Ich habe dazu recherchiert und nur Hinweise auf eigene Scripte oder externes Monitoring gefunden.
Wie löst ihr das?

Wenn Script, wäre die weitere Frage, wie man das am besten in OPNsense einrichtet?

Wäre für Anregungen dankbar.

Grüße

I'm running a 25.4 installation in the cloud. The VM has a dedicated public WAN interface IPv4, but I want to use an "elastic IP" (x.y.z.125) for the outbound traffic.
So the outbound NAT is in hybrid mode and I've created rules for all internal network and the loopback subnet to translate the source address to x.y.z.125.

This works well for all outbound traffic, even IPSec on OPNsense itself, but the rule is completely ignored by OpenVPN client instances (legacy and new).

In the legacy client settings there is an option to state a certain interface IP though, which would work, but in new instances this option is sadly missing.

As I want to migrate a client to a new instances type, I'm wondering if there is any way to use a certain VIP as source address instead of the primary interface address.
The outbound NAT rule doesn't work. I also tried to add a rule for 127.0.0.0/8 with no avail. Even if I switch the outbound NAT into manual mode and there is no rule with the primary interface IP as NAT address, OpenVPN uses it.

Hallo,

ich habe in HAproxy einen Backendpool mit 3 Real Servers eingerichtet.
Einer davon ist als "active" konfiguriert, die anderen beiden als "backup".

Wenn nun der active Server nicht erreichbar ist, schaltet HAproxy auf das erste Backup um, wie gewünscht. Allerdings schaltet er nicht wieder von selbst zurück, wenn der active Server wieder verfügbar ist, obwohl der Status in Maintenance "UP" zeigt.

Also HAproxy erkennt zwar, dass der primäre Server wieder auf Health Checks antwortet, leitet aber dennoch alle Anfo
rderungen an den Backup Server. Deshalb denke ich nicht, dass die Health Check Einstellungen hier was verbessern könnten. Sind TCP Checks.

Ein "set state to ready" hilft auch nicht, das ist er ohnehin schon.
Bislang konnte ich HAproxy nur durch einen Service Restart oder durch auf "Maintenance" Setzen der beiden Backup Server wieder dazu bringen, richtig zu arbeiten. Das müsste er doch automatisch machen.

Könnte es da noch was zu konfigurieren geben?

Dieses Setup hatte ich bereits unter pfSense eingerichtet. Da funktioniert es einwandfrei.

Grüße

Hallo,

die HAproxy Konfiguration hat mir wieder mal eine Stunde extra gekostet, weil die GUI eine für mich logische Eingabe nicht akzeptiert. Aber vielleicht habe ich was falsch gemacht.
Kann mir jemand erklären, wie die Condition "Path contains subdir" korrekt anzuwenden ist?

Als Subdir Wert hätte ich einen Namen für ein Unterverzeichnis an beliebiger Stelle des Pfades gehalten. Meines heißt "Data_intern", und das hatte ich so ohne Anführungszeichen eingegeben. Doch die GUI liefert einen Fehler bei "Test syntax": No such ACL
Wenn ich mir die Config ansehe, fehlt die ACL auch tatsächlich. Stattdessen steht da

Code Select Expand

    # ERROR: missing parameters
    # ACL INVALID: Data_intern_path (ef0d8b72-55bc-435b-9f73-283e1b1bc3eb)
wovon ich auch nicht schlauer werde. Was soll da fehlen? Die Condition hat einen Namen, einen Type und einen Wert. Mehr sollte es nicht brauchen, denke ich.

Den Verzeichnisnamen zwischen Slashes zu setzen, befriedigt die OPNsense auch nicht.

Wenn ich die Condition auf "Path contains string" ändere und den Verzeichnisnamen als Wert zwischen Slashes setze, also "/Data_intern/", akzeptiert OPNsense die Eingabe, abgesehen von den nicht nachvollziehbaren Warnungen "http-request' rule placed after a 'use_backend' rule will still be processed before.", die ich schon mal hier angesprochen hatte.

Für mich bewirkt diese Condition dasselbe, aber was ist mit "Path contains subdir"? Was kann da an meiner Eingabe fehlen oder falsch sein?
Es wäre ja logisch, diesen Typ für meinen Zweck zu nehmen.

Grüße

Hallo,

mein HAproxy wirft beim Syntax Test eine Warnung aus:

[NOTICE] (20099) : haproxy version is 3.0.8-6036c31
[NOTICE] (20099) : path to executable is /usr/local/sbin/haproxy
[WARNING] (20099) : config : parsing [/usr/local/etc/haproxy.conf.staging:91] : a 'http-request' rule placed after a 'use_backend' rule will still be processed before.
Warnings were found.

Nun frag ich mich, wie ich dem Problem auf den Grund gehen kann, nachdem die OPNsense GUI es nicht beim Namen nennt.

Ich bin nun die Regeln durchgegangen, nachdem ich nicht mehr benötigte entfernt habe. In keinem Frontend habe ich eine http-request Regel, lediglich in einem Backend. So vermute ich, dass es diese Regel ist, die diese Warnung auslöst, und die die OPNsense GUI in Bezug zu den Frontend-Regeln stellt, von welchen natürlich einige use_backend Regeln sind.
Doch wie soll ich daran was ändern?
Ich sehe hier keine Möglichkeit, die OPNsense GUI zu zufrieden zu stellen. Hat vielleicht jemand eine Idee?

Die besagte Regel im Backend ist eine 'http-request deny'. Die soll eben für dieses bestimmte Backend angewendet werden und nicht allgemein.
Man könnte das mit einigem Mehraufwand gewiss auch alles im Frontend korrekt beregeln, aber für mich ist da der Syntax-Test das Problem, der einfach keine http-request Regeln im Backend akzeptiert. Ein Frontend wird wohl fast immer eine use_backend Regel enthalten, ist ja die Kernkompetenz eines Reverse Proxys.

Grüße

Hallo,

ich möchte die DNS-01 Challlenge verwenden, um ein LE Wildcard Zertifikat für meine Domain zu bekommen.
Das DNS ist bei Exoscale gehostet.

Der ACME Client bietet Exoscale als DNS Service an. Allerdings erhalte ich beim Versuch, das Zertifikat zu ziehen den Fehler

Code Select Expand

2024-12-16T12:23:55 acme.sh [Mon Dec 16 12:23:55 CET 2024] response='{"errorresponse":{"errorcode":403,"cserrorcode":9999,"errortext":"This API is deprecated. See https://changelog.exoscale.com/en#feature54957866 for more informations.","uuidList":[]}}'
Der zitierte Link führt nur mal zu allgemeinen Changelogs, aber über die Suche bin ich auf https://changelog.exoscale.com/en/deprecation-api-v1-as-of-may-1st-2024-uVYHUVZ3 gekommen, wo Exoscale verrät, dass nun nur mehr die API v2 unterstützt wird.
Der ACME Client verwendet aber noch die Version 1.

Kann ich da was machen? Lässt sich das irgendwo anpassen od. integrieren?

Grüße

[Conditions]

Hallo,

ich habe schon seit Jahren HAproxy auf pfSense in Verwendung.
Die Konfiguration auf pfSense scheint recht nah an der tatsächlichen HAproxy Konfiguration angelehnt zu sein. Die originalen HAproxy Anleitungen sind so leicht nachzuvollziehen.

Nun evaluiere ich OPNsense für unseren Zweck und habe auch hier HAproxy eingerichtet. Aber die GUI verfolgt ein völlig anderes Konzept, das nicht nur von jener auf pfSense, auch von der tatsächlichen HAproxy Konfiguration weit abweicht. Ich kann nicht nachzuvollziehen, warum hier die Konfiguration dermaßen zerklüfftet ist: Real Servers, Public Services, Backend Pools, Conditions, Rules, Haelth Monitor.
In pfSense wie auch in HAproxy selbst ist all das in zwei Bereichen zu konfigurieren, Frontends und Backends. Das erscheint mir weitaus übersichtlicher und hängt auch sinngemäß zusammen.
Vielleicht kann mir jemand aber den Sinn dahinter erklären.

Aber okay, da mag sich jemand was anderes überlegt haben, und ich versuche halt damit umzugehen. Doch nun zu meinen eigentlichen Fragen / Problemen:

An einem Punkt erscheint mir die Konfiguration doch regelrecht grotesk:
Conditions
Ich versuche, alles über eine öffentliche IP zu lösen und habe 5 Backend Server. Zu Sinn oder Unsinn dieser Lösung kann man sich hier auch gerne äußern, bislang hatte ich ein Frontend je Backup.

Auf einem dieser habe ich etwa 30 ziemlich verschiedene Hostnamen. So brauche ich eine Menge Host-Conditions, um diesen Server zu bedienen. 14 für einen einzigen virtuellen Server darauf. Der hat so viele Aliase.
So habe ich 14 Conditions mit demselben Namen angelegt, und dachte, so wie es die HAproxy Konfiguration vorsieht, brauche ich diesen nur einmal in der Regel zu erwähnen. Aber nicht auf OPNsense. In der Regel-Konfig scheinen auch alle 14 auf und möchten auch alle angehakt werden, damit sie darauf reagiert.
Im Konfig-File habe ich gesehen, dass jede Condition eine eigene ID erhält und diese verwendet wird. Ich frag mich, warum, wenn es das Original doch einfacher vorgibt.

Ist das wirklich so nötig oder habe ich was übersehen?
Das erscheint mir doch ziemlich abwegig von der eigentlichen HAproxy Konfiguration und ist zudem unnötig kompliziert und unhandlich.

Zusätzlich habe ich noch ein Frage zur 'Maintenance' Funktion:
In einem Backend Pool habe ich einen Server mit Status 'active' und einen weiteren mit Status 'backup'.
Mein Test: Ich aktiviere 'maintenance' auf dem aktiven. Die Anfragen werden auf den Backup weitergeleitet, wie erwartet. Nachdem ich den aktiven wieder auf 'ready' setze, bleibt das allerdings so. Auch ein 'drain' des Backups bringt HAproxy nicht wieder dazu, die Anfragen auf den aktiven Server zu leiten, auch nicht jene einer neuen Session / anderen Browser.
Erst, wenn ich den Backup auf 'maintenance' stelle UND die Webseite im Browser aufrufe, verwendet HAproxy wieder den aktiven Server.

Das kann doch auch nicht Sinn der Sache sein. Auch das funktioniert auf pfSense pipifein.
Hat da jemand bessere Erfahrung? Lassen sich die Server noch irgendwie anders umschalten?

Und dann noch die Frage, lassen sich Aliases aus OPNsense in den Conditions verwenden?
Ich vermute mal, nein, nachdem man eigene User und -Gruppen einrichten kann. Auch das geht in pfSense super toll und ist sehr praktisch.

Wenn das alles negativ bleibt, frage ich mich, ob HAproxy überhaupt die richtige Wahl für einen Reverse-Proxy auf OPNsense ist.
Habe mitbekommen, dass hier sehr viel von Caddy geschrieben wird. Aber kann der auch all das und ist der vernünftiger einzurichten und zu bedienen?
Meine Anforderungen sind sehr überschaubar: Eben wie o.g. ein Backup-Backend, das verwendet wird, wenn der primäre Host down ist, HTTP auf HTTPS Redirect und ein paar Regeln basieren auf Hostnamen, Pfade und später vielleicht noch Files und IPs.

Grüße