Messages

[KEA DHCPv4 will not change client from a dynamic IP to new static IP]

KEA DHCPv4 will not change client from a dynamic IP to new static IP
The client keeps getting given a dynamic IP address that OPNsense calls "static" when its's not.


I have two esp32 devices, both joined the wireless network and OPNsense is the DHCP server using Kea.
I have 2 x static IP addresses setup, with the correct client MAC address and outside the dynamic range of the 10.220.220.0/24 scope 50-150 (10.220.220.162 & .163)

I've deleted the current leased addresses as given out, (10.220.220.5x something) and rebooted OPNsense. I reboot the esp32 devices and they keep getting a .5x address which under DHCP leases strangely is listed as a "static" address (which it's not, .5x is in the dynamic range).

This happened on 26.7.7_1 and now also on 26.7.2

I cannot get these clients to change to pickup a new assigned static IP address. There is nothing on .162 nor .163, arp shows these addresses as empty.

Code Select Expand

Warning
kea-dhcp4
WARN [kea-dhcp4.alloc-engine.0x3c4c2b483010] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT [hwtype=1 b8:1f:3f:fe:2d:74], cid=[01:b8:1f:3f:fe:2d:74], tid=0x49607173: conflicting reservation for address 10.220.220.163 with existing lease Address: 10.220.220.163
Remote ID: (none)
Relay ID: (none)
State: default
Pool ID: 0
Subnet ID: 1
Client id: (none)
Hardware addr: 8c:53:e6:33:d4:b2
Cltt: 1786580276
Valid life: 28800
2026-08-13T18:47:44
Warning
kea-dhcp4
WARN [kea-dhcp4.alloc-engine.0x3c4c2b483010] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT [hwtype=1 b8:1f:3f:fe:03:cc], cid=[01:b8:1f:3f:fe:03:cc], tid=0xb055b682: conflicting reservation for address 10.220.220.162 with existing lease Address: 10.220.220.162

Tried adding in System > Settings > Tuneables

• ichwd_load="YES"
• watchdogd_enable="YES"

Also ensured Intel hardware TCO watchdog is enabled in the BIOS

Reboot (and even cold reboot)

But

Code Select Expand

dmesg | grep ichwd returns no results from CLI.
Appears ichwd is not loading

Looking at the developers GitHub, it looks like floating rules are going to be deprecated.

I for one, can't actually see a use case for floating rules that firewall interface groups doesn't cover.
I also like how you can add and subtract interfaces to an interface group, set the interface group sequence (aka rule order processing).

With floating rules, to now add WAN3 you needed to edit every rule to now work against WAN, WAN2 and WAN3 as opposed to simply adding WAN3 to WANgroup (firewall group).

[Final suggestion]

Ok!

After looking at the GitHub ticket, and creating an interface group "WANgroup" with a single WAN interface in this group (in my home config anyway) - I get the desired behaviour;

>>>> interface group rules are processed before the interface rules <<<<

I therefore cannot think of a use case for floating rules.

Thanks Patrick M. Hausen - a single interface group does indeed do the trick. It wasn't hard at all to modify each rule and simple unselect the single interface "WAN and select "WANgroup" to move the rule one by one to the new interface group called "WANgroup".


Final suggestion
Update the release notes for 26.1 and provide a bit more guidance about floating rules - recommendation to migrate these to Interface Groups and also explain that a floating rule that only has a single interface in the old rules will be migrated under new rules to appear under that single interface (and not in floating rules).

[However - this is a significant behavior change]

I see what happened.

Because my floating rules only have a single interface referenced, they were migrated to the appropriate interface as LAN or WAN etc interface rules.

However - this is a significant behavior change
The reason I use these rules on floating, is to ensure these block rules are always processed before interface rules. That way, special rules like Spamhaus DROP are always processed before the WAN interface rules. I can reorder WAN rules without fear of accidentally undoing special block rules.

OPNsense firewall processing order (in part):
 1. Floating rules first
 2. Interface rules second

Lastly, if I then add a 2nd WAN later on, it's very easy with a floating rule to have these block rules apply to WAN and WAN2, etc.

Ok!

Working this morning after leaving it overnight.

Utterly no idea why. I rebooted multiple times both the remote and the main site firewall and yet I could not ping from main site to remote site the wg tunnel interface IP. Yet, after waiting overnight, it's working....


Very strange.

One site was working fine.

Main site:
WAN 202.202.202.202 (made up)
WG listens on 202.202.202.202 port 51820
tunnel IP for peer: 10.100.100.1/24

Remote site:
WAN DHCP / not static
tunnel IP for main site peer 10.100.100.2/24

It was all working fine:
I could ping 10.100.100.2 from main site...  all good!

Upgrade remote site 25.7.8... post reboot it came up, tunnel address answered about 5 pings and then gone.

Looks related to 27.7.8, main site and now remote sites all running 25.7.78 and multiple reboots but cannot ping wg tunnel addresses anymore.

• I have a bunch of firewalls I support which have dynamic IP.
• The main site (hub and spoke) has a static IP.
• The remote sites all make wg tunnels from remote to main site

.

I can no longer ping the remote site wg tunnel IP, and, I used to be able to. It's making a wg tunnel fine.
I can ping just fine any other wg VPN site to site tunnel IP where the other site has a static WAN IP.

Just wg to wg using the tunnel IP, it no longer works IF the remote side peer does not have a static WAN IP and port.

Error on attempting to remove IPv6 from LAN interface:

Code Select Expand

The following input errors were detected:

    The DHCPv6 Server is active on this interface and it can be used only with a static IPv6 configuration. Please disable the DHCPv6 Server service on this interface first, then change the interface configuration.
But it's not active.

I have disabled IPv6 completely. I use KEA for IPv4, no IPv6 on the WAN interface at all, and  "ISC DHCPv6" shows a lan interface with "Enable DHCPv6 server on LAN interface" not selected.

Kea DHCPv6 is disabled.
I have rebooted multiple times.

[Outbound static NAT]

I too run Plex.
I have two NAT's one for static NAT outbound and one for the incoming NAT (aka Port Forward).
I have a static WAN address assigned by my ISP.

Outbound static NAT

• I have my firewall NAT outbound in Hybrid mode.
  Firewall > NAT > Outbound
• I have added a manual static IP address for my Plex server (say 192.168.1.88)
• I have a static outbound NAT for Plex.

**** Like this ****
Interface: WAN
Source: 192.168.1.88 (my Plex server LAN IP address)
Destination: *
Destination Port: *
NAT Address: Interface Address
NAT Port: *
Static Port: YES
Description: Static NAT for Plex Out

Inbound port forward NAT

• Firewall > NAT > Port Forward
• I have added a port forward for me Plex server (say 192.168.1.88)

**** Like this ****
Interface: WAN
Proto: TCP
Address: *
Ports: *
Address: This Firewall
Ports: the static port number you set inside Plex, typically 32400
IP: 192.168.1.88 (my Plex server LAN IP address)
Ports: the static port number you set inside Plex, typically 32400, the same as the first "Ports"
NAT Address: Interface Address
Description: WAN to Plex IN


This works for me great! I do not used "One-to-One" NAT at all.

Renamed a "Network(s)" alias, didn't add or subtract any content, just renamed the alias.

Firewall rules in multiple interfaces using the alias failed to update to the new alias name thereby breaking the firewall rules.
Renamed a second alias and observed the same behavior.

[What is the Intel TCO Watchdog Timer]

I am running OPNsense on an ODroid-H4 and it works great. The H4 BIOS supports the The Intel TCO (Total Cost of Ownership) Watchdog Timer.

What is the Intel TCO Watchdog Timer
This is a hardware watchdog in the chipset and BIOS of the computer whose purpose is to reboot the computer if the system hangs. If the hardware watchdog does not receive a ping at a regular interval it will cause a hardware reset. To work, the software must run a software Watchdog daemon which regularly writes to the ACPI hardware tables. In this way, if the OS hangs then there is no update to the tables, the hardware watchdog sees this and reboots the computer.

I see there is support in FreeBSD for the Intel TCO Watchdog Timer, the "ichwd" driver.

The Intel TCO Watchdog Timer is not just ODROID-H4 specific, but many Intel based systems support this.


Feature Request
Add a package that enables support for the Intel TCO Watchdog Timer.

I image it would have a few simple settings that could be set:

• watchdog-timeout = 14
• realtime = yes

Plus the ability to:

• View watchdog logs

Reference
ODroid-H4 Intel TCO Watchdog on Linux/Ubuntu
FreeBSD - ichwd --   device driver for the Intel ICH   watchdog interrupt timer

[I had the same error - fixed by resetting DNS data]

I had the same error - fixed by resetting DNS data

• Reporting > Settings > Unbound DNS reporting "Reset DNS data"

Then do the upgrade again - worked flawlessly.

To close off this topic:

Since OPNsense 23.7.8 and beyond with the built-in support of WireGuard to follow a CARP VHID, this issue and others have all been solved.

There's no longer any need to run custom scripts etc and WireGuard now works very well indeed!

[Why so much trouble with stacked switches?]

My experience is that many switches do not handle CARP / VRRP correctly across "stacked" switches.

You can tell if you've got that problem, because, you get all sorts of weird  CARP issues occurring such as:

• MASTER or BACKUP firewall failing and disabling CARP due a a CARP problem
• CARP won't fail back
• CARP gets a huge demotion level number of 240 or 480 or higher
• Sometimes it works and sometimes it doesn't and you just can't figure out why
• You reboot the master or backup firewall and strange CARP issues occur
• Both the master and backup firewall report themselves as the CARP master (which should be impossible)

Check here to see the CARP demotion level number:
   Interfaces: Virtual IPs: Status

Ask the switch manufacturer if they properly support VRRP which is basically what CARP is. If you tell them your trying to run CARP they will say "What?????" and won't know what your talking about.

Even then, what you want is a switch stack that supports external VRRP / CARP, that is, not that the switch stack itself supports VRRP, but, that is supports another VRRP plugged into it. In our case firewall1 and firewall2 but it could be server1 and server2 share an IP address using VRRP (which is essentially CARP).

If they do support external VRRP then CARP will work.

Often I have found it simpler to have:

     Firewall1 > switch1
     Firewall2 > switch2
     Switch1 and switch2 cross connect as standalone switches and thus CARP behaves nicely.


Why so much trouble with stacked switches?
Because it's actually really complicated for the switch manufacturer. They have to maintain an ARP states across 2 switches and replicate certain things switch to switch and the whole time lie and pretend to be a single switch. CARP/VRRP complicates things because of the technical way it shares an IP address across two devices and the fact that VRRP / CARP are protocol 112 and not UDP (protocol number 17) and not TCP (protocol number 6).

I have found they work hard on getting stacked switches to work covering most stuff, but not things like VRRP / CARP.

I know I haven't cured the problem but hopefully my explanation helps it all make sense as to why sometimes you just can't get it to go.