OPNsense - Kea DHCP mit Hochverfügbarkeit
Auf einen Blick
| Gilt für | OPNsense 26.1 und 26.7 (Services → Kea DHCP, im Kern enthalten), Kea 3.0 |
|---|---|
| Bereich | IT-Security |
| Dauer | ca. 45 Minuten (DHCPv4 mit HA-Cluster aus zwei Firewalls) |
| Rechte | Administrator (OPNsense-WebUI), bestehender CARP/HA-Cluster |
| Stand | Oktober 2026 (OPNsense 26.7.5, Kea 3.0.4) |
Kea DHCP in OPNsense ist der moderne DHCP-Server des Internet Systems Consortium (ISC) und Nachfolger des klassischen ISC-DHCP. Seine besondere Stärke ist die Hochverfügbarkeit (HA): Zwei OPNsense-Firewalls synchronisieren ihre Leases fortlaufend, sodass bei einem Ausfall die zweite Firewall nahtlos weiterarbeitet – ohne getrennte Adresspools und ohne Adresskonflikte. Dazu kommen Reservierungen mit CSV-Import, flexible DHCP-Optionen, Prefix Delegation für IPv6 und dynamische DNS-Updates (DDNS).
Dieser Artikel zeigt die Einrichtung mit OPNsense 26.7 und legt den Schwerpunkt auf den HA-Betrieb im CARP-Cluster: Funktionsweise, Schritt-für-Schritt-Konfiguration, Failover-Zeiten, Tests und typische Fehler.
Kea oder Dnsmasq?
Seit OPNsense 26.1 ist Dnsmasq der Standard-DHCP-Server, ISC-DHCP ist nur noch als Plugin erhältlich. Kea ist die Wahl für größere und hochverfügbare Umgebungen:
| Kriterium | Kea DHCP | Dnsmasq |
|---|---|---|
| Einsatzgröße | mittel bis groß (laut OPNsense ab ca. 1.000 Clients), viele VLANs | klein bis mittel |
| Hochverfügbarkeit | Lease-Synchronisation zwischen zwei Servern (hot-standby) | getrennte Pools, Backup antwortet verzögert |
| DNS-Registrierung | DDNS (RFC 2136) mit TSIG an einen updatefähigen DNS-Server | integriert, direkt mit Unbound nutzbar |
| IPv6 Prefix Delegation | ja (statisch und dynamisch, inkl. Routen) | nein |
| Konfiguration | umfangreicher, Optionen pro Subnetz und Reservierung | einfacher, Tags |
Menü und Bausteine
Unter Services → Kea DHCP:
| Menüpunkt | Zweck |
|---|---|
| Control Agent | REST-Schnittstelle von Kea – Voraussetzung für HA |
| DDNS Agent | Vermittler für dynamische DNS-Updates (D2-Server) |
| Kea DHCPv4 / Kea DHCPv6 | Reiter Settings, Subnets, Reservations, HA Peers, Options (bei DHCPv6 zusätzlich Prefix Delegation) |
| Leases DHCPv4 / Leases DHCPv6 | aktuelle Leases, einzelne Leases löschen; auch als Dashboard-Widget |
| Log File | Meldungen aller Kea-Dienste, inklusive HA-Zustandswechsel |
Die Leases werden in einer Datei gespeichert (memfile, persistent), sodass sie Neustarts überstehen.
Teil 1: Kea DHCPv4 auf einer Firewall
Grundeinstellungen
Services → Kea DHCP → Kea DHCPv4 → Settings:
- Enabled und Interfaces (z. B. LAN, VLANs)
- Valid lifetime – Lease-Dauer in Sekunden (Standard pro Dienst, pro Subnetz überschreibbar)
- Firewall rules – legt die nötigen DHCP-Regeln automatisch an
- Socket Type raw (Standard); udp nur, wenn ausschließlich über DHCP-Relays verteilt wird
Subnetze
Reiter Subnets → +:
| Feld | Beispiel / Hinweis |
|---|---|
| Subnet | 192.168.1.0/24
|
| Pools | 192.168.1.100 - 192.168.1.199 (mehrere Zeilen möglich)
|
| Auto collect option data | bei Einzelbetrieb aktiv – Gateway, DNS und NTP werden aus der Schnittstelle übernommen. Im HA-Betrieb deaktivieren! |
| Routers (gateway) / DNS servers | bei HA die CARP-Adresse, z. B. 192.168.1.1
|
| Domain name / Domain search / NTP servers | nach Bedarf |
| Classless static routes | Option 121 für zusätzliche Routen |
| ICMP ping | prüft vor der Vergabe, ob die Adresse frei ist (26.7.5: weitere Einstellungen pro Subnetz) |
| Next server / TFTP server / TFTP bootfile name | für PXE-Boot |
| Match client-id | Standard: Clients werden über die Client-ID erkannt; deaktivieren, um MAC-basiert zu arbeiten |
Eigene Optionen (z. B. Option 66/150 für VoIP-Telefone) werden im Reiter Options angelegt und im Subnetz oder in einer Reservierung ausgewählt.
Reservierungen
Reiter Reservations: Subnetz, IP address, MAC address bzw. Client ID, optional Hostname und abweichende Optionen (Gateway, DNS, Routen). Über Import/Export im CSV-Format lassen sich viele Einträge auf einmal pflegen – etwa die aus dem ISC-DHCP-Plugin exportierten statischen Zuordnungen bei einer Migration.
Teil 2: Hochverfügbarkeit mit zwei OPNsense
So funktioniert Kea HA
OPNsense konfiguriert Kea HA im Modus hot-standby:
- Beide Firewalls betreiben Kea mit identischer Konfiguration (über die HA-Synchronisation von OPNsense).
- Der primary-Server beantwortet alle DHCP-Anfragen und überträgt jede neue oder verlängerte Lease sofort an den standby-Partner.
- Die Partner tauschen alle 10 Sekunden ein Heartbeat-Signal aus (heartbeat-delay).
- Antwortet der Partner 60 Sekunden lang nicht (max-response-delay) und bleiben zusätzlich Anfragen von Clients unbeantwortet (Max Unacked clients, Standard 2), wechselt der Standby in den Zustand partner-down und vergibt selbst Adressen aus denselben Pools.
- Kehrt der Primary zurück, gleicht er zuerst die Leases mit dem Partner ab (sync-timeout 60 Sekunden) und übernimmt dann wieder.
- Die Kommunikation läuft über einen eigenen HTTP-Listener je Peer (Multi-Threaded HA, HA+MT), der Control Agent selbst darf daher auf
127.0.0.1lauschen.
Beispiel-Szenario
| Eigenschaft | Wert |
|---|---|
| LAN | 192.168.1.0/24
|
| CARP-Adresse LAN | 192.168.1.1
|
| Master (fw1) LAN | 192.168.1.2
|
| Backup (fw2) LAN | 192.168.1.3
|
| Pool | 192.168.1.100 - 192.168.1.199
|
Voraussetzung ist ein funktionierender CARP-Cluster mit Konfigurations-Synchronisation (System → High Availability). Alle Einstellungen erfolgen auf dem Master und werden anschließend auf den Backup übertragen.
Schritt 1: Control Agent
Services → Kea DHCP → Control Agent: Enabled, Bind address 127.0.0.1, Bind port 8000 → Apply.
Schritt 2: DHCPv4-Einstellungen mit HA
Kea DHCPv4 → Settings:
- Enabled, Interfaces = LAN, Firewall rules aktiv
- Abschnitt High Availability: Enabled; This server name leer lassen bzw. den vorgeschlagenen Standard (Hostname der Firewall) übernehmen – so ergibt sich auf jeder Firewall automatisch der richtige Name.
- Max Unacked clients: Standard
2; mit0löst bereits jede Netzstörung einen Failover aus, höhere Werte machen den Failover in kleinen Netzen träger.
Schritt 3: Subnetz für HA
Subnets: Subnet 192.168.1.0/24, Pools 192.168.1.100 - 192.168.1.199, Auto collect option data aus, Routers und DNS servers = 192.168.1.1 (CARP).
Schritt 4: HA Peers
Reiter HA Peers, zwei Einträge (auf dem Master angelegt, gelten für beide Firewalls):
| Name | Role | Url |
|---|---|---|
| Hostname von fw1 (wie unter This server name angezeigt) | primary | http://192.168.1.2:8001/
|
| Hostname von fw2 | standby | http://192.168.1.3:8001/
|
Der Port der Peers (8001) muss sich vom Port des Control Agents (8000) unterscheiden. Als Adressen die physischen Adressen der Firewalls verwenden, nicht die CARP-Adresse. Speichern und Apply.
Schritt 5: Synchronisieren
- System → High Availability → Settings: unter Services to synchronize Kea DHCP auswählen.
- System → High Availability → Status: Synchronize and reconfigure all.
Danach läuft Kea auf beiden Firewalls, und die Leases werden in beide Richtungen synchronisiert.
Schritt 6: Firewall und Netz
- Die Peers erreichen sich per HTTP auf TCP 8001 über die angegebenen Adressen. Liegen diese im LAN, erlaubt die übliche LAN-Regel den Verkehr; bei einer eigenen Sync-Schnittstelle eine Regel für TCP 8001 zwischen den Firewalls anlegen.
- Die HA-Kommunikation ist unverschlüsselt und ohne Anmeldung – Peer-Adressen nur in vertrauenswürdigen Netzen bzw. auf einer dedizierten HA-/Sync-Schnittstelle verwenden.
- Beide Firewalls per NTP synchron halten: Kea prüft die Uhrzeit des Partners und stellt die Synchronisation bei größerer Zeitabweichung ein.
Failover testen
- Unter Leases DHCPv4 auf beiden Firewalls prüfen, ob dieselben Leases erscheinen (ein neuer Client muss auf beiden sichtbar sein).
- Auf dem Primary den Kea-Dienst stoppen (Dashboard-Widget Services) oder die Firewall herunterfahren.
- Im Log File des Standby den Wechsel nach partner-down verfolgen – nach etwa 60 Sekunden plus unbeantworteten Client-Anfragen übernimmt er.
- Einen Client neu verbinden: Er erhält eine Adresse vom Standby, Gateway und DNS bleiben die CARP-Adresse.
- Primary wieder starten: Er synchronisiert die Leases und übernimmt erneut.
Bestehende Clients merken vom Failover in der Regel nichts – sie verlängern ihre Lease erst nach der Hälfte der Laufzeit und erreichen dann den aktiven Server.
Weitere Netze und DHCPv6
Für jedes weitere VLAN genügt ein weiteres Subnetz mit eigener CARP-Adresse als Gateway/DNS; die HA-Peers gelten für alle Subnetze. Für DHCPv6 werden Control Agent und HA analog unter Kea DHCPv6 eingerichtet (eigene HA Peers, anderer Port als bei DHCPv4, z. B. 8002). Router Advertisements kommen weiterhin aus Services → Router Advertisements (bei Kea im Modus Assisted oder Managed).
Prefix Delegation (IPv6)
Kea delegiert IPv6-Präfixe an nachgelagerte Router – statisch per Reservierung oder dynamisch aus einem Pool. OPNsense installiert dafür automatisch die passenden Routen zum jeweiligen Router (Route Installation). Das ist der wichtigste Grund, im IPv6-Umfeld Kea statt Dnsmasq zu verwenden.
Dynamisches DNS (DDNS)
Kea registriert Clients nicht direkt in Unbound, sondern sendet Updates nach RFC 2136 an einen autoritativen DNS-Server, der dynamische Updates annimmt:
- DDNS Agent aktivieren (Bind address
127.0.0.1, Port53001). - Im Subnetz die Felder DNS forward zone (z. B.
lan.internal.), DNS reverse zone, DNS server address sowie TSIG key name/secret/algorithm ausfüllen. - Als Ziel eignet sich z. B. das Plugin os-bind mit einer dynamischen Zone; Unbound leitet diese Zone per Query Forwarding an BIND weiter (siehe OPNsense - Unbound DNS Resolver).
Die OPNsense-Oberfläche bietet TSIG an, aber kein GSS-TSIG – AD-integrierte Windows-Zonen mit „nur sicheren Updates“ lassen sich so nicht direkt beschreiben.
Migration von ISC-DHCP
- Im ISC-DHCP-Plugin die statischen Zuordnungen als CSV exportieren.
- In Kea die Subnetze (mit Pools und Optionen) anlegen und die Reservierungen per CSV importieren.
- Im Wartungsfenster ISC-DHCP auf den Schnittstellen deaktivieren, Kea aktivieren; im HA-Cluster anschließend wie oben synchronisieren.
- In Unbound Register ISC DHCP4 Leases deaktivieren und – falls Namen benötigt werden – DDNS einrichten.
- Nach erfolgreichem Umstieg das Plugin os-isc-dhcp entfernen.
Sicherheitsempfehlungen
- Control Agent nur auf
127.0.0.1binden; HA-Peers nur über vertrauenswürdige Netze. - DHCP nur auf den benötigten Schnittstellen aktivieren; Rogue-DHCP per DHCP Snooping auf den Switches verhindern.
- Decline Probation Period (erweitert) beibehalten bzw. moderat wählen – fehlerhafte Clients können sonst den Pool mit abgelehnten Adressen blockieren.
- TSIG-Schlüssel für DDNS geheim halten und je Zone getrennt vergeben.
- Kea-Logs (HA-Zustandswechsel, erschöpfte Pools) an ein Monitoring oder SIEM übertragen, z. B. mit dem Wazuh-Agent oder Zabbix.
Typische Probleme und Lösungen
| Symptom | Ursache und Lösung |
|---|---|
| Kea startet nicht | Anderer DHCP-Server (Dnsmasq/ISC) auf derselben Schnittstelle aktiv; Log prüfen. |
| HA-Hook startet nicht | Control Agent nicht aktiviert, This server name passt zu keinem HA-Peer oder Peer-Port gleich dem Control-Agent-Port. |
| Partner wird als nicht erreichbar gemeldet | Peer-URL falsch, TCP 8001 blockiert, Kea auf dem Partner gestoppt oder Konfiguration nicht synchronisiert. |
| HA bleibt im Zustand waiting/syncing | Partner nicht erreichbar oder große Lease-Datenbank – Log beobachten; Zeitabweichung zwischen den Firewalls per NTP beheben. |
| Clients erhalten nach Failover falsches Gateway/DNS | Auto collect option data aktiv bzw. Routers/DNS nicht auf die CARP-Adresse gesetzt. |
| Reservierung greift nicht | Client meldet sich mit Client-ID statt MAC – Client-ID eintragen oder Match client-id im Subnetz deaktivieren. |
| Pool läuft voll | Lease-Dauer verkürzen, Pool vergrößern, Leases unter Leases DHCPv4 prüfen und einzelne Leases löschen. |
| DDNS-Einträge fehlen | DDNS Agent aus, TSIG falsch, Zone nimmt keine Updates an oder Client sendet keinen Hostnamen. |
Fazit
Kea DHCP ist auf OPNsense die richtige Wahl, wenn DHCP ausfallsicher sein muss: Im hot-standby-Modus synchronisieren zwei Firewalls jede Lease, und der Standby übernimmt nach rund einer Minute automatisch – ohne geteilte Pools. Entscheidend sind wenige Details: Control Agent aktivieren, Peers mit eigenem Port und physischen Adressen, Gateway und DNS auf die CARP-Adresse und Auto collect option data aus. Für kleinere Netze ohne HA-Anforderung bleibt Dnsmasq die einfachere Alternative.
Unterstützung von m.a.x. it
Sie planen einen hochverfügbaren OPNsense-Cluster mit ausfallsicherem DHCP oder möchten von ISC-DHCP auf Kea umsteigen? m.a.x. it unterstützt Sie als OPNsense-Gold-Partner mit OPNsense-Firewall-Services von m.a.x. it und einer Managed Firewall von m.a.x. it.
Siehe auch
- OPNsense - Hochverfügbarkeit mit CARP und pfsync
- DHCP
- OPNsense - Dnsmasq DHCP-Server
- OPNsense - Unbound DNS Resolver
- OPNsense - Eine kurze Einführung
- OPNsense - Wazuh-Agent
- OPNsense - Zabbix-Agent
Links und Quellen
- OPNsense-Doku – Kea DHCP
- Kea-Handbuch – Hook-Bibliotheken (u. a. High Availability)
- ISC – Kea DHCP
- m.a.x. it – OPNsense-Firewall-Services
Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung?
