Hallo zusammen!
Habt Geduld mit mir, ich setze OPNSense erst seit 2 Wochen ein :-)
Wir haben folgendes Szenario (IP's der Einfachkeit halber nur Pseudos):
OPNSense WAN 1.1.1.1
OPSense LAN 192.168.0.1
NPM Reverse Proxy intern 192.168.0.20
Nextcloud intern 192.168.0.30
Mit Caddy auf der OPNSense funktioniert alles einwandfrei, Upstream 192.168.0.30:80
Auch bei einem Upstream auf den NPM (192.168.0.20:80) funktioniert die GUI einwandfrei
ABER:
Richte ich eine NAT-Regel (siehe auch Screenshot) ein, die die Ports 80 und 443 auf den NPM (192.168.0.20) weiterleiten funktionieren andere ,,normale" Webseiten (testweise eine angelegt), aber die GUI von Nextcloud ist extrem träge, es dauert bis zu einer Minute bis diese geladen ist.
In der NextCloud config ist als ,,trusted Proxy" der NPM hinterlegt (192.168.0.20), was beim Betrieb über Caddy aber ohne Konsequenz ist.
Die Firewall Logs zeigen an, dass die Anfragen an den NextCloud Server weitergereicht werden (alles 443), einzig die GUI ist extrem träge.
Hängt der NPM an einer Public IP funktioniert auch alles einwandfrei, ich denke also, es muss an einer Regel liegen, die Nextcloud dazu bringt, so langsam zu antworten.
Hat jemand Erfahrungen in diesem Zusammenhang oder kann mir einen Tipp geben, wie dieses Verhalten zustande bzw. gelöst werden kann?
Und Fragen zu vermeiden, Caddy hat leider ein paar fehlende Funktionen, weshalb wir auf den NMP umsteigen wollen.
Hallo,
Quote from: Polfi on February 20, 2025, 09:00:12 AMNPM Reverse Proxy intern 192.168.0.20
NPM sagt mir nichts. Arbeitet der etwa im Transparent Modus?
Dann könnte es zu asymmetrischen Routing kommen. Und die IP als "trusted Proxy" anzugeben, könntest du dir sparen.
Quote from: Polfi on February 20, 2025, 09:00:12 AMUnd Fragen zu vermeiden, Caddy hat leider ein paar fehlende Funktionen, weshalb wir auf den NMP umsteigen wollen.
HAproxy ist auch auf OPNsense verfügbar. Ich bezweifle, dass dem die gewünschten Funktionen auch fehlen.
NPM = Ngnix Proxy Manager
Ich habe es auch schon mit Zoraxy probiert, leider selbes Ergebnis.
Das "seltsame" ist ja, dass es nur NextCloud betrifft, alle anderen Seiten werden ohne Verzögerung geladen.
Mit dem HA Proxy habe ich mich schon beschäftigt, allerdings ist mir da die Konfiguration zu fummelig :-)
Mit der Konfigurationsoberfläche von HAproxy auf OPNsense bin ich auch nicht glücklich. Speziell wenn man HAproxy bereits kennt, entbehrt dies jeder vernünftigen Logik (IMHO). Aber man bekommt es hin, wenn man sich dahinter klemmt.
Und hier läuft auch eine Nextcloud dahinter.
Wenn dein NPM nicht im Transparent Mode läuft, fällt mir kein Grund für das Problem ein. Die OPNsense macht da ja nichts weiter, als die Pakete weiterzuleiten.
Der Webserver sieht dann die IP das Proxy als Quelle?
Fügt der Proxy einen X-Forwarded-For Header ein? Ich glaube gelesen zu haben, dass NC das haben möchte, wenn ein "trusted Proxy" konfiguriert ist.
Wenn du als Admin in die Verwaltungseinstellungen der NC gehst, wird dir da irgendein Hinweis angezeigt?
Das Brute-Force Modul arbeitet auch hinter Proxy, jedenfalls mit dem zuvor genannten Header, und würde Beschränkungen da melden.
Oder findet sich ein Hinweis unter Protokollierung?
Ich bin interessiert was dir in Caddy fehlt, wenn es etwas simples ist dann kann man es gegebenenfalls dazuprogrammieren.
Ich werde mir die Sache übers Wochenende mal genauser ansehen, , wäre doch gelacht, wenn wir das nicht hinbekommen.
Und was MIR (und vielleicht wirklich nur mir) an Caddy fehlt sind z. B. Aliase und Weiterleitungen.
Aber das ist Jammern auf hohen Niveau.
Weiterleitungen gibt es. Sind extra für Nextcloud eingebaut. Im Handler den advanced mode aktivieren um alles zu sehen.
https://github.com/opnsense/plugins/pull/4263
Aliase gehen leider nicht, die sind im Firewall Namespace für PF. Ich weiß sonst nicht welche Aliase gemeint sind.
Quote from: Monviech (Cedrik) on February 20, 2025, 07:09:13 PMAliase gehen leider nicht, die sind im Firewall Namespace für PF.
Leider auch nicht in HAproxy. :-(