Messages

Ja, das wird so sein. Das ist allerdings auch nicht anders möglich, denn die Nextcloud, die angesprochen wird, hört auf Port 11000 und erhält das SSL-Zertifikat extern von nginx. Damit die verschlüsselte Verbindung also zustande kommen kann, muss sie durch nginx geleitet werden.

Hat niemand eine Idee?

Hallo zusammen,

im LAN der OPNsense habe ich einen Server (Photoprism), der versucht in einer Nextcloud-Instanz eine Anmeldung durchzuführen. Die Nextcloud-Instanz ist in einem anderen Netzwerk, das über Wireguard angebunden ist.
Beide Server sind über den nginx Reverse-Proxy der OPNsense von außen und aus dem lokalen Netz erreichbar.
Grundsätzlich funktionieren die Verbindungen zwischen beiden Netzwerken einwandfrei. Hier bin ich erstmals auf ein Problem gestoßen.

Wenn Photoprism versucht sich über webdav bei Nextcloud anzumelden, erhält Photoprism folgende Fehlermeldung:

2026-03-02 08:13:30 ERRO service-folder: 401 Unauthorized: <error xmlns="DAV:"><exception xmlns="http://sabredav.org/ns">Sabre\DAV\Exception\NotAuthenticated</exception><message xmlns="http://sabredav.org/ns">No public access to this resource., This request is not for a federated calendar, Username or password was incorrect, No &#39;Authorization: Bearer&#39; header found. Either the client didn&#39;t send one, or the server is mis-configured, Username or password was incorrect</message></error>

Nach vielem Probieren und Recherchieren habe ich evtl. das Problem identifiziert. Es könnte daran liegen, dass die Header nicht richtig weitergegeben werden. Konkret scheinen diese zu fehlen:

proxy_set_header Authorization $http_authorization;
proxy_pass_header Authorization;

Kann ich diese in der OPNsense in nginx irgendwie hinterlegen (z. B. Custom-Headers). Ich habe keine Möglichkeit dazu gefunden.

Viele Grüße

Marco

PS: Der direkte Aufruf über die IP-Adresse anstatt der Domain ist leider nicht möglich - das habe ich bereits versucht.

Hello everyone,

I seem to have a similar problem here.

My setup:
Virtualized OPNsense (Proxmox VE)
1 primary WAN connection
5 additional IP addresses created via additional virtual interfaces (created in Proxmox with assigned MAC addresses).

All IP addresses use the same upstream IP address as a gateway (Hetzner).


Previously: Corresponding firewall rules were created for each interface. In addition, corresponding port forwarding rules with automatic outbound NAT rules were created.
The traffic worked perfectly.

After the switch to 26.1, no traffic could be delivered. After all IP addresses were supplemented with /32, the traffic at least arrived at the respective host again. However, no responses were received from the services behind the additional IP addresses, while all packets running via the primary WAN connection continued to run unhindered.

It turned out that the packets were apparently being routed via vtnet0 instead of vtnet1, vtnet2, etc.
This means that the packets are apparently being discarded because they are coming back from a different interface than the one they came in on.

Despite numerous adjustments in all possible places, I have not been able to route the outgoing packets correctly via the interfaces through which they entered. Is this a bug?

I would be very grateful for any help!

Hallo zusammen,

ich habe mehrere OPNsense-Instanzen mit aktiviertem nginx-Reverse-Proxy (AddOn). Auf einer Instanz scheint der Dienst in unregelmäßigen Abständen immer wieder abzustürzen. Die Vorkommnisse liegen meist mehrere Tage bis Wochen auseinander. Eine Regelmäßigkeit konnte ich noch nicht feststellen.
Nach einem Neustart des Dienstes funktioniert wieder alles reibungslos.
Den Logs, die über die Weboberfläche einsehbar sind, war nichts zu entnehmen.
Habe ich eine Möglichkeit, herauszufinden, weshalb der Dienst immer wieder ein Problem hat?

Grüße

Das mit den Well-Known-Einträgen hat sich zwischenzeitlich erledigt. Ich hab eine Weiterleitung dafür eingerichtet und auf dem Zielhost einen Webserver erstellt, der die Einträge bereitstellt.

Dennoch ist es so, dass, sobald ich von einem externen Matrix-Server eine Verbindung aufbaue, der nginx ein Problem hat und alle Verbindungen zu allen Hosts nicht mehr funktionieren. Es steht solange alles, bis ich den Dienst neu starte.

Hat jemand eine Idee?
Ich habe bisher auch in keinem Log etwas gefunden, das auf einen Fehler hindeutet.

Hi, das ist soweit klar. Das Problem ist nur, dass ich nicht weiß, wie ich das bewerkstelligen soll. Im Prinzip müsste der nginx-Dienst von OPNsense differenzieren, welche well-known-Einträge gewollt sind. Der nginx-Dienst fängt die Abfrage ab und leitet sie um, weil das ACME-Modul die Abfrage auch braucht.
In OPNsense kann man die nicht hinterlegen, oder?

Hallo zusammen,
ich habe in Docker eine Matrix-Instanz laufen. Das ganze liegt hiner einem nginx reverse proxy (OPNsense-Dienst). Die funktioniert soweit auch ganz gut und tut was sie soll.
Der Federation-Tester (federationtester.matrix.org) gibt auch aus, dass alles gut sei.
Wenn ich jedoch versuche von außen eine Verbindung zu meiner Matrix-Instanz aufzubauen (von einem anderen Matrix-Server), hängt sich nginx komplett auf und gibt erst wieder Verbindungen weiter, wenn der Dienst neu gestartet wurde. Das Problem betrifft dann alle Hosts - nicht nur die Matrix-Instanz.

Im Fehlerlog "HTTP Fehler" erscheint folgendes:

Code Select Expand

*401 open() "/usr/local/etc/nginx/html/.well-known/matrix/client" failed (2: No such file or directory), client: ###.###.###.##, server: matrix.###.de, request: "GET /.well-known/matrix/client HTTP/2.0", host: "matrix.###.de"

Im Fehlerlog "HTTP Access" erscheint folgendes:

Code Select Expand

Status: 200
GET /_matrix/client/r0/sync?filter=1&timeout=30000&since=s8448_176689_0_12239_15402_1_10892_159_0_1 HTTP/2.0

und

Status 204
OPTIONS /_matrix/client/r0/sync?filter=1&timeout=30000&since=s8448_176689_0_12239_15402_1_10892_159_0_1 HTTP/2.0

Ich bin überfragt. Eine Lösung konnte ich trotz langer Recherche bisher nicht finden. Ich hoffe jemand kann mir hier weiter helfen, sodass ich meine Instanz von außen für einen anderen Server erreichbar machen kann.

Hat niemand eine Idee?

Ich vermute, dass es evtl. am Port 80 bzw. an der Portweiterleitung liegt.
Wenn ich im ACME-Plugin den Debug-Modus schalte und dann die im Log aufgelistete http-Adresse manuell aufrufe, erhalte ich die Datei als Download, da sie bei Abbruch vom ACME-Modul nicht gelöscht wird.
Insofern scheint es also mit der Portweiterleitung, die ja nur temporär für die Dauer der Aktualisierung gesetzt werden soll, nicht zu funktionieren. Ich frage mich nur, woran das liegen kann und was ich ggf. ändern muss.

Evtl. hilfreich:

Den Verwaltungsport habe ich auf einen anderen Port als 443 gesetzt, da die 443-Portweiterleitung für nginx gebraucht wird.
Die Anti-Aussperrregel ist im LAN auf Port 80 und dem neuen Verwaltungsport für https aktiv.
Diese Einstellungen waren allerdings auch schon so, als das Zertifikat das erste Mal gesetzt wurde.

Mir ist im Log außerdem aufgefallen, dass das Skript nur bis 5/30 zählt, bis es abbricht. Es werden also nicht 30 Sekunden (?) abgewartet.

Grüße

Ja, es geht um eine automatisch aktualisierte Netzwerkübersicht, wie sie Router üblicherweise haben.

Danke für die Rückmeldungen. Dann hat sich das Thema erledigt.

Hallo zusammen,
was mir immer mal wieder fehlt ist die Auflistung der Netzwerkgeräte, die sich im LAN bzw. VLAN befinden. Natürlich, die OPNsense ist kein Router, aber doch relativ modular aufgebaut und erweiterbar.
Gibt es eine Möglichkeit alle im Netzwerk befindlichen Geräte auflisten zu lassen (Name, MAC-Adresse, IP-Adresse, Subnetz usw.)?
Ich kenne nur den Bereich der Leases beim DHCP-Server, der aber naturgemäß nur einen Teil abdeckt.

Hallo zusammen,

ich habe einen Acme-Challenge-Fehler (Timeout der well-known-Adresse) bei der Aktualisierung eines Zertifikats.

Folgender Aufbau:

Subdomain sub.domain.tld verweist per CNAME-Record auf andere.zweitdomain.tld.

Der Server hinter andere.zweitdomain.tld liegt hinter einer OPNsense.
Auf der OPNsense ist nginx aktiviert und eingerichtet. Der Server ist erreichbar und funktioniert ordnungsgemäß.
Der Server selbst ist ein Docker-Container.

Bei der Aktualisierung des Zeritifikats wird nun ein Timeout beim Abruf der well-known-Adresse festgestellt.

Konfiguration ACME-Client: HTTP-01 auf Schnittstelle WAN.

Konfiguration NGINX-Eintrag:

• Position
  - URL-Pattern: /
  - Match Type: Don't check REGEX
  - HTTPS erzwingen: ja
  - HTTP/2-Preloading: ja
  
  
• HTTP-Server
  -  Enable Let's Encrypt Plugin Support: ja
  - HTTPS only: ja
  

Aktuell weiß ich nicht, warum die Ausgabe der Zertifikats beim ersten Mal funktioniert hat und warum die Erneuerung nun nicht funktioniert. Ich habe schon verschiedenes ausprobiert. Mir gehen langsam die Ideen aus. Hat jemand von euch eine Idee?[/list]