Hallo zusammen,
ich habe heute auf meiner Synology im Docker einen Vaultwarden aufgesetzt. Nun wollte ich aber nicht den Reserve Proxy und die SSL Abhandlung von der Synology nutzen, sondern das meiner Firewall und nginx überlassen. Also habe ich heute selbiges frisch installiert auf der Opnsense und wollte es einrichten.
Aber nach einem gesamten Tag konfigurieren und wirklich so gar keinem Erfolg (ausser beim Synology mit SSL Zertifikat von meiner Domain und Reverse Proxy inklusive NAT und Outbound NAT auf Opnsense vollkommen funktional) fiel mir auf, dass im Dashboard ständig im Live Log "WARNING: failed to setup nginx" auftaucht. Eine Reinstallation half nichts und zu dem Fehler finde ich auch nicht vernünftiges.
Hat dazu jemand eine Idee?
Ich hab leider keine Erfahrung mit NginX innerhalb von OPNsense. Ich kann nur sagen, dass für eingehende Web-Anwendungen der schmerzfreiste Reverse-Proxy definitiv Caddy ist. Weshalb genau möchtest du lieber NginX verwenden?
Ehrlich gesagt viel gutes darüber gehört/gelesen und bin neuen Dingen nicht abgeneigt in der Welt der IT aber der nginx in OPNsense fühlt sich nach einem Tag wirklich.....mies an. Weshalb dein Einwurf nicht wirklich verkehrt klingt.
Vielleicht arbeiten die auch alle mit dem Nginx Proxy Manager.
Wenn Caddy dasselbe in besser macht, soll mich davon nichts abhalten.
Das Plugin ist relativ neu, Cedrik aka @Monviech, der seit einiger Zeit für Deciso arbeitet, hat wirklich sein Herzblut da rein gesteckt. Ziel ist, dass Web-Anwendungen mit SSL per Letsencrypt mit minimalem Aufwand "einfach funktionieren". Für Reverse Proxy hat Caddy wirklich die Nase vorn, auch außerhalb von OPNsense.
Wenn man komplexere Setups braucht, dann gibt es nach wie vor NginX und HAproxy als Option.
Viel Erfolg.
Ah ok das mit dem "relativ neu" erklärt es dann wohl. Ich hab schon mit Caddy angefangen und versuche es nun mal damit.
Ich danke dir und auch für deine Zeit. :)
Da gibt es ein Tutorial für... für HAproxy auch, damit kann man ggf. noch mehr Spezialfälle abdecken.
Quote from: meyergru on September 03, 2025, 11:37:20 PMDa gibt es ein Tutorial für... für HAproxy auch, damit kann man ggf. noch mehr Spezialfälle abdecken.
Meinst du für Caddy? Das habe ich schon fertig gelesen aber Danker für den Hinweis.
Da muss ich für heute auch erstmal kapitulieren. Alles durchgelesen, alles wie gewünscht eingerichtet (WAN/LAN FW Rules für Ports 80/443, Domains, Handler). Ich komme nicht einmal auf die https Seite von meiner DSM als Test von außen.
# DO NOT EDIT THIS FILE -- OPNsense auto-generated file
# caddy_user=root
# Global Options
{
log {
output net unixgram//var/run/caddy/log.sock {
}
format json {
time_format rfc3339
}
}
servers {
protocols h1 h2
}
auto_https off
grace_period 10s
import /usr/local/etc/caddy/caddy.d/*.global
}
# Reverse Proxy Configuration
*.meinedomain.de {
tls /var/db/caddy/data/caddy/certificates/temp/0815khkjh2k22.pem /var/db/caddy/data/caddy/certificates/temp/891651951.key {
}
}
vaultwarden {
handle {
reverse_proxy https://192.168.178.100:6655 {
transport http {
tls_insecure_skip_verify
tls_trust_pool file /var/db/caddy/data/caddy/certificates/temp/68b882285bce8.pem
}
}
}
}
import /usr/local/etc/caddy/caddy.d/*.conf
- UI auf einen anderen Port gelegt?
- Redirect HTTP --> HTTPS für das UI deaktiviert?
- TCP/80+443, any --> WAN address auf WAN erlaubt?
Wenn ja, dann funktioniert der Caddy normalerweise auf Anhieb.
Quote from: Patrick M. Hausen on September 04, 2025, 01:58:27 AM- UI auf einen anderen Port gelegt?
- Redirect HTTP --> HTTPS für das UI deaktiviert?
- TCP/80+443, any --> WAN address auf WAN erlaubt?
Wenn ja, dann funktioniert der Caddy normalerweise auf Anhieb.
Zu allen 3: Ja alles drin
Habs aber nun hinbekommen. Caddy scheint meine Idee mit den
Domains nicht zu mögen.
Hatte als Domain https://*.meinedomain.de
als Subdomain "vaultwarden"
Wenn ich unter
Domains allerdings direkt https://vaultwarden.meinedomain.de nutze, dann klappt es.
Dachte eigentlich ich dachte richtig mit den Subdomains aber er hat wohl was gegen die Wildcard Domain.
Für Wildcard musst du das ACME-Client Plugin und die DNS-Challenge verwenden. Mit HTTP-Challenge stellt Letsencrypt keine Wildcards aus.
Quote from: Patrick M. Hausen on September 04, 2025, 02:13:41 AMFür Wildcard musst du das ACME-Client Plugin und die DNS-Challenge verwenden. Mit HTTP-Challenge stellt Letsencrypt keine Wildcards aus.
Möchte ich ja gar nicht. Ich habe das ja vollständig deaktiviert. Ich hab ein eigenes Zertifikat. Damit sollte es doch dann gehen, wenn ich es hinterlegt habe?
Oder habe ich nun was missverstanden?
Das Problem im oberen Caddyfile ist, dass die domain und subomain so heißen müssen:
*.meinedomain.de
vaultwarden.meinedomain.de
und nicht
*.meinedomain.de
vaultwarden
Steht im Helptext. Danach sollte es mit dem wildcard richtig klappen.
Wenn man in der Lage ist, Wildcards zu verwenden, sollte man auf gar keinen Fall mehr FQDNs verwenden, insbesondere nicht so etwas wie "vaultwarden.meinedomain.de" oder "opnsense.meinedomain.de". Das ist nämlich unnötig, da bereits durch "*.meinedomain.de" abgedeckt.
Wenn man die bereits einmal hat ausstellen lassen, sind diese Namen aufgrund certificate transparency bereits "in the open" und sollten ggf. gewechselt werden, siehe: https://crt.sh/
Zur Erklärung: https://forum.opnsense.org/index.php?msg=189393
Quote from: Monviech (Cedrik) on September 04, 2025, 05:54:30 AMDas Problem im oberen Caddyfile ist, dass die domain und subomain so heißen müssen:
*.meinedomain.de
vaultwarden.meinedomain.de
und nicht
*.meinedomain.de
vaultwarden
Steht im Helptext. Danach sollte es mit dem wildcard richtig klappen.
Ah okay. Dann hatte ich das überlesen. Danke für den Hinweis.
Quote from: meyergru on September 04, 2025, 10:10:46 AMWenn man in der Lage ist, Wildcards zu verwenden, sollte man auf gar keinen Fall mehr FQDNs verwenden, insbesondere nicht so etwas wie "vaultwarden.meinedomain.de" oder "opnsense.meinedomain.de". Das ist nämlich unnötig, da bereits durch "*.meinedomain.de" abgedeckt.
Wenn man die bereits einmal hat ausstellen lassen, sind diese Namen aufgrund certificate transparency bereits "in the open" und sollten ggf. gewechselt werden, siehe: https://crt.sh/
Zur Erklärung: https://forum.opnsense.org/index.php?msg=189393
Dann bleibe ich beim Wildcard. Habe ja eins bekommen mit
*.meinedomain.de . Unter crt.sh ist auch nur bisher das einsehbar. Danke dir für den Hinweis. Ich war gestern so vertieft, dass ich das mit dem certificate transparency vergessen hatte. Das macht das Ganze dann wenigsten transparenter und mit dem Domain Guard, der sowas wie
zone transfers sperrt, sollte das doch gut klappen. Ich muss nur gucken, wie ich das dann einrichten muss.
Nach etwas Schlaf ist mein Kopf auch wieder nach den 18 Stunden frei. Ich verbeisse mich bei sowas zu schnell.
Quote from: Seelenschnitter on September 03, 2025, 10:53:09 PMHallo zusammen,
ich habe heute auf meiner Synology im Docker einen Vaultwarden aufgesetzt. Nun wollte ich aber nicht den Reserve Proxy und die SSL Abhandlung von der Synology nutzen, sondern das meiner Firewall und nginx überlassen. Also habe ich heute selbiges frisch installiert auf der Opnsense und wollte es einrichten.
Aber nach einem gesamten Tag konfigurieren und wirklich so gar keinem Erfolg (ausser beim Synology mit SSL Zertifikat von meiner Domain und Reverse Proxy inklusive NAT und Outbound NAT auf Opnsense vollkommen funktional) fiel mir auf, dass im Dashboard ständig im Live Log "WARNING: failed to setup nginx" auftaucht. Eine Reinstallation half nichts und zu dem Fehler finde ich auch nicht vernünftiges.
Hat dazu jemand eine Idee?
Normalerweise würde der nicht starten, weil die Konfiguration ein Problem hat.
Quote from: bimbar on September 04, 2025, 02:23:57 PMQuote from: Seelenschnitter on September 03, 2025, 10:53:09 PMHallo zusammen,
ich habe heute auf meiner Synology im Docker einen Vaultwarden aufgesetzt. Nun wollte ich aber nicht den Reserve Proxy und die SSL Abhandlung von der Synology nutzen, sondern das meiner Firewall und nginx überlassen. Also habe ich heute selbiges frisch installiert auf der Opnsense und wollte es einrichten.
Aber nach einem gesamten Tag konfigurieren und wirklich so gar keinem Erfolg (ausser beim Synology mit SSL Zertifikat von meiner Domain und Reverse Proxy inklusive NAT und Outbound NAT auf Opnsense vollkommen funktional) fiel mir auf, dass im Dashboard ständig im Live Log "WARNING: failed to setup nginx" auftaucht. Eine Reinstallation half nichts und zu dem Fehler finde ich auch nicht vernünftiges.
Hat dazu jemand eine Idee?
Normalerweise würde der nicht starten, weil die Konfiguration ein Problem hat.
Gestartet war er aber es interessierten ihn scheinbar keinerlei Einstellungen. Mit Caddy klappte es rucki zucki.
Quote from: meyergru on September 04, 2025, 10:10:46 AMWenn man in der Lage ist, Wildcards zu verwenden, sollte man auf gar keinen Fall mehr FQDNs verwenden, insbesondere nicht so etwas wie "vaultwarden.meinedomain.de" oder "opnsense.meinedomain.de". Das ist nämlich unnötig, da bereits durch "*.meinedomain.de" abgedeckt.
Wenn man die bereits einmal hat ausstellen lassen, sind diese Namen aufgrund certificate transparency bereits "in the open" und sollten ggf. gewechselt werden, siehe: https://crt.sh/
Zur Erklärung: https://forum.opnsense.org/index.php?msg=189393
Ich hab mir jetzt irgendwie das Hirn verknotet. Wie soll das denn ohne Subdomains funktionieren, also woher soll mein Netzwerk wissen, welche Anfrage wohin geht?
Bsp:
2 Dienste Web
Eins ist eine Webseite, das Andere Vaultwarden.
Ich muss doch irgendwie sagen, wann ich was abrufen möchte. Wenn ich jetzt immer nur meinedomain.de anspreche, dann geht 443 doch immer nur an einen Dienst, ohne einen weiteren
Zeiger oder hab ich was in der aussage falsch verstanden? Also wenn ich nicht noch Ports eingeben möchte.
Es ist nur gemeint, du sollst keine Zertifikate auf meindienst.meinedomain.de ausstellen, nicht, dass du keine solche URL/domain verwenden sollst.
Quote from: Patrick M. Hausen on September 04, 2025, 03:26:28 PMEs ist nur gemeint, du sollst keine Zertifikate auf meindienst.meinedomain.de ausstellen, nicht, dass du keine solche URL/domain verwenden sollst.
Achso ok. Dann hatte ich da wirklich was missverstanden in der Aussage. Verzeihung.
Frage: Sollte Caddy nicht bei entsprechenden Firewall Regeln
Firewall -> Rules -> LAN
Protocol: IPV4 TCP
Source: Any
Port: Any
Destination: This Firewall
Port: 443 (und eine extra Regel für Port 80)
Gateway: default
nicht auch den internen Traffic auflösen können, wenn ich eine Webseite anspreche, die ich als reverse Proxy eingetragen habe?
Doch sollte es und zwar ohne weitere tricks.
Keine DNS overrides nötig, intern muss nur die gleiche externe IP der Firewall für die selben Namen aufgelöst werden können.
Wenn es nicht geht das hier abarbeiten:
https://docs.opnsense.org/manual/how-tos/caddy.html#caddy-troubleshooting
Quote from: Monviech (Cedrik) on September 04, 2025, 07:53:43 PMDoch sollte es und zwar ohne weitere tricks.
Keine DNS overrides nötig, intern muss nur die gleiche externe IP der Firewall für die selben Namen aufgelöst werden können.
Wenn es nicht geht das hier abarbeiten:
https://docs.opnsense.org/manual/how-tos/caddy.html#caddy-troubleshooting
Ich hoffte auf etwas, dass ich vergessen habe. Das habe ich leider bereits abgearbeitet. Ich machs aber nochmal. Vielleicht habe ich da ja doch was übersehen.
EDIT: Ja....ab und zu tut ein PowerCycle auch einfach mal gut (Klassiker). Es klappt nun ^^
Nächste Frage: Ist es möglich mit meinem Zertifikat vom Hoster (Cert, Intermediate) die Kette auf der Opnsense abzubilden? Irgendwie sehe ich nicht, wie ich die Kette erstellen kann und man findet immer nur Let's Encrypt.
Danke schonmal
Edit: Das scheint nicht zu gehen, da man die Kette nicht abbilden kann ohne das gegenzuzeichnen an der CA, dessen private Key man nicht hat.