DynDNS-Probleme - oder tiefer liegender Fehler mit meiner Installation?

[viragomann]

Sobald ich die Standardroute sowie Verbose und Allow IPv6 jeweils aktiviere, funktioniert es wieder:
Code Select Expand

Code Select Expand

2025-10-09T18:20:46 Notice ddclient SUCCESS:  SUBDOMAIN.dedyn.io: skipped: IP address was already set to 93.214.62.185.
Ich frage deshalb nochmals nach, damit am Ende nicht die ganze Installation auf wackligen Beinen steht, weil IPv4 o. a. eigentlich nicht korrekt funktioniert.

Also ich habe hier auch ein OPNsense WAN an einem DHCP Server hängen. Ich hatte keine Route manuell eingetragen. Das geschah automatisch.
Ist die Standardroute mit der FB als Gateway in System: Routes: Status gelistet?

In System: Gateways: Configuration müsste ebenso die FB IPv4 als Gateway zu sehen sein.

Dann sollte die OPNsense nach außen verbinden können. Bspw. ein Ping auf 1.1.1.1

[meyergru]

Eventuell ist auch ein IPv6 DNS-Server konfiguriert. Wenn der nicht erreichbar ist, ist selbstverständlich auch die Auflösung von Namen gestört (oder verlangsamt). Das zu tun, ist natürlich nur sinnvoll, wenn IPv6 auch richtig funktioniert.

[Anderer]

Dann sollte die OPNsense nach außen verbinden können. Bspw. ein Ping auf 1.1.1.1

Also PING 1.1.1.1, 8.8.8.8, 9.9.9.9 oder andere Domains haben immer funktioniert.
Lediglich SUBDOMAIN.dedyn.io funktioniert nur mit Standardroute und IPv6 aktiviert.

System: Routes: Status

Code Select Expand

Protokoll    Ziel                                Gateway                            Flags    MTU     Netzwerk        Netzwerkschnittstelle
ipv4         default                             192.168.178.1                      UGS      1500    WAN             igc1
ipv4         127.0.0.1                           link#7                             UH       16384   Loopback        lo0
ipv4         192.168.50.0/24                     link#1                             U        1500    LAN             igc0
ipv4         192.168.50.1                        link#7                             UHS      16384   Loopback        lo0
ipv4         192.168.178.0/24                    link#2                             U        1500    WAN             igc1
ipv4         192.168.178.5                       link#7                             UHS      16384   Loopback        lo0
ipv6         default                             fe80::...%igc1                     UG       1500    WAN             igc1
ipv6         ::1                                 link#7                             UHS      16384   Loopback        lo0
ipv6         2003:xxxx:xxxx::/64                 link#2                             U        1500    WAN             igc1
ipv6         2003:xxxx:xxxx:...                  link#7                             UHS      16384   Loopback        lo0
ipv6         2003:xxxx:xxxx:...                  fe80::...%igc1                     UGHS     1500    WAN             igc1
ipv6         fdxx:xxxx:xxxx::/64                 link#2                             U        1500    WAN             igc1
ipv6         fdxx:xxxx:xxxx:...                  link#7                             UHS      16384   Loopback        lo0
ipv6         fdxx:xxxx:xxxx:...                  fe80::...%igc1                     UGHS     1500    WAN             igc1
ipv6         fe80::%igc0/64                      link#1                             U        1500    LAN             igc0
ipv6         fe80::...%lo0                       link#7                             UHS      16384   Loopback        lo0
ipv6         fe80::%igc1/64                      link#2                             U        1500    WAN             igc1
ipv6         fe80::...%lo0                       link#7                             UHS      16384   Loopback        lo0
ipv6         fe80::%lo0/64                       link#7                             U        16384   Loopback        lo0
ipv6         fe80::1%lo0                         link#7                             UHS      16384   Loopback        lo0

[Anderer]

Eventuell ist auch ein IPv6 DNS-Server konfiguriert.

System: Settings: General:  Prefer IPv4 over IPv6: No
=> Soll ich das auf Yes,  Prefer to use IPv4 even if IPv6 is available umstellen?
=> DNS servers habe ich komplett leer gelassen

Ich werde nochmals alle Einstellungen nach IPv6 durchsuchen, da ich das tatsächlich gerne beheben würde.


Zwischenzeitlich habe ich noch eine EIGENE DOMAIN direkt über do.de mit FlexDNS eingerichtet, um mögliche Fehler bei DynDNS auszuschließen.

[meyergru]

Ich wollte damit nur sagen: Wenn Du IPv6 für bestimmte Zwecke deaktivierst, für andere aber nicht, dann greift die Regel, dass IPv6 bevorzugt verwendet wird. Wenn also IPv6 nicht komplett deaktiviert ist, kann es dann passieren, dass per IPv6 eben keine Namensauflösung klappt, was ja anscheinend Dein Problem war. Also entweder gar kein IPv6 oder eben funktionierend - problematisch wäre IPv6 aktiviert, funktioniert aber nicht.

Und wenn Du keine DNS-Server einträgst, dann werden je nach Einstellungen in Unbound (wenn Du den verwendest) die Namen direkt resolviert (wobei jedes Protokoll, dass eingeschaltet ist - nicht: funktioniert - ausprobiert oder irgendwelche ISP-DNS-Server verwendet oder DoT-Server.

[Anderer]

Hier noch die Ergebnisse meiner IPv6-Suche:

System: Gateways: Configuration

• WAN_DHCP (active), WAN, IPv4, 254, 192.168.178.1, Status: grün, Interface WAN_DHCP Gateway
• WAN_DHCP6 (active), WAN, IPv6, 254, fe80::dj76:87ff:ad45:a354, Status: grün, Interface WAN_DHCP6 Gateway

Interfaces: Overview

Code Select Expand

Status        Device    VLAN    IPv4            IPv6            Gateway        Routes
LAN (lan)    Igc0    static    192.168.50.1/24        fe80::...:c2f5/64            192.168.50.0/24
                                                fe80::%igc0/64
WAN (wan)    Igc1    dhcp    192.168.178.5/24    2003:...:c2f6/64    192.168.178.1    default
                            fd5e:...:c2f6/64    fe80::...:e579    192.168.178.0/24
                            fe80::...:c2f6/64            default
                                                2003:...:e579
                                                fd5e:...:e579
                                                fe80::%igc1/64
Unassigned    Igc2, 3, 4, 5                       
           
Loopback    lo0    static    127.0.0.1/8        ::1/128                    127.0.0.1
                            fe80::1/64                192.168.50.1
                                                192.168.178.5
                                                ::1
                                                2003:...:c2f6
                                                fd5e:...:c2f6
                                                fe80::...:c2f6%lo0
                                                fe80::...:c2f5%lo0
                                                fe80::%lo0/64
                                                fe80::1%lo0
Unassigned    eno0                       
Unassigned    pflog0       


• Services: Dynamic DNS: Settings: advanced mode
  Verbose: No 
  Allow IPv6: No

• System: Routes: Configuration:
  0.0.0.0/0, WAN_DHCP - 192-168-178.1 Standardroute (noch aktiviert)
• Ergebnis:
  Ping EIGENE_ DOMAIN.de funktioniert
  Ping SUBDOMAIN.dedyn.io funktioniert nicht

Ich werde morgen nochmals nach Unterschieden zwischen den beiden Domains suchen und das Tutorial zu Ende durchgehen.

[Anderer]

Also entweder gar kein IPv6 oder eben funktionierend

• Wie kann ich bitte für den Anfang sicherstellen, dass "gar kein IPv6" aktiviert ist?
• Soll ich das WAN Gateway IPv6 deaktivieren?
• Dürfte ich dann bei
  
  • - Interfaces:Overview
  • - System: Gateways: Configuration

• GAR KEINE IPv6 Adressen sehen?

Ich habe die Beiträge READ THIS FIRST und OpnSense für Dummies (speziell für Fritzbox-Umsteiger) sowie mehrere zu "RFC 1918" nochmals genau gelesen.

• OPNsense hängt als "Exposed Host" mit selbständiger Portfreigabe hinter einer FritzBox 5690 Pro an deren WLAN
• Die FritzBox soll hier nur das Internet an der WAN-Schnittstelle der OPNsense zur Verfügung stellen. Keine andere Aufgabe.
• Leider kann ich das physikalische Setup aktuell hier nicht ohne Weiteres ändern/verbessern, aber letzten Sonntag funktionierte HAProxy mit DynDNS und ACME.

Tatsächlich habe ich jedoch noch immer ein Problem mit "RFC 1918", welches ich am Sonntag nicht hatte.

• SSLLabs meldet für meine EIGENE_DOMAIN.de
  - Certificate not valid for domain name
  - IP address is from private address space (RFC 1918)
  => also wird noch immer die RFC 1918 statt öffentlicher IP übermittelt.

Die Zertifikate für *.EIGENE_DOMAIN.de und *.SUBDOMAIN.dedyn.io wurden jedoch ausgestellt und installiert. Last ACME Status: OK
=> SUBDOMAIN.dedyn.io habe ich danach überall deaktiviert (ACME: Accounts, Challenge Types, Certificates; Dynamic DNS: Settings: Accounts)

Meine EIGENE_DOMAIN.de ist bei do.de (Domain Offensive) gehostet und dort nutze ich das integrierte FlexDNS, also ohne weiteren DynDNS-Provider dazwischen.

Ergänzung:

Interfaces: [WAN]: IPv6 Configuration Type: None (jetzt deaktiviert)

System: Gateways: Configuration: Es gibt nur noch IPv4

Interfaces: Overview: IPv6 Adressen werden trotzdem noch mit /64 am Ende sowie bei Routen angezeigt

Services: Dynamic DNS: Settings: Accounts zeigt die korrekte öffentliche IPv4

Interfaces: Diagnostics: Trace Route: ANY_STRING.MEINE_DOMAIN.de ergibt:  has multiple addresses
ohne ANY_STRING, also nur mit MEINE_DOMAIN.de kommt dieser Fehler nicht

Code Select Expand

traceroute: Warning: xxx.de has multiple addresses; using 116.181.223.12 traceroute to xxx.de (116.181.223.12), 64 hops max, 40 byte packets

TTL AS# Host Address Probes
1 AS0 192.168.178.1 192.168.178.1 2.363 ms
2 AS3320 p3e9bf52b.dip0.t-ipconnect.de 62.155.245.43 6.253 ms
3 AS3320 f-ed53-i.F.DE.NET.DTAG.DE 217.5.118.230 11.250 ms
4 AS3320 62.157.443.128 62.157.251.167 11.394 ms
5 AS24940 core12.nbg1.hetzner.com 213.239.245.34 15.016 ms
8 AS24940 268338.your-cloud.host 128.140.19.82 20.061 ms

[meyergru]

https://www.thomas-krenn.com/en/wiki/OPNsense_disable_IPv6

Offenbar hat der DNS-Eintrag mehrere Adressen - Du willst ja offenbar nur eine und zwar eine IPv4, die nicht RFC1918 ist. Wie gesagt, ich kenne den DDNS-Provider nicht, aber Du musst sicherstellen, dass nur eine IP vorhanden ist - im Zweifel, indem Du dort alle anderen Adressen per Web-UI löschst.

[Anderer]

https://www.thomas-krenn.com/en/wiki/OPNsense_disable_IPv6

Offenbar hat der DNS-Eintrag mehrere Adressen - Du willst ja offenbar nur eine und zwar eine IPv4, die nicht RFC1918 ist. Wie gesagt, ich kenne den DDNS-Provider nicht, aber Du musst sicherstellen, dass nur eine IP vorhanden ist - im Zweifel, indem Du dort alle anderen Adressen per Web-UI löschst.

Sehr guter Link. Dankeschön. Ich habe das durchgearbeitet und eine Frage, die dort unterschiedlich zum Tutorial oder sonstigen Empfehlungen ist:

• Block private networks: Y/N
• Block bogon networks: Y/N

Jetzt habe ich auch verstanden, woher die "multiple addresses" kamen und beim Hoster alle Records gelöscht und nur CAA und CNAME eingetragen.
Anschließend wurde A mit der korrekten öffentlichen IPv4 und AAAA mit :: vermutlich durch ddclient gesetzt.
Der Hinweis von ssllabs.com auf private address space (RFC 1918) stand übrigens bei IPv6: 0:0:0:0:0:0:0:0
Bei der öffentlichen IPv4 steht jetzt Ready.
Immerhin bekomme ich jetzt ein Zertifikat mit A, ohne +, aber das könnte noch and diesen Cliphers liegen. Dazu lese ich nochmals nach.

Beim Aufruf von intern und extern bekomme ich jetzt 503 Service Unavailable
Das war zuvor nicht und da muss ich ggf. auch nochmals danach suchen.

https://dnschecker.org/dns-record-validation.php zeigt folgende Hinseise:

• Name Servers are on the Same Subnet.
• SOA Expire Value is out of recommended range.
• SOA Serial Number Format is Invalid.

Gibt eis dazu bitte einen Hinweis, was ich bei den Records ändern sollte? Printscreen anbei

[viragomann]

Ich habe das durchgearbeitet und eine Frage, die dort unterschiedlich zum Tutorial oder sonstigen Empfehlungen ist:

• Block private networks: Y/N
• Block bogon networks: Y/N

Du könntest dir auch mal selbst zu den diversen Einstellungen Gedanken machen anstatt jedes Detail hier zu erfragen.
Die beiden Punkte sind selbsterklärend. Wenn du mehr Information benötigst, klicke auf das "i" links daneben, oder schalte rechts oben "full help" ein. Das macht die Seite zwar nicht übersichtlicher, hilft aber einem Anfänger beim Einstieg.

Immerhin bekomme ich jetzt ein Zertifikat mit A, ohne +, aber das könnte noch and diesen Cliphers liegen. Dazu lese ich nochmals nach.

Es liegt nicht ausschließlich an den Ciphers. Aber ja, schwache sollten rausgeworfen werden. Hier mal meine, die an A+ beteiligt sind:
Cipher Suites: TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256

Auch ein CAA Record im DNS und HSTS (HAproxy Frontend) mit langer Laufzeti wird da positiv bewertet. Letzteres empfehle ich aber erst dann zu aktivieren, wenn sonst alles läuft, vor allem, wenn du nicht weißt, was es macht und wie du ein Problem damit lösen kannst, was ich annehme. Das hat schon so manchen zur Weißglut gebracht.

Beim Aufruf von intern und extern bekomme ich jetzt 503 Service Unavailable
Das war zuvor nicht und da muss ich ggf. auch nochmals danach suchen.

Gute Idee.
Üblicherweise bedeutet es, dass das Backend auf Anfragen von HAproxy nicht (korrekt) antwortet.
Erst mal in Services: HAProxy: Maintenance den Backend-Status prüfen. Is der down, antwortet das Backend nicht auf Health Checks und HAproxy versucht gar nichts weiteres. Die sind dann meist falsch konfiguriert, sollte es eigentlich antworten.
Es könnte aber auch ein anderer Konfigurationsfehler in HAproxy oder im Backend vorliegen.

https://dnschecker.org/dns-record-validation.php zeigt folgende Hinseise:

• Name Servers are on the Same Subnet.
• SOA Expire Value is out of recommended range.
• SOA Serial Number Format is Invalid.

[/list]
Gibt eis dazu bitte einen Hinweis, was ich bei den Records ändern sollte? Printscreen anbei

Ersteres ist wieder selbsterklärend. Ist einfach so. Du kannst dir ggf andere Namensserver suchen.

"SOA Expire Value" ist wohl das Zeitlimit in deinem Screenshot. Wenn du es dnschecker.org recht machen möchtest, musst du herausfinden, was sie denn empfehlen. Ich hätte mit dem Wert kein Problem.
"SOA Serial Number" kannst du anscheinend eh nicht ändern, wie der Screenshot vermuten lässt.
Es gibt unterschiedliche Verfahren der Zählung bzw. unterschiedliche Startnummern. Das Prüftool mag wohl eher ein anderes.

[Anderer]

Vorab: Probleme weitgehend gelöst.

Zusammenfassung:

• OPNsense finde ich sehr gut und möchte das auf jeden Fall nutzen und mit der Zeit weiter vertiefen.
• Bei HAProxy gefällt mir der Aufbau mit Server, Backend, Map-File, ACME-Plugin usw. besser, als bei Caddy, aber vielleicht nur, weil ich mich damit zuerst und viel länger beschäftigt hatte. Evtl. schaue ich mir das später, mit mehr Zeit, nochmals an.
• Caddy hatte mich gestern morgen zunächst abgeschreckt, da mir ein Tutorial mit PrintScreen fehlte und einige Fragen unbeantwortet blieben.
• Ohne DeepSeek hätte ich gestern Caddy nicht installieren können und trotzdem musste ich aufmerksam Fehler korrigieren, die auch DeepSeek machte.
• Ohne OPNsense zu installieren, loszulegen und vor allem im Forum die Unterstützung zu erhalten, wäre ich gar nicht soweit gekommen. Nur mit Lesen, sehe ich nicht, wie das funktionieren könnte. Es bleibt auch unklar, weshalb Caddy funktioniert und HAProxy nicht.

Ergebnis:

• tatsächlicher Installationsaufwand (ohne HAProxy und Fehlersuche) ca. 4-6 Stunden für OPNsense vom USB-Stick, wenige Grundeinstellungen (IP, DHCP, Port, Backup), DynDNS (ddclient) und Caddy sowie Nextcloud AIO auf dem NAS inkl. Fehlerbehebung (Header, MIME-TYPE, CLI-URL etc.) sowie eigene Doku.
• ddclient und caddy laufen und waren einfach bzw. problemlos zu installieren
• FlexDNS und Token für Let's Encrypt von Domain Offensive (do.de) ist bereits inklusive und einfach einzustellen.
• nc.DOMAIN.de, nas.DOMAIN.de usw. sind von intern und extern erreichbar "Verbindung sicher"
• ssllabs.com bestätigt A+ Zertifikat
• Nextcloud AIO installiert. Version: Nextcloud Hub 25 Autumn (32.0.0)
• bei nc.DOMAIN.de erfolgreich angemeldet
• NC Fehler und Warnungen konnte ich heute weitgehend beheben

noch offen:

• Synchronisation mit Thunderbird, Smartphones etc.
• dnschecker.org meldet SOA Warnungen, lt. Domain Offensive do.de jedoch unerheblich (z. B. anderes Zahlenformat)
• Services: Caddy: Log File meldet Fehler und Warnungen, die noch zu klären wären, aber Funktionalität ist soweit gegeben
• andere Log Files von System und anderen Plugins prüfen

Herzlichen Dank nochmals an alle für Tutorials sowie die Unterstützung in Beiträgen und per PN. Das war sehr hilfreich und notwendig.