Kea-DHCP Feature Requests #9418
Description
name: Feature request
about: Suggest an idea for OPNsense
title: 'Kea DHCP: Enable shared networks for DHCPv4 and DHCPv6'
labels: ''
assignees: ''
Important notices
Before you add a new report, we ask you kindly to acknowledge the following:
- I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
- I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue
Is your feature request related to a problem? Please describe.
For the purpose of providing IPv6 ULA addressing to internal networks (media, iot, lan, net, etc.) and also allow for dynamic GUA addressing /prefix-delegation from my ISP (Cox Business), I would like to be able to set /configure the Kea-DHCP capability to use shared network configuration.
This will compliment Kea: Add DHCP-DDNS Support but does require moving some of the ddns configuration options into the shared network configuration area.
It will also require moving reservations and option-data into the shared subnet configuration.
By using shared networks on an interface, instead of multiple separate networks, the Kea-DHCP server will offer addresses from all shared networks - and then using DDNS will register those assigned addresses in the configured DNS server (if enabled /set up) and/ or track them in the appropriate leases file.
The configuration and options for shared networks are identical between DHCPv4 and DHCPv6 in the Kea-DHCP platform.
I prefer using the OpnSense platform for DHCPv6 since in my experience ISP's for the independent /SMB sector don't permanently delegate a PD unless you pay them $$$$$.
So PD's can (and have) changed when one or more things happen:
- ISP equipment upgrades (CO or distribution point)
- CPE equipment upgrades or changes
- CPE reboots
- CO /plant maintenance by the ISP
- Weather interruptions (physical plant failure inline)
- Whenever the ISP CO Engineer resets or reboots the POP (or the blade on the POP...)
Using the built-in OpnSense tooling to accommodate for the semi-regular changes is useful in reducing management and administration overhead.
Describe the solution you like
Testing internally, I was successful in setting:
"interfaces-config": {
"interfaces": [
"rge1",
"rge1.1"
]
at the global level for interfaces in both kea-dhcp4 and kea-dhcp6 to account for VLANs.
From my kea-dhcp6 configuration file (dhcp4 and dhcp6 are identical in this manner):
"shared-networks": [
{
"name": "lan",
"ddns-qualifying-suffix": "lan.internal.",
"ddns-generated-prefix": "lan",
"reservations-global": false,
"reservations-in-subnet": true,
"subnet6": [
{
"id": 1,
"ddns-replace-client-name": "when-not-present",
"interface": "rge1",
"subnet": "2001::/64",
"pools": [
{
"pool": "2001::1-2001::ffff"
}
],
"reservations": [
{
"hw-address": "00:e0:67:1f:25:29",
"hostname": "opnsense.lan.internal",
"ip-addresses": [
"2001::2529"
]
}
]
},
{
"id": 3,
"ddns-replace-client-name": "always",
"interface": "rge1",
"subnet": "fde4:b3e2:db9e:1000::/64",
"pools": [
{
"pool": "fde4:b3e2:db9e:1000::1-fde4:b3e2:db9e:1000::ffff"
}
],
"option-data": [
{
"name": "dns-servers",
"code": 23,
"space": "dhcp6",
"csv-format": true,
"data": "fde4:b3e2:db9e:1000::11, fde4:b3e2:db9e:1000::15",
"always-send": true
},
{
"name": "domain-search",
"code": 24,
"space": "dhcp6",
"csv-format": true,
"data": "lan.internal",
"always-send": true
},
{
"name": "sntp-servers",
"code": 31,
"space": "dhcp6",
"csv-format": true,
"data": "fde4:b3e2:db9e:1000::15",
"always-send": true
}
],
"reservations": [
{
"hw-address": "00:e0:67:1f:25:29",
"hostname": "opnsense.lan.internal",
"ip-addresses": [
"fde4:b3e2:db9e:1000::1"
]
}
]
}
]
}
]
The above can be repeated, substituting "iot" (or "guest", or "whatever") for "lan" with suitably different interface, CIDRs and so on.
I found that global ddns settings worked best as:
"dhcp-ddns": {
"enable-updates": true,
"server-ip": "127.0.0.1",
"server-port": 53001,
"sender-ip": "192.168.144.13"
},
"ddns-send-updates": true,
"ddns-override-no-update": true,
"ddns-conflict-resolution-mode": "check-with-dhcid",
"hostname-char-set": "[^A-Za-z0-9.-]",
"hostname-char-replacement": "x",
The ddns settings which I found appropriate and useful to move into the "per-shared-network" configuration block are:
- ddns-replace-client-name
- ddns-generated-prefix
- ddns-qualifying-suffix
These can also be set at the global level, but since they can be different per network, work best at the network level as they impact what DHCP-DDNS sends as an update.
Shared network configurations work with just one network defined function as a single network - multiple entries are not required.
Additional context
Although my primary use-case is IPv6, I did test with IPv4 and using equivalent settings was able to successfully issue multiple IPs and register both A and PTR records in DNS for multiple subnets.