Messages

Thank you for that link "ONT" is a new TLA for me, so my searching wouldn't have found it...

New update, new rules - I'm up and running.

Previously working in v25.* series OpnSense.

Internal LAN is 192.168.144.0/24
The ISP modem is connected to the WAN port (bridge mode) and is hard-coded to use 192.168.100.1 for it's WebUI, allowing connection only from the 192.168.100.0/24 network.

In the v25 releases I had a NAT "Outbound" rule that masked any traffic from the LAN destined for the ISP Modem to use 192.168.100.100 (any source /destination ports).

That NAT stopped working when I upgraded to v26, but I recalled that when I went from v24 to v25 the same thing happened and it required deleting and rebuilding the NAT rule.

So I rebuilt again, with no luck.

I also tried a "Source NAT" rule - again, no dice.

I cannot reach the ISP Modem WebUI (though oddly, it is ICMP pingable...), even though in the logs it _looks_ like the NAT is applying and traffic is passing:

Code Select Expand

$ ping -c 5 192.168.100.1
PING 192.168.100.1 (192.168.100.1): 56 data bytes
64 bytes from 192.168.100.1: icmp_seq=0 ttl=63 time=1.451 ms
64 bytes from 192.168.100.1: icmp_seq=1 ttl=63 time=1.921 ms
64 bytes from 192.168.100.1: icmp_seq=2 ttl=63 time=2.084 ms
64 bytes from 192.168.100.1: icmp_seq=3 ttl=63 time=1.313 ms
64 bytes from 192.168.100.1: icmp_seq=4 ttl=63 time=1.402 ms

--- 192.168.100.1 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 1.313/1.634/2.084/0.308 ms

$ nc -zv 192.168.100.1 80
nc: connect to 192.168.100.1 port 80 (tcp) failed: Operation timed out

WAN Out 2026-02-06T12:12:14-06:00 TCP 192.168.100.100:38311 192.168.100.1:80 pass let out anything from firewall host itself
WAN Out 2026-02-06T12:12:14-06:00 TCP 192.168.144.17:35649 192.168.100.1:80 nat nat rule
WAN Out 2026-02-06T12:12:06-06:00 ICMP 192.168.100.100 192.168.100.1 pass let out anything from firewall host itself
WAN Out 2026-02-06T12:12:06-06:00 ICMP 192.168.144.17 192.168.100.1 nat nat rule
WAN Out 2026-02-06T12:11:51-06:00 TCP 192.168.100.100:64757 192.168.100.1:80 pass let out anything from firewall host itself
WAN Out 2026-02-06T12:11:51-06:00 TCP 192.168.144.17:24923 192.168.100.1:80 nat nat rule
Any suggestions on what to try next?  Did I miss something in the new v26 NAT documentation?

I completely re-created the FR as Feature Request: Kea DHCP: Enable shared networks for DHCPv4 and DHCPv6, a sanity check would be appreciated if time permits...

Thank you.

I did receive an email from the core "auto-responder" - apparently my feature request used the wrong template?

There was a help link about policies, but it wasn't much help (or I am running on too little sleep and too much caffeine to fully comprehend what I need to change...).

Any clue-by-fours you can swing my direction?

https://github.com/opnsense/ports/issues/243

Has been submitted - though it appears that the project has been idle since August?

Is there a new /different Git repo where I should have dropped the request?

Like all software, best to assume it's safe to use unless and until you hear about a CVE.

Isn't that backwards?  I tend to presume all software is unsafe until proven otherwise...

My initial thread seems to have been re-purposed for troubleshooting, so a new thread for new data...

I've been testing Kea-DHCP v3.0.2 on a separate FreeBSD box and from that testing I can state:

* Shared Networks works as expected in assigning both GUA and ULA addresses from the configured pools, for the primary "lan" interface and an aliased "vlan01" interface on the same hardware port
  - IPv6 traffic on both GUA and ULA networks from client systems to the Public Internet works
* Data flows to both the "lan" subnet and to the "vlan01" subnet internally with no crossover
* DDNS in both IPv4 and IPv6 works as expected, updating my internal "master" DNS server with IPv4 and both the GUA and ULA IPv6s
  - A, AAAA in the "lan.internal" and "iot.internal" TLDs and PTR records in the right .ip6.arpa /in-addr.arpa zones
  - Using either the "always" or the "when-not-present" flag
* Shared Networks configuration works with just one network /range /pool defined, so it should be possible to use as a default for all networks
  - I don't have access to a full test rack /setup so I cannot be definitive for a broader scope

So it appears (at least locally) that allowing Shared Subnets and DDNS updates in the Kea-DHCP config would work...

And I would prefer to have it running on the OpnSense system, since that's also where radvd and the other upstream "find my PD and populate addresses" scripts are set to run.

Any hope to put this on the roadmap /PoA&M?

Related to: Feature Requst: KEA DHCPv6 "shared subnets"

As an alternative to official "shared subnets" support, is there a way to "pass-through" the IPv6 subnet delegation from my ISP (Cox Cable) to a standalone Kea DHCP server?

The Kea "readthedocs" site infers that such is possible, but doesn't give any specifics or details - saying it's up to the "router vendor".

I did some keyword searching in the OpnSense docs along with "Dr. Google", but nothing useful turned up other than some confusion regarding PD pools and subrouters (none of which was very clear - most posts said something like "after I played around with it for a while..." but gave no details).

Any thoughts, help, links to good docs, etc.?

Correct on DNS hostname registration.

I'm not sure on the SLAAC part, but testing (which left things kinda weird) using PiHole DHCPv6 for private and OpnSense for Public, I was able to pull SLAAC from OpnSense for Public IPs, and also get valid DHCPv6 for my internal subnet.

Since PiHole uses dnsmasq for pretty much everything including DHCP, it is not capable of performing TSIG updates from it's own internal database (flatfile).

I have found that enabling 'kea-dhcp_ddns' works (as long as I re-enable after updates or reboots, since again it reverts any .conf changes "automagickally") and pushes data to my internal DNS master for A, AAAA and PTR records.

My desired outcome is to have Kea DHCPv4 and v6 running on OpnSense, then use DHCP-DDNS to send dynamic assignment updates to the DNS master server.

I'd even accept running Unbound on the OpnSense if the any of the DHCP flavors (Kea, ISC, dnsmasq) were capable of shared networks - as long as it would push DDNS to my internal DNS master.

Oh, I'm familiar with your write-up - that's how I got IPv6 working at the start of things.

But the "variability" of the public IP space lead me down the path of using an internal private space (fde4:b3e2:db9e:: in this case) so that my internal PiHole servers, NAS boxes, and so on will have at least one "static" IP.  Yes, they end up with additional IPs based on need, but they always have one outside of the pool that is attached to their network adapter.

Poking around a bit on the Kea DHCP mailing list, my situation is not uncommon.

In fact, it's so common that Kea built a specific method to accommodate the need (shared networks for IPv6).

There are several Rube Goldberg-ish solutions to running my own internal Kea (or ISC, or PiHole) DHCP platform, but I'd rather have it all live in the same place (OpnSense) as the interface tracking to update the dynamic Public IPs makes things much easier.

I can set up and validate a .conf file, but even doing manual configuration fails since something in the OpnSense platform "nukes" the config on restart.

Thus the request that "shared networks" be made available...

Kea DHCP does have a provision for what are known as "shared networks".

Kea Doc Examples

My use case (which I cannot imagine is unique) is:

ISP that provides a "public" range of IPv6 (/56), which can (and does) change based on when the router/modem reboots.

The need for internal non-public IPv6 to point at NTP, DNS (PiHole) and so on, since the ISP assigned addresses change and there is no graceful or smooth way to re-publish service related addresses that I have found (yet - I'm willing to be wrong).

The configuration looks straightforward in the example document, so maybe a dropdown or somewhere in the "Advanced" options?

Second vote for `kea-dhcp-ddns`.

I can enable it once the firewall is up, but it disables itself on every reboot, overwriting the .conf file that should allow it to run.

Oddly, it does not reset the `kea-dhcp-ddns.conf` file, that stays and it works once I re-enable in the master .conf.

Currently running v25.1.1 upgraded from v25.1

When on v25.1 (pre-upgrade), IPv6 was working via the "Track Interface" mechanism on the WAN (igb0) interface.

Settings are the same as used in the v24 production series, which also worked.

The behavior (pre-upgrade) was:

Request a /56 allocation from Cox
Deploy the /56 as a /64 to:
LAN (igb1) with prefix "0"
IoT (opt1) with prefix "1"

With the 25.1.1 upgrade, this does not seem to work any more.

The log is filled with messages like:

Code Select Expand

RDNSS address 2001:579:4c:3700:a434:9a73:b10d:e091 received on igb1 from fe80::53bb:1ff4:f59c:40b3 is not advertised by us
AdvPreferredLifetime on igb1 for 2001:579:4c:3700:: doesn't agree with fe80::53bb:1ff4:f59c:40b3
AdvValidLifetime on igb1 for 2001:579:4c:3700:: doesn't agree with fe80::53bb:1ff4:f59c:40b3
I also spot that both internal interfaces (LAN and IoT, which are physical interfaces) end up with the same IPv6 address: 2001:579:4c:3700:2e0:67ff:fe1f:2529/64 which is apparently not a "reachable" address.

Rolling back to 25.1, IPv6 works as expected once again, internal systems are assigned IPv6 from the allocation, etc.

Not sure what else might be needed to troubleshoot /debug, but I'm game to deliver as requested...

[UN]

I had spotted the other thread, but when I checked the file I found:

Code Select Expand

# grep offloading /conf/config.xml
    <disablechecksumoffloading>1</disablechecksumoffloading>
    <disablesegmentationoffloading>1</disablesegmentationoffloading>
    <disablelargereceiveoffloading>1</disablelargereceiveoffloading>

The natives were getting restless in the household, so I girded my loins and moved the `eastpect` file out of `/usr/local/etc/rc.d`.

That worked and the WebUI came up on reboot.

Oddly, when I checked the system config I noticed that all the "offload" boxes were UNchecked.

Moving the `eastpect` file back where it started and rebooting worked as I would have expected before this evolution.  WebUI, SSH, etc. working.

Checking those boxes didn't change anything in the `/conf/config.xml` file, so maybe that's controlled /set somewhere else these days?

At any rate, I'm back up and running and managed to remove Zenarmor (it didn't work since it's missing the database).

Thanks for the pointers, it got me moving (even if I had a flop-sweat moment moving files around).

Not sure if anyone can help, but I screwed up and thought I'd try Zenarmor.

Unfortunately, I didn't read far enough into the "gotchas" to discover that turning on checksum offloading is a "Bad Idea (tm)" with Zenarmor.

Now my firewall is stuck with no WebUI, no SSH and no Serial/TTY console (spamming the "drop mbuf that needs checksum offload" message).

I built a NomadBSD USB and can mount up the correct partition - but can't find where the config files live to either:

1) Turn checksum offload "Off"
-or-
2) Disable Zenarmor so the WebUI starts and I can change the checksum offload there

Can anyone point me in the right direction?

Or have I just blown up my firewall and need to re-image from bare metal?