Messages

Hat sich erledigt. War ein Layer 8 Problem. :)

Moin zusammen,

ich habe eine kleine Frage. Ich habe meinen LACP auf der OPNSense folgendermaßen konfiguriert:

Code Select Expand

Device:       lagg0
Parent:       igb0,ix0
Proto:        lacp
Fast Timeout: Yes
Hash Layer:   L2

Seitens CX:

Code Select Expand

interface lag 1
    description LACP Trunk Firewall
    no shutdown
    vlan trunk native 1
    vlan trunk allowed 1,10,20
    lacp mode active
    loop-protect action tx-rx-disable

interface 1/1/1
    description Router LACP
    no shutdown
    lag 1
    no power-over-ethernet
interface 1/1/2
    description Router LACP
    no shutdown
    lag 1
    no power-over-ethernet

Leider kommt der LACP aber nicht richtig zustande:

Code Select Expand

State abbreviations :
A - Active        P - Passive      F - Aggregable I - Individual
S - Short-timeout L - Long-timeout N - InSync     O - OutofSync
C - Collecting    D - Distributing
X - State m/c expired              E - Default neighbor state

Actor details of all interfaces:
----------------------------------------------------------------------------------
Intf       Aggr       Port  Port  State   System-ID         System Aggr Forwarding
           Name       Id    Pri                             Pri    Key  State
----------------------------------------------------------------------------------
1/1/1      lag1       2     1     ALFNCD  38:10:XX:XX:XX:XX 65534  1    up
1/1/2      lag1       3     1     ALFOE   38:10:XX:XX:XX:XX 65534  1    lacp-block

Muss man bei der OPNSense noch irgendwas spezielles  beachten?

[Edit:]

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.

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

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

Frage: Sollte Caddy nicht bei entsprechenden Firewall Regeln

Code Select Expand

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?

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

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

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.

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?

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.

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.

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?

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

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


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.

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

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.