Bottom line: Review the configuration copied to the standby separately from the lease behavior expected during an outage. Make both server identities and the client-facing gateway and DNS values explicit before scheduling an HA exercise.
\nThe OPNsense KEA guide requires the Control Agent for HA and says it can remain bound to loopback because HA communication uses a separate listener by default. Its peer definitions must match on all nodes, normally identifying primary and standby servers. In the DHCPv4 HA example, automatic option collection is unchecked and the router and DNS options explicitly use the LAN CARP address. The example enables KEA in services to synchronize, then synchronizes and reconfigures the pair, making KEA active on both with bidirectional lease synchronization.
\nThese statements concern the source’s DHCPv4 HA example, not an assertion that an existing pair has correct lease service. They do not establish a tested outage duration or authorize applying the example addresses to another network.
\nThe following steps are DSE recommendations based on the cited source.
\nDSE recommends separate configuration and lease-service checklists. On the configuration sheet, record each peer’s own address, role and communication endpoint alongside the shared client-facing values. Preserve both exports before synchronization and identify which node is the approved configuration authority.
\nReview the source example’s explicit option values against the real subnet design. Have the network owner verify the chosen gateway and DNS service. Do not accept matching peer configuration if both peers contain an incorrect client-facing address.
\nPlan a proposed controlled allocation test using one new test client and one renewing test client on an approved segment. Write the expected address range and client options before the run. Keep an eventual partner-loss exercise separate from the initial configuration comparison.
\nTreat a discrepancy between peers as a reason to stop and reconcile direction and authority before synchronizing again. Record which configuration was intended to win and why. Do not use a broad production client release as a convenient way to generate the test traffic.
\nProposed verification: inspect both effective peer definitions and subnet options, then compare test-client leases and returned gateway and DNS values. Preserve the observation time and responding server evidence available through the supported tooling. Confirm lease exchange independently of the configuration-copy action.
\nIf partner loss is separately approved, observe both renewal and new allocation during that bounded exercise, then reconcile the recovered pair before closing it. Retain actual timings as observations rather than a promised failover target. Keep any DNS integration review outside this article’s narrower DHCPv4 HA acceptance.
\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "Bottom line: Review the configuration copied to the standby separately from the lease behavior expected during an outage. Make both server identities and the client-facing gateway and DNS values explicit before scheduling an HA exercise.\nSource fact: what the authority says\nThe OPNsense KEA guide requires the Control Agent for HA and says it can remain bound to loopback because HA communication uses a separate listener by default. Its peer definitions must match on all nodes, normally identifying primary and standby servers. In the DHCPv4 HA example, automatic option collection is unchecked and the router and DNS options explicitly use the LAN CARP address. The example enables KEA in services to synchronize, then synchronizes and reconfigures the pair, making KEA active on both with bidirectional lease synchronization.\nWhat the source does not establish\nThese statements concern the source’s DHCPv4 HA example, not an assertion that an existing pair has correct lease service. They do not establish a tested outage duration or authorize applying the example addresses to another network.\nApplicability questions\n\nDo both servers have the intended names and identical HA peer definitions?\nWhich actual CARP address should clients receive as their gateway and DNS server?\nIs KEA selected for configuration synchronization through the intended master?\nWhat observations will distinguish copied settings from actual lease exchange and client service?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends separate configuration and lease-service checklists. On the configuration sheet, record each peer’s own address, role and communication endpoint alongside the shared client-facing values. Preserve both exports before synchronization and identify which node is the approved configuration authority.\nReview the source example’s explicit option values against the real subnet design. Have the network owner verify the chosen gateway and DNS service. Do not accept matching peer configuration if both peers contain an incorrect client-facing address.\nPlan a proposed controlled allocation test using one new test client and one renewing test client on an approved segment. Write the expected address range and client options before the run. Keep an eventual partner-loss exercise separate from the initial configuration comparison.\nTreat a discrepancy between peers as a reason to stop and reconcile direction and authority before synchronizing again. Record which configuration was intended to win and why. Do not use a broad production client release as a convenient way to generate the test traffic.\nVerification and evidence\nProposed verification: inspect both effective peer definitions and subnet options, then compare test-client leases and returned gateway and DNS values. Preserve the observation time and responding server evidence available through the supported tooling. Confirm lease exchange independently of the configuration-copy action.\nIf partner loss is separately approved, observe both renewal and new allocation during that bounded exercise, then reconcile the recovered pair before closing it. Retain actual timings as observations rather than a promised failover target. Keep any DNS integration review outside this article’s narrower DHCPv4 HA acceptance.\nOfficial references\n\nOPNsense — KEA DHCP — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "Bottom line: Review the configuration copied to the standby separately from the lease behavior expected during an outage. Make both server identities and the client-facing gateway and DNS values explicit before scheduling an HA exercise.\n\n## Source fact: what the authority says\n\nThe [OPNsense KEA guide](https://docs.opnsense.org/manual/kea.html) requires the Control Agent for HA and says it can remain bound to loopback because HA communication uses a separate listener by default. Its peer definitions must match on all nodes, normally identifying primary and standby servers. In the DHCPv4 HA example, automatic option collection is unchecked and the router and DNS options explicitly use the LAN CARP address. The example enables KEA in services to synchronize, then synchronizes and reconfigures the pair, making KEA active on both with bidirectional lease synchronization.\n\n## What the source does not establish\n\nThese statements concern the source’s DHCPv4 HA example, not an assertion that an existing pair has correct lease service. They do not establish a tested outage duration or authorize applying the example addresses to another network.\n\n## Applicability questions\n\n- Do both servers have the intended names and identical HA peer definitions?\n\n- Which actual CARP address should clients receive as their gateway and DNS server?\n\n- Is KEA selected for configuration synchronization through the intended master?\n\n- What observations will distinguish copied settings from actual lease exchange and client service?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE recommends separate configuration and lease-service checklists. On the configuration sheet, record each peer’s own address, role and communication endpoint alongside the shared client-facing values. Preserve both exports before synchronization and identify which node is the approved configuration authority.\n\nReview the source example’s explicit option values against the real subnet design. Have the network owner verify the chosen gateway and DNS service. Do not accept matching peer configuration if both peers contain an incorrect client-facing address.\n\nPlan a proposed controlled allocation test using one new test client and one renewing test client on an approved segment. Write the expected address range and client options before the run. Keep an eventual partner-loss exercise separate from the initial configuration comparison.\n\nTreat a discrepancy between peers as a reason to stop and reconcile direction and authority before synchronizing again. Record which configuration was intended to win and why. Do not use a broad production client release as a convenient way to generate the test traffic.\n\n## Verification and evidence\n\nProposed verification: inspect both effective peer definitions and subnet options, then compare test-client leases and returned gateway and DNS values. Preserve the observation time and responding server evidence available through the supported tooling. Confirm lease exchange independently of the configuration-copy action.\n\nIf partner loss is separately approved, observe both renewal and new allocation during that bounded exercise, then reconcile the recovered pair before closing it. Retain actual timings as observations rather than a promised failover target. Keep any DNS integration review outside this article’s narrower DHCPv4 HA acceptance.\n\n## Official references\n\n- [OPNsense — KEA DHCP](https://docs.opnsense.org/manual/kea.html) — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/separate-opnsense-kea-configuration-sync-from-lease-failover/", "url": "https://update.dsesecurity.com/updates/separate-opnsense-kea-configuration-sync-from-lease-failover/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-29" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/separate-opnsense-kea-configuration-sync-from-lease-failover/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Business Continuity", "item": "https://update.dsesecurity.com/topic/business-continuity/" }, { "@type": "ListItem", "position": 3, "name": "Separate OPNsense KEA configuration sync from lease failover", "item": "https://update.dsesecurity.com/updates/separate-opnsense-kea-configuration-sync-from-lease-failover/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/separate-opnsense-kea-configuration-sync-from-lease-failover/#article", "identifier": "https://update.dsesecurity.com/updates/separate-opnsense-kea-configuration-sync-from-lease-failover/", "url": "https://update.dsesecurity.com/updates/separate-opnsense-kea-configuration-sync-from-lease-failover/", "headline": "Separate OPNsense KEA configuration sync from lease failover", "description": "Review peer configuration, explicit CARP option values and bidirectional lease exchange as separate parts of the documented KEA DHCPv4 HA example.", "abstract": "Review peer configuration, explicit CARP option values and bidirectional lease exchange as separate parts of the documented KEA DHCPv4 HA example.", "articleBody": "Bottom line: Review the configuration copied to the standby separately from the lease behavior expected during an outage. Make both server identities and the client-facing gateway and DNS values explicit before scheduling an HA exercise.\nSource fact: what the authority says\nThe OPNsense KEA guide requires the Control Agent for HA and says it can remain bound to loopback because HA communication uses a separate listener by default. Its peer definitions must match on all nodes, normally identifying primary and standby servers. In the DHCPv4 HA example, automatic option collection is unchecked and the router and DNS options explicitly use the LAN CARP address. The example enables KEA in services to synchronize, then synchronizes and reconfigures the pair, making KEA active on both with bidirectional lease synchronization.\nWhat the source does not establish\nThese statements concern the source’s DHCPv4 HA example, not an assertion that an existing pair has correct lease service. They do not establish a tested outage duration or authorize applying the example addresses to another network.\nApplicability questions\n\nDo both servers have the intended names and identical HA peer definitions?\nWhich actual CARP address should clients receive as their gateway and DNS server?\nIs KEA selected for configuration synchronization through the intended master?\nWhat observations will distinguish copied settings from actual lease exchange and client service?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends separate configuration and lease-service checklists. On the configuration sheet, record each peer’s own address, role and communication endpoint alongside the shared client-facing values. Preserve both exports before synchronization and identify which node is the approved configuration authority.\nReview the source example’s explicit option values against the real subnet design. Have the network owner verify the chosen gateway and DNS service. Do not accept matching peer configuration if both peers contain an incorrect client-facing address.\nPlan a proposed controlled allocation test using one new test client and one renewing test client on an approved segment. Write the expected address range and client options before the run. Keep an eventual partner-loss exercise separate from the initial configuration comparison.\nTreat a discrepancy between peers as a reason to stop and reconcile direction and authority before synchronizing again. Record which configuration was intended to win and why. Do not use a broad production client release as a convenient way to generate the test traffic.\nVerification and evidence\nProposed verification: inspect both effective peer definitions and subnet options, then compare test-client leases and returned gateway and DNS values. Preserve the observation time and responding server evidence available through the supported tooling. Confirm lease exchange independently of the configuration-copy action.\nIf partner loss is separately approved, observe both renewal and new allocation during that bounded exercise, then reconcile the recovered pair before closing it. Retain actual timings as observations rather than a promised failover target. Keep any DNS integration review outside this article’s narrower DHCPv4 HA acceptance.\nOfficial references\n\nOPNsense — KEA DHCP — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-29T17:41:11+00:00", "dateModified": "2026-10-29T17:41:38+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/separate-opnsense-kea-configuration-sync-from-lease-failover/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/separate-opnsense-kea-configuration-sync-from-lease-failover/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Separate OPNsense KEA configuration sync from lease failover" }, "articleSection": [ "Business Continuity", "Networks & Infrastructure" ], "keywords": [ "Business Continuity", "Networks & Infrastructure", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 521, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "OPNsense — KEA DHCP", "url": "https://docs.opnsense.org/manual/kea.html" } } ] } }