Probleme mit NGINX

[Seelenschnitter]

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?

[Patrick M. Hausen]

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?

[Seelenschnitter]

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.

[Patrick M. Hausen]

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.

[Seelenschnitter]

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. :)

[meyergru]

Da gibt es ein Tutorial für... für HAproxy auch, damit kann man ggf. noch mehr Spezialfälle abdecken.

[Seelenschnitter]

Da 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.

[Seelenschnitter]

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.

Code Select Expand

# 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


[Patrick M. Hausen]

- 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.

[Seelenschnitter]

- 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.

[Patrick M. Hausen]

Für Wildcard musst du das ACME-Client Plugin und die DNS-Challenge verwenden. Mit HTTP-Challenge stellt Letsencrypt keine Wildcards aus.

[Seelenschnitter]

Fü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?

[Monviech (Cedrik)]

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.

[meyergru]

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

[Seelenschnitter]

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.

Ah okay. Dann hatte ich das überlesen. Danke für den Hinweis.

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

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.