RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io

[Anderer]

Guten Abend zusammen,

für Nextcloud AIO wollte ich HAProxy als Reverse Proxy mit Wildcard-Zertifikat von Let's Encrypt und "SUBDOMAIN.dedyn.io" von deSEC installieren. Vorgehen analog Tutorial mit Adaption an aktuelle Felder und Einstellungen:
https://forum.opnsense.org/index.php?topic=23339.0

A) Plugin-Installation

• OPNsense aktuell mit OpenSSL
• os-acme-client, os-ddclient, os-haproxy sind installiert

B) DynDNS configuration

• Account in desec.io angelegt
• SUBDOMAIN.dedyn.io angelegt
• Token angelegt
• TOKEN
• CAA record mit 0, issuewild, "letsencrypt.org", 3600
• Beim Anlegen des CNAME gibt es folgenden Fehler:
  RRset with conflicting type present: database (CAA, NS). (No other RRsets are allowed alongside CNAME.)
  In der Doku steht dazu:
  A CNAME record is not allowed when other records exist at the same subname. This is a limitation of the DNS specification.
  https://desec.readthedocs.io/en/latest/dns/rrsets.html#unsupported-types
• Dienste > Dynamisches DNS > Einstellungen > Allgemeine Einstellungen > Aktiviert, Intervall: 300, Backend: nativ
• Dienste > Dynamisches DNS > Einstellungen > Konten >
   - Dienst: desec-v4 bzw. Custom
  - Protokoll: entfällt bzw. DynDNS 2
   - Server: entfällt bzw. update.dedyn.io
   - Benutername: SUBDOMAIN.dedyn.io
   - Passwort: TOKEN
   - Wildcard: Nein
   - Hostname: SUBDOMAIN.dedyn.io
   - IP-Prüfmethode: Schnittstelle [IPv4]
   - Zu überwachende Schnittstelle: WAN
   - IP-Prüfzeitüberschretung: 10
   - SSL erzwingen: Ja
• Schnittstellen > Diagnose > Ping > Hostname oder IP: SUBDOMAIN.dedyn.io, Adressfamilie: IPv4, Quelladresse: LEER, Paketgröße: LEER, Nicht fragmentieren: Nein

        => Verlust: 100%, Fehler: sendto: Host is down

Ich habe dann zunächst lange gesucht und dann versucht, HAProxy zu konfigurieren, aber es blieb - vermutlich - bei diesem Fehler.

• Könnte ich bitte einen Hinweis bekommen, was ist statt CAA + CNAME bei deSEC konfigurieren muss oder nachlesen kann, wenn CNAME nur alleine eingegeben werden darf - oder 
• könnte ich evtl. jemanden beauftragen, meine Einstellungen zu prüfen und korrigieren, damit ich Nextcloud installieren kann?

Nachfolgend noch meine Konfiguration (anonymisiert), Protokoll und Topologie.

Dankeschön & herzliche Grüße,

Rico

Dienste: HAProxy: Konfigurationsexport

Code Select Expand

[pre]#
# Automatically generated configuration.
# Do not edit this file manually.
#
global
    uid                         80
    gid                         80
    chroot                      /var/haproxy
    daemon
    stats                       socket /var/run/haproxy.socket group proxy mode 775 level admin
    nbthread                    6
    hard-stop-after             60s
    no strict-limits
    maxconn                     10000
    ocsp-update.mindelay 300
    ocsp-update.maxdelay 3600
    httpclient.resolvers.prefer   ipv4
    tune.ssl.default-dh-param   4096
    spread-checks               2
    tune.bufsize                16384
    tune.lua.maxmem             0
    log                         /var/run/log local0 info
    lua-prepend-path            /tmp/haproxy/lua/?.lua
defaults
    log     global
    option redispatch -1
    maxconn 5000
    timeout client 30s
    timeout connect 30s
    timeout server 30s
    retries 3
    default-server init-addr last,libc
    default-server maxconn 50000
# autogenerated entries for ACLs
# autogenerated entries for config in backends/frontends
# autogenerated entries for stats
# Frontend: 0_SNI_frontend (Listening on 0.0.0.0:80, 0.0.0.0:443)
frontend 0_SNI_frontend
    bind 0.0.0.0:443 name 0.0.0.0:443
    bind 0.0.0.0:80 name 0.0.0.0:80
    mode tcp
    default_backend SSL_backend
    # logging options
# Frontend: 1_HTTP_frontend (Listening on 127.4.4.3:80)
frontend 1_HTTP_frontend
    bind 127.4.4.3:80 name 127.4.4.3:80 accept-proxy
    mode http
    option http-keep-alive
    default_backend Fallback_Backend
    # logging options
    # ACL: NoSSL_condition
    acl acl_74z5hhgd42d038.47994567 ssl_fc
    # ACTION: HTTPtoHTTPS_rule
    http-request redirect scheme https code 301 if !acl_74z5hhgd42d038.47994567
# Frontend: 1_HTTPS_frontend (Listening on 127.4.4.3:443)
frontend 1_HTTPS_frontend
    http-response set-header Strict-Transport-Security "max-age=6307200; includeSubDomains; preload"
    bind 192.168.50.1:443 name 192.168.50.1:443 accept-proxy ssl curves secp384r1  ssl-min-ver TLSv1.3 ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256 alpn h2,http/1.1 crt-list /tmp/haproxy/ssl/74z5hhgd42d038.47994567.certlist
    mode http
    option http-keep-alive
    default_backend Fallback_Backend
    # logging options
    # ACL: PUBLIC_SUBDOMAINS_condition
    acl acl_74z5hhgd42d038.47994567 hdr_reg(host) -i .*\.SUBDOMAIN\.dedyn\.io
    # ACTION: PUBLIC_SUBDOMAINS_rule
    use_backend %[req.hdr(host),lower,map_dom(/tmp/haproxy/mapfiles/4z5hhgd42d038.47994567.txt)] if acl_74z5hhgd42d038.47994567.53560960
# Backend: SSL_backend (Backend für SSL Offloading)
backend SSL_backend
    # health checking is DISABLED
    mode tcp
    balance source
    # stickiness
    stick-table type ip size 50k expire 30m 
    stick on src
    server SSL_server 127.4.4.3:443 send-proxy-v2 check-send-proxy
# Backend: Nextcloud_Backend (Backend für Nextcloud Service)
backend Nextcloud_Backend
    # health checking is DISABLED
    mode http
    balance source
    # stickiness
    stick-table type ip size 50k expire 30m 
    stick on src
    http-reuse safe
    server Nextcloud_Server 192.168.50.48:8080
# Backend: Fallback_Backend (Fallback Backend, falls Subdomain nicht vorhanden ist)
backend Fallback_Backend
    # health checking is DISABLED
    mode http
    balance source
    # stickiness
    stick-table type ip size 50k expire 30m 
    stick on src
    http-reuse safe
    server Fallback_Server 127.4.4.3:80
# Backend: UgreenNAS_Backend (Backend für UGREEN DXP480T Plus)
backend UgreenNAS_Backend
    # health checking is DISABLED
    mode http
    balance source
    # stickiness
    stick-table type ip size 50k expire 30m 
    stick on src
    http-reuse safe
    server UgreenNAS_Server 192.168.50.48:9443 ssl alpn h2,http/1.1 verify none
# Backend: OPNsense_Backend (Backend für OPNsense Mini-PC)
backend OPNsense_Backend
    # health checking is DISABLED
    mode http
    balance source
    # stickiness
    stick-table type ip size 50k expire 30m 
    stick on src
    http-reuse safe
    server OPNsense_Server 192.168.50.1:55443 ssl alpn h2,http/1.1 verify none
# Backend: AsusRouter_Backend (Backend für ASUS GT-BE98)
backend AsusRouter_Backend
    # health checking is DISABLED
    mode http
    balance source
    # stickiness
    stick-table type ip size 50k expire 30m 
    stick on src
    http-reuse safe
    server AsusRouter_Server 192.168.50.2:8398 ssl alpn h2,http/1.1 verify none
# statistics are DISABLED[/pre]





Dienste: HAProxy: Protokolldatei
=> hat immer wieder den gleichen Eintrag mit unterschiedlichen "from" Ports - sonst alles gleich.

Code Select Expand

2025-10-01T22:04:52
Informational
haproxy
Connect from 127.4.4.3:35006 to 127.4.4.3:443 (0_SNI_frontend/TCP)


Topologie:

Code Select Expand

WAN / Internet                        Telekom
     |
     |      VDSL
     |
   .-+-------------.
   |   FritzBox    |                   172.168.178.1      Modem
   '-+-------------'
     |
     |     WiFi-5
     |
   .-+-------------.
   | FritzRepeater |                   172.168.178.17     Access-Point
   '-+-------------'
     |
     |     1G LAN
     |
   .-+-------------.                .- 172.168.178.5      Exposed Host
   |   OPNsense    |                |
   '-+-------------'                '- 172.168.50.1/24    FW, DHCP-Server, später: VPN, Reverse Proxy
     |
     |   2.5G LAN
     |
   .-+-----+-------.
   | ASUS GT-BE98  |                   172.168.50.2       Access-Point, keine FW, kein DHCP-Server, kein VPN
   '-++++----------'
     ||||
     |||| 10G LAN
     ||||           .---------------.
     |||+-----------+ DXP-480T NAS  |  172.168.50.48      Netzlaufwerke, Nextcloud, Home Assistant etc.
     |||            '---------------'
     |||  10G LAN
     |||            .---------------.
     ||+------------+   Notebook    |  172.168.50.4       Windows 11
     ||             '---------------'
     ||  2.5G LAN
     ||             .---------------.
     |+-------------+    Clients    |  172.168.50.x       Mini PC, Notebook, NAS
     |              '---------------'
     |     WiFi-7
     |              .---------------.
     +--------------+    Clients    |  172.168.50.x       Tablet, Notebook, Smartphones, IoT (später: VLAN)
                    '---------------'

[Anderer]

OK, es gab 2 A records. Nachdem Löschen des A records mit Wildcard, konnte ich CNAME mit Wildcard anlegen. Leider bleibe ich trotzdem bei 9.) hängen, da OPNsense > Schnittstellen > Diagnose > Ping > SUBDOMAN.dedyn.io (mit oder ohne "any_string") nicht auflöst, sondern weiterhin 100% Verlust, sendto: Host is down.

https://dnschecker.org/#CNAME mit any_string.SUBDOMAIN.dedyn.io zeigt propagated, aber nur SUBDOMAIN.dydyn.io (ohne any_string) ist nicht propagated. Ich nehme an, dass das korrekt ist, oder nicht?

https://dnschecker.org löst mit Erfolg zur korrekten IP auf.

https://www.ssllabs.com/ssltest/analyze.html löst zur korrekten IP auf, aber scheitert beim SSL Zertifikat.

https://www.ssllabs.com/ssltest/analyze.html scheitert, während
https://crt.sh/ die crt.sh.IDs mit korrektem Erstell- und Verfallsdaten zeigt.
=> mit Klick auf crt.sh.ID Link, sehe ich Details, wie Serial Number, Public Key, DNS usw. sowie:
OCSP check => mit Klick: No OCSP URL available
CRL, CRLSet, disallowedcert, OneCRL - all "Not Revoked".

OPNsense > Schnittstellen > Diagnose > Ping > SUBDOMAIN.dedyn.io (mit oder ohne any_string) weiterhin 100% Verlust, sendto: Host is down

Liegt das an der HAProxy Konfiguration oder müsste es zuvor noch einen Fehler geben, da bei 9.) der Ping-Test auflösen müsste?

Ping 8.8.8.8 führt ebenfalls zu 100% Verlust, sendto: Host is down, obwohl
Firewall: Protokolldateien: Liveansicht zeigt GRÜN:
WAN   192.168.178.5:5993   8.8.8.8:53   udp   let out anything from firewall host itself (force gw)

[viragomann]

Vorgehen analog Tutorial mit Adaption an aktuelle Felder und Einstellungen:
https://forum.opnsense.org/index.php?topic=23339.0

Das hatte ich mir auch durchgesehen, hatte es aber nicht so gelöst.
Einen Sinn des TCP frontends konnte ich für mich nicht erkennen.
Ich habe eines, das auf Port 80 lauscht und jegliche Anfragen auf https redirektet, und mehrer auf Port 443.

Mir fällt dazu in deiner HAproxy Konfig auf, dass da beim Frontend: 1_HTTPS_frontend zwar "(Listening on 127.4.4.3:443)" in der Bezeichnung seht, die Bind Adresse aber tatsächlich 192.168.50.1 ist.
Aber wie gesagt, mit diesem Konfigurationsvorschlag habe ich mich nicht auseinandergesetzt.

aber nur SUBDOMAIN.dydyn.io (ohne any_string) ist nicht propagated. Ich nehme an, dass das korrekt ist, oder nicht?

Ist wohl auch keine CNAME, oder?

https://www.ssllabs.com/ssltest/analyze.html scheitert, während
https://crt.sh/ die crt.sh.IDs mit korrektem Erstell- und Verfallsdaten zeigt.
=> mit Klick auf crt.sh.ID Link, sehe ich Details, wie Serial Number, Public Key, DNS usw. sowie:
OCSP check => mit Klick: No OCSP URL available
CRL, CRLSet, disallowedcert, OneCRL - all "Not Revoked".

Das heißt, die Analyze bricht komplett ab?
Dann würde ich vermuten, dass der Host keine Zertifikat liefert. Zeigt SSLLabs eines an?

OPNsense > Schnittstellen > Diagnose > Ping > SUBDOMAIN.dedyn.io (mit oder ohne any_string) weiterhin 100% Verlust, sendto: Host is down
Liegt das an der HAProxy Konfiguration oder müsste es zuvor noch einen Fehler geben, da bei 9.) der Ping-Test auflösen müsste?

Ping müsstest du am WAN mit einer FW-Regel erlauben.
HAproxy lauscht auf einen oder mehrer Ports. Ping (ICMP) kennt keine Ports. Pings landen demnach nicht auf HAproxy.

[meyergru]

Man kann keine ACME Wildcard-Zertifikate für Subdomains erstellen - so einfach ist das.

Schaut mal in die Vergaberichtlinien.

[Anderer]

Mir fällt dazu in deiner HAproxy Konfig auf, dass da beim Frontend: 1_HTTPS_frontend zwar "(Listening on 127.4.4.3:443)" in der Bezeichnung seht, die Bind Adresse aber tatsächlich 192.168.50.1 ist.

Das ist richtig. Danke. Ich hatte es geändert, um zu testen, wenn direkt auf OPNsense umgeleitet wird. Es ändert jedoch nichts, wenn ich zwischen den beiden IP wechsle.

Das heißt, die Analyze bricht komplett ab?
Dann würde ich vermuten, dass der Host keine Zertifikat liefert. Zeigt SSLLabs eines an?

SSLLabs schreibt 2x  Unable to connect to the server
Ich vermute, dass ich gar nicht so weit komme, da der Ping schon nicht funktioniert.

Ping müsstest du am WAN mit einer FW-Regel erlauben.
HAproxy lauscht auf einen oder mehrer Ports. Ping (ICMP) kennt keine Ports. Pings landen demnach nicht auf HAproxy.

Ich habe zunächst noch eine ICMP Regel eingerichtet und dann testweise WAN, incoming, pass, komplett freigegeben. Im Log ist jetzt auch alles grün - keine rote Zeile mehr, z. B. für Ping 8.8.8.8:

• WAN

  2025-10-03T16:49:45

  192.168.178.5:21236

  8.8.8.8:53

  udp

  let out anything from firewall host itself (force gw)

• WAN

  2025-10-03T16:49:44

  192.168.178.5

  8.8.8.8

  icmp

  let out anything from firewall host itself (force gw)

Ping geht trotzdem nicht.100% Verlust, sendto: Host is down

[viragomann]

Deine OPNsense sitzt demnach ja hinter einem anderen Router. Ist da alles weitergeleitet, was du testest, also hier mal ICMP und TCP 80 u. 443?

Wenn ja, geh mal auf Interfaces: Diagnostics: Packet Capture, selektiere WAN Interface und ICMP Protokoll, ggf. setze noch deine Quell-IP bei Host und starte das Capture.
Dann starte einen Ping und schau anschließend, ob da Pakete zu sehen sind.

Ich nehme an, du pingst aus dem Internet.

Wenn da nichts ist, hat es was mit der Weiterleitung, oder du bekommst schon von deinem ISP nichts weitergeleitet.

[Anderer]

Man kann keine ACME Wildcard-Zertifikate für Subdomains erstellen - so einfach ist das.

Danke für den Hinweis, aber mir mangelt es am Verständnis für die Umsetzung.
Im Tutorial wird das Wildcard Zertificat mit CNAME record empfohlen:
https://forum.opnsense.org/index.php?topic=23339.0

• Why are we using wildcard certificates and not just regular certificates?
  For me the main reason is simplicity, there is no need to set up multiple certificates for multiple subdomains.
  Also you don't need to add any rules in HAProxy or your firewall for the ACME plugin to function correctly as the DNS challenge doesn't need this.
  If you want to read more about the differences follow the links below.
  https://sectigostore.com/page/ssl-vs-wildcard-ssl-certificate/
  https://comodosslstore.com/resources/whats-the-difference-wildcard-certificate-vs-regular-ssl-certificate/

In deinem Kommentar vom 29.09.25 lese ich ebenfalls heraus:
https://forum.opnsense.org/index.php?topic=23339.msg248393;topicseen#msg248393

Also, you can (and should) use wildcard certificates if ever possible, because named certificates will be published and can be used to scan for IPv6-based services where a normal port scan is infeasible.

Ich habe jetzt einen CNAME record mit Wildcard auf SUBDOMAIN.dedyn.io sowie CAA mit issue und issuewild "letsencrypt.org". Falls das gar nicht geht, aber sinnvoll ist, könnte ich auch eine eigene Domain dafür nehmen, aber mit dedyn.io war es im Tutorial beschrieben.

Ich vermute allerdings, dass noch ein ganz anderes Problem zugrunde liegt, da auch Ping 8.8.8.8 nicht möglich ist, obwohl das FW-Log nun nur noch grüne Zeilen hat.

[Anderer]

Deine OPNsense sitzt demnach ja hinter einem anderen Router. Ist da alles weitergeleitet, was du testest, also hier mal ICMP und TCP 80 u. 443?

In der FritzBox ist "Exposed Host" eingestellt, aber fritz.box oder 192.168.178.1 erreiche ich ebenfalls nichtmehr, obwohl das FW-Log auch hier grün ist:

• LAN

  2025-10-03T17:20:19

  192.168.50.4:57262

  192.168.178.1:80

  tcp

  let out anything from firewall host itself

• LAN

  2025-10-03T17:20:12

  192.168.50.1:58177

  192.168.178.1:53

  udp

  let out anything from firewall host itself

• WAN

  2025-10-03T17:20:20

  192.168.178.5:2140

  34.999.8.122:443

  tcp

  let out anything from firewall host itself (force gw)

• WAN

  2025-10-03T17:20:20

  192.168.178.5:65485

  52.19.999.51:443

  tcp

  let out anything from firewall host itself (force gw)

Wenn ja, geh mal auf Interfaces: Diagnostics: Packet Capture, selektiere WAN Interface und ICMP Protokoll, ggf. setze noch deine Quell-IP bei Host und starte das Capture.
Dann starte einen Ping und schau anschließend, ob da Pakete zu sehen sind.

Bei Schnittstellen: Diagnose: Paketaufzeichnung kommt gar kein Eintrag, selbst wenn ich WAN+LAN auswähle sowie Adressfamilie und Protokoll beliebig. Ich habe dann Schnittstellen: Diagnose: Ping 8.8.8.8 getestet, Webseiten aufgerufen und Ping über CMD und über wieistmeineip.de getestet.

Wenn da nichts ist, hat es was mit der Weiterleitung, oder du bekommst schon von deinem ISP nichts weitergeleitet.

Ping-Test über wieistmeineip.de ist grün und bei cmd vom Notebook bekomme ich:

Code Select Expand

Ping wird ausgeführt für 8.8.8.8 mit 32 Bytes Daten:
Antwort von 8.8.8.8: Bytes=32 Zeit=11ms TTL=119
Antwort von 8.8.8.8: Bytes=32 Zeit=12ms TTL=119
Antwort von 8.8.8.8: Bytes=32 Zeit=11ms TTL=119
Antwort von 8.8.8.8: Bytes=32 Zeit=11ms TTL=119

Ping-Statistik für 8.8.8.8:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 11ms, Maximum = 12ms, Mittelwert = 11ms

[viragomann]

In der FritzBox ist "Exposed Host" eingestellt, aber fritz.box oder 192.168.178.1 erreiche ich ebenfalls nichtmehr, obwohl das FW-Log auch hier grün ist:

• LAN

  2025-10-03T17:20:19

  192.168.50.4:57262

  192.168.178.1:80

  tcp

  let out anything from firewall host itself

• LAN

  2025-10-03T17:20:12

  192.168.50.1:58177

  192.168.178.1:53

  udp

  let out anything from firewall host itself

• WAN

  2025-10-03T17:20:20

  192.168.178.5:2140

  34.999.8.122:443

  tcp

  let out anything from firewall host itself (force gw)

• WAN

  2025-10-03T17:20:20

  192.168.178.5:65485

  52.19.999.51:443

  tcp

  let out anything from firewall host itself (force gw)

Das sollte schon funktionieren.

Allerdings gehen die Pakete bei dir offenbar LAN Interface ruas, wie die ersten beiden Regeln zeigen. Die FritzBox hängt doch am WAN?
Ich frag mich auch, wo sie reinkommen.
Vielleicht solltest du mal deine Routingtabelle offenbaren.

Ping-Test über wieistmeineip.de ist grün

Bei mir auch, allerdings habe ich keine ICMP von außen erlaubt und das Firewall Log zeigt die Pings auch als geblockt. Die OPNsense hat selbt die öffentliche IP am WAN.
Da frag ich mich, wie die zu dem erfreulichen Ergebnis kommen.[/list]

[Anderer]

Allerdings gehen die Pakete bei dir offenbar LAN Interface ruas, wie die ersten beiden Regeln zeigen. Die FritzBox hängt doch am WAN?
Ich frag mich auch, wo sie reinkommen.

OPNsense hängt mit Sicherheit über WAN (igc0) an der FritzBox und am LAN (igc1) hängt der ASUS Router, an dem alle Clients hängen. So sind auch die LAN-Kabel eingesteckt. Das habe ich gerade nochmals überprüft.

Vielleicht solltest du mal deine Routingtabelle offenbaren.

Schnittstellen: Diagnose: Routenverfolgung 8.8.8.8, IPv4, UDP (ICMP analog) ergibt:
 traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 40 byte packets traceroute: sendto: Host is down..., timeout reached

Es sei nochmals erwähnt, dass ich Newbie bin und OPNsense auf einem neuen Mini-PC frisch installiert habe. Ich kann mit den FW-Regeln jetzt normal arbeiten (Internet, E-Mails etc.). Ich erreiche OPNsense, den ASUS Router, NAS und Clients, aber nicht fritz.box oder fritz.repeater - auch nicht über deren IP. Ich kann - meine ich - zu Testzwecken, die Regeln komplett öffnen, damit dort nichts hängen bleibt. Falls aber noch eine Verbindung, Mapping, Regel o. ä. fehlt, welche das Tutorial für HAProxy voraussetzt, dann weiß ich vermutlich garnicht, auf was ich schauen oder wonach ich suchen soll.

[viragomann]

OPNsense hängt mit Sicherheit über WAN (igc0) an der FritzBox und am LAN (igc1) hängt der ASUS Router, an dem alle Clients hängen. So sind auch die LAN-Kabel eingesteckt. Das habe ich gerade nochmals überprüft.

Viele Router für den Anfang.
Aber gut, wenn die OPNsense als Exposed Host an der FB hängt, sollte sie von außen erreichbar sein, sofern das überhaupt was reinkommt.
Hast du schon irgendwann mal erfolgreich Zugriff aus dem Internet auf dein Netzwerk gehabt?

Die Routing Tabelle ist über System: Routes: Status abrufbar.
Bitte auch die Gateway Konfiguration dazu: System: Gateways: Configuration

Mich stört das "let out anything from firewall host itself" im Regel-Log am LAN:

LAN      2025-10-03T17:20:19   192.168.50.4:57262   192.168.178.1:80   tcp   let out anything from firewall host itself

Was ist da die Quell-IP?
Wenn du die involvierten IPs erklären würdest, würde eine Analyse leichter fallen.

Ziel ist auf jeden Fall die FritzBox, und ein Paket zu dieser sollte nicht am LAN raus gehen, wenn sie am WAN angeschlossen ist.

[Patrick M. Hausen]

Man kann keine ACME Wildcard-Zertifikate für Subdomains erstellen - so einfach ist das.

Sehe ich anders. Ich habe hier aktive Wildcard-Zertifkate über Letsencrypt mit DNS-01 für:

- *.meinedomain.de
- *.meinwohnort.meinedomain.de

Läuft einwandfrei, zeige ich dir gerne beim nächsten Stammtisch 😉

Was nicht geht ist

- *.*.meinedomain.de

Die Wildcard umfasst immer nur genau eine Hierarchieebene.

[Anderer]

Hast du schon irgendwann mal erfolgreich Zugriff aus dem Internet auf dein Netzwerk gehabt?

Nein, von außen komme ich nicht auf mein Netwerk, jedenfalls nicht z. B. auf den Router - selbst wenn ich LAN/WAN alles beliebig mit pass freigebe. Da gibt es wohl automatische Regeln (Default deny / state violation rule, Quellports: 39440, 80, Zielports: 443, 61855), die den Zugriff trotzdem blockieren. Die wollte oder kann ich nicht anfassen.

Mein angedachtes Vorgehen war auf OPNsense HAProxy und LE-Zertifikate einzurichten, dort dann auch Nextcloud AIO und danach Wireguard zu installieren, um von außen Zugriff zu bekommen. Im Anschluss sollten auch NAS, OPNsense und Router oder weitere Apps wie Home Assistant über VPN erreichbar sein. Bei HAProxy stecke ich aber schon fest.

[Anderer]

System: Routen: Status

[Anderer]

System: Gateways: Konfiguration