Merge pull request #9927 from agoodkind/agoodkind/captive-portal-ipv6-dual-stack-support
Follow up for dual-stack captive portal authorization in `CaptivePortal`
Services: Kea DHCP: Add DDNS feature for subnet4 and subnet6 (#9923)
* kea: WIP add dhcp-ddns daemon with forward zone support, goal is initial feature parity with what ISC had.
* Add a default for ddns_domain_algorithm inside the config generator
* The control socket is not needed right now. It would only be required to directly query the ddns server
* Some updates to ddns model and dialogs
* Update service controls via data_service_widget
* More terminology changes for ddns server ip and port
* It looks like a trailing dot validation is not necessary as the configuration is valid regardless, kea does not crash or log any error here
* Add constraints for key_name and key_secret to be used together, adjust some property names for clarity, extend ddns_domain_key_algorithm with all supported values per documentation
* Use single validation string
[39 lines not shown]
firewall: fix regression in 8554581eac so alias content summary is shown (#9929)
The "description" is a summary so change the underlying
code accordingly to avoid future misinterpretations.
PR: https://forum.opnsense.org/index.php?topic=51246.0
firewall: fix regression in 8554581eac so alias content summary is shown
The "description" is a summary so change the underlying
code accordingly to avoid future misinterpretations.
Warm-start captive portal roaming expansion.
This restores best-effort sibling address authorization at login for already-known addresses on the same MAC, while keeping the background reconciliation path as the source of truth for later convergence and cleanup.
Finish captive portal dual-stack authorization flow.
This makes IPv4 and IPv6 portal entry points behave consistently, fixes proxied client IP detection, and lets roaming sessions discover IPv6 addresses quickly enough to authorize privacy and secondary addresses on the same client.
interfaces: multi-dhcp6c support #7647
This splits off rtsold and dhcp6c into separate processes.
I'm not entirely sure why we settled for a single deamon of
dhcp6c back in the day, but there are certianly downsides to
it and I don't see something that wasn't fixed in the meantime
that makes this not work.