imported>TechCorner-Redaktion: Verlinkung auf den Artikel OPNsense - Hochverfügbarkeit mit CARP und pfsync ergänzt

2026-10-08T00:00:00Z

Verlinkung auf den Artikel OPNsense - Hochverfügbarkeit mit CARP und pfsync ergänzt

Neue Seite

{{Steckbrief
| gilt_fuer = 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 [[OPNsense - Hochverfügbarkeit mit CARP und pfsync|CARP-Cluster]]''': Funktionsweise, Schritt-für-Schritt-Konfiguration, Failover-Zeiten, Tests und typische Fehler.

== Kea oder Dnsmasq? ==
Seit OPNsense 26.1 ist [[OPNsense - Dnsmasq DHCP-Server|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:
{| class="wikitable"
! 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
|}

[[Datei:OPNsense-Kea-DHCP-HA.png|thumb|center|750px|Kea DHCP im HA-Cluster: Die primäre OPNsense beantwortet die DHCP-Anfragen und überträgt jede Lease an den Standby-Partner; fällt sie aus, übernimmt der Standby nach spätestens rund 60 Sekunden. Gateway und DNS zeigen auf die CARP-Adresse.]]

== Menü und Bausteine ==
Unter '''Services → Kea DHCP''':
{| class="wikitable"
! 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
{{Hinweis|Auf derselben Schnittstelle darf nur ein DHCP-Server laufen. Vor der Aktivierung von Kea Dnsmasq-DHCP bzw. ISC-DHCP auf diesen Schnittstellen abschalten.}}

=== Subnetze ===
Reiter '''Subnets''' → '''+''':
{| class="wikitable"
! Feld !! Beispiel / Hinweis
|-
| Subnet || <code>192.168.1.0/24</code>
|-
| Pools || <code>192.168.1.100 - 192.168.1.199</code> (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. <code>192.168.1.1</code>
|-
| 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 <code>127.0.0.1</code> lauschen.

{{Hinweis|'''Kea HA ist unabhängig von CARP.''' Welche Firewall Kea-Primary ist, richtet sich nach der Rolle im Kea-Peer, nicht nach dem CARP-Status. Deshalb müssen '''Gateway und DNS-Server''' als Option immer auf die '''CARP-Adresse''' zeigen – und ''Auto collect option data'' muss aus sein, sonst erhält jeder Client die physische Adresse der Firewall, die ihn gerade bedient hat.}}

=== Beispiel-Szenario ===
{| class="wikitable"
! Eigenschaft !! Wert
|-
| LAN || <code>192.168.1.0/24</code>
|-
| CARP-Adresse LAN || <code>192.168.1.1</code>
|-
| Master (fw1) LAN || <code>192.168.1.2</code>
|-
| Backup (fw2) LAN || <code>192.168.1.3</code>
|-
| Pool || <code>192.168.1.100 - 192.168.1.199</code>
|}
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''' <code>127.0.0.1</code>, '''Bind port''' <code>8000</code> → ''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 <code>2</code>; mit <code>0</code> lö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'' <code>192.168.1.0/24</code>, ''Pools'' <code>192.168.1.100 - 192.168.1.199</code>, '''Auto collect option data''' '''aus''', '''Routers''' und '''DNS servers''' = <code>192.168.1.1</code> (CARP).

=== Schritt 4: HA Peers ===
Reiter '''HA Peers''', zwei Einträge (auf dem Master angelegt, gelten für beide Firewalls):
{| class="wikitable"
! Name !! Role !! Url
|-
| Hostname von fw1 (wie unter ''This server name'' angezeigt) || ''primary'' || <code><nowiki>http://192.168.1.2:8001/</nowiki></code>
|-
| Hostname von fw2 || ''standby'' || <code><nowiki>http://192.168.1.3:8001/</nowiki></code>
|}
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 <code>127.0.0.1</code>, Port <code>53001</code>).
# Im Subnetz die Felder ''DNS forward zone'' (z. B. <code>lan.internal.</code>), ''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 <code>127.0.0.1</code> binden; 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 [[OPNsense - Wazuh-Agent|Wazuh-Agent]] oder [[OPNsense - Zabbix-Agent|Zabbix]].

== Typische Probleme und Lösungen ==
{| class="wikitable"
! 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 [https://www.max-it.de/it-services/opnsense/ OPNsense-Firewall-Services von m.a.x. it] und einer [https://www.max-it.de/it-services/managed-firewall/ 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 ==
* [https://docs.opnsense.org/manual/kea.html OPNsense-Doku – Kea DHCP]
* [https://kea.readthedocs.io/en/latest/arm/hooks.html Kea-Handbuch – Hook-Bibliotheken (u. a. High Availability)]
* [https://www.isc.org/kea/ ISC – Kea DHCP]
* [https://www.max-it.de/it-services/opnsense/ m.a.x. it – OPNsense-Firewall-Services]

{{Uebermax}}
[[Kategorie:IT-Security]]

OPNsense - Kea DHCP mit Hochverfügbarkeit - Versionsgeschichte

imported>TechCorner-Redaktion: Verlinkung auf den Artikel OPNsense - Hochverfügbarkeit mit CARP und pfsync ergänzt