OPNsense DynDNS via Cloudflare API: dynamische Public IP automatisieren

Viele kleine und mittelständische Unternehmen kämpfen mit dem gleichen Problem: Der Glasfaser- oder VDSL-Anschluss liefert eine dynamische Public IP, aber Standort-VPN, Remote-Zugriff auf die Telefonanlage oder ein selbst gehosteter Mailserver brauchen einen festen DNS-Namen. Klassische DynDNS-Anbieter wie No-IP oder DynDNS.org funktionieren, sind aber im Geschäftskontext zunehmend unattraktiv: TTLs von 5 Minuten, träge Propagation, gelegentliche Account-Sperren und schwache Zwei-Faktor-Optionen.

Wer ohnehin eine eigene Domain bei Cloudflare hält, hat einen deutlich eleganteren Hebel: Die OPNsense aktualisiert per Cloudflare API direkt einen A-Record in der eigenen Zone. Das os-ddclient Plugin in OPNsense 25.1 unterstützt Cloudflare nativ, der API-Token lässt sich präzise auf eine einzige Zone einschränken, und die TTL lässt sich auf den Cloudflare-Minimalwert von einer Minute setzen. In diesem Beitrag zeigen wir den vollständigen Setup-Weg, den Umgang mit Multi-WAN-Szenarien und die Stolpersteine, die uns in echten Projekten bei DATAZONE über den Weg gelaufen sind.

Warum Cloudflare als DynDNS-Backend

Cloudflare ist eigentlich als CDN und DDoS-Schutz bekannt, bietet aber als Nebeneffekt einen der schnellsten und stabilsten DNS-Dienste weltweit — mit DNS-Servern in über 300 PoPs. Für DynDNS-Zwecke bringt das drei handfeste Vorteile:

• Niedrige TTL: Cloudflare erlaubt für Free-Zonen eine TTL von einer Minute. Bei klassischen Registraren wie INWX, IONOS oder Strato liegt das Minimum oft bei 300 oder 600 Sekunden.
• Schnelle globale Propagation: Updates per API sind typischerweise in unter 30 Sekunden weltweit sichtbar. Wir messen in unseren Tests aus München, Frankfurt und Singapur Propagationszeiten von 15 bis 45 Sekunden.
• Sauberes Token-Modell: API-Tokens lassen sich pro Zone und pro Berechtigung scopen. Ein Token, das ausschliesslich DNS:Edit auf der Zone firma.de darf, kann bei Diebstahl keinen Account-weiten Schaden anrichten.

Hinzu kommt: Wenn Sie die Domain ohnehin bei Cloudflare führen, sparen Sie sich einen weiteren externen Account und ein weiteres Passwort im Stack.

API-Token in Cloudflare anlegen

Der erste Schritt findet im Cloudflare-Dashboard statt. Unter “My Profile — API Tokens — Create Token” wählen Sie nicht den Global API Key (der hat Vollzugriff auf den Account), sondern erstellen ein Custom Token mit minimalen Rechten:

Permission	Scope	Wert
Zone — DNS	Edit	aktiviert
Zone — Zone	Read	aktiviert
Zone Resources	Include — Specific Zone	firma.de
Client IP Filter	Operator: is in — IP/CIDR	optional
TTL	Start now — expires never	empfohlen

Der “Client IP Filter” ist optional, aber in Multi-WAN-Setups gefährlich: Wenn die OPNsense gerade über die Backup-Leitung rausgeht und Sie die Primär-IP gefiltert haben, schlägt das Update fehl. In der Praxis lassen wir den Filter offen und sichern den Token stattdessen per Token-Rotation alle sechs Monate ab.

Nach dem Klick auf “Create Token” wird der String genau einmal angezeigt. Diesen sicher in Ihrem Passwort-Manager ablegen — Cloudflare zeigt ihn nie wieder.

os-ddclient in OPNsense installieren

Das os-ddclient Plugin ist nicht im Default-Paketumfang enthalten, lässt sich aber per Klick nachinstallieren. Im OPNsense-Webinterface:

1. System — Firmware — Plugins
2. In der Liste os-ddclient suchen
3. Auf das ”+” klicken und die Installation bestätigen
4. Nach circa 30 Sekunden erscheint im Menü unter Services — Dynamic DNS der neue Eintrag

Im Hintergrund wird der ddclient Daemon installiert, der seit Version 4.0 ein nativ unterstütztes protocol=cloudflare Modul mitbringt. Frühere Versionen brauchten Workarounds mit nsupdate — das ist erfreulicherweise Geschichte.

Account und Service konfigurieren

In Services — Dynamic DNS — Settings legen Sie zwei Objekte an: einen Account (Ihr Cloudflare-Zugang) und einen Service (der konkrete DNS-Record).

Der Account-Eintrag braucht nur den API-Token, ein beschreibender Name reicht sonst. Den Service konfigurieren Sie dann so:

Enabled:      yes
Description:  fw-neuburg cloudflare
Service:      Cloudflare (v4)
Account:      cloudflare-firma-de
Username:     <leer lassen -- nur bei Global Key noetig>
Hostname:     fw.firma.de
Zone:         firma.de
TTL:          60
Check IP Mode: Interface
Interface:    WAN
Force SSL:    yes

Wichtig ist der “Check IP Mode”: Stellen Sie ihn unbedingt auf “Interface” und nicht auf “Web”. Der “Web”-Modus fragt einen externen Dienst nach der eigenen IP — das funktioniert zwar, ist aber bei Multi-WAN oder CG-NAT-Anschlüssen fehleranfällig. Der Interface-Modus liest die IP direkt vom WAN-Interface der OPNsense und ist damit deterministisch.

Multi-WAN: zwei Records, zwei Services

Spannend wird es, wenn die Firewall zwei aktive WAN-Anschlüsse hat — typisch Glasfaser primär plus LTE-Backup. Hier legen Sie zwei getrennte Service-Einträge an, jeweils mit eigenem Hostname:

Hostname	Interface	TTL	Zweck
fw-glasfaser.firma.de	WAN	60	Primärer Endpoint für VPN
fw-lte.firma.de	WAN2	60	Backup-Endpoint, immer aktiv
fw.firma.de	WAN	60	CNAME oder dynamisches Round-Robin

Den dritten Eintrag fw.firma.de setzen wir in der Praxis als zweistufige Lösung um: Ein Cloudflare Worker liest beide Records und liefert je nach Erreichbarkeit den passenden zurück. Wer es einfacher mag, nutzt einfach beide Hostnamen direkt im OPNsense-Site-to-Site-VPN-Profil als Failover-Endpoints.

Wichtig: Wenn die OPNsense per Gateway-Group beide Interfaces aktiv balanciert, sollte der DDNS-Service trotzdem fest pro Interface laufen, nicht über die Gateway-Group. Sonst wechselt die IP-Erkennung mit jedem Routing-Switch und Sie schreiben Cloudflare voll mit Update-Requests.

Subdomain-Handling und Wildcard-Records

Cloudflare verwaltet Subdomains als eigenständige Records. Das os-ddclient Plugin kann pro Service genau einen Record aktualisieren. Brauchen Sie mehrere Subdomains — etwa mail.firma.de, vpn.firma.de, cloud.firma.de — alle auf derselben dynamischen IP, gibt es zwei saubere Wege:

1. Mehrere Services in OPNsense: Pro Subdomain ein eigener Service-Eintrag. Funktioniert, ist aber unübersichtlich ab vier oder fünf Records.
2. Ein A-Record, mehrere CNAMEs: Nur fw.firma.de per DynDNS aktualisieren, alle anderen Hostnamen als CNAME auf fw.firma.de zeigen lassen. Das ist die saubere Variante.

Beachten Sie: Cloudflare’s “CNAME-Flattening” sorgt dafür, dass auch die Root-Domain firma.de per CNAME auf fw.firma.de zeigen kann — ein Feature, das klassisches DNS nicht erlaubt. Praktisch, wenn die Hauptdomain auf einen selbst gehosteten Webserver hinter der OPNsense zeigen soll.

Wildcard-Records (*.firma.de) lassen sich ebenfalls aktualisieren, allerdings muss der Hostname in OPNsense exakt als *.firma.de eingetragen werden und der Wildcard-Record vorab manuell in Cloudflare angelegt sein.

Troubleshooting und Monitoring

In Services — Dynamic DNS — Log File sehen Sie jeden Update-Versuch mit Zeitstempel. Typische Fehlerbilder:

• SUCCESS: updating fw.firma.de — alles gut, Record steht.
• WARNING: skipped, no IP change — normal, IP hat sich nicht geändert.
• ERROR: Cloudflare API returned 9109 — API-Token hat nicht genug Rechte oder ist auf die falsche Zone gescoped.
• ERROR: could not determine IP — “Check IP Mode” auf Interface, Interface aber Down.

Für produktive Setups empfehlen wir ein zusätzliches externes Monitoring — etwa Uptime Kuma oder Checkmk — das den DNS-Record alle 60 Sekunden auflöst und mit der erwarteten IP vergleicht. So fallen stille Token-Expirations sofort auf, nicht erst wenn der Site-to-Site-VPN beim Kunden nicht mehr aufbaut.

Wenn Sie OPNsense produktiv mit dynamischer Public IP betreiben und sauber ins Cloudflare-Ökosystem integrieren möchten, unterstützt Sie DATAZONE bei Setup, Multi-WAN-Architektur und Monitoring. Auch komplette Firewall-Migrationen von Sophos oder Lancom auf OPNsense sind Teil unseres Tagesgeschäfts in Neuburg an der Donau. Sprechen Sie uns gerne an — über unser Kontaktformular oder telefonisch.