Recent posts

#1

26.1, 26,4 Series / Re: [closed] Unbound fails to ...

Last post by passeri - Today at 05:00:54 AM

Nor is it used to visit root servers (my case) which are not part of or listed in system nameservers. Given the addresses to which you finally connect are visible to an ISP, not to mention at the site itself, and I have a static IP, I do not consider DoT to provide any privacy of interest.

#2

26.1, 26,4 Series / Re: OPNsense 26.1.7-amd64 - Gu...

Last post by frade - Today at 03:25:26 AM

I've already tried your suggestions, using Edge, Chrome, and Firefox, and/or in private mode and with a clear cache... nothing solved this problem.

Thank you for your help.

#3

General Discussion / Re: OPNSense 26.1 installs but...

Last post by OPNenthu - Today at 03:16:33 AM

I don't think setting a static IP would cause a problem.  It's been a while since I did a fresh install but I think Dnsmasq is the default DHCP server now and as long as you took all the defaults during the installation and didn't change anything it should be set up already with a DHCP range for the 192.168.1.0/24 subnet.

During the installation the system might have asked you if you want to make manual interface changes or IP assignments.  I'm assuming you didn't.  In that case you should probably be seeing a screen like this:

https://docs.opnsense.org/manual/install.html#initial-configuration

Unfortunately you can't copy/paste because you're using VGA, but if you could take a picture or let us know what you see on the bootup screens maybe something will stand out.

The 'igc' driver for the i226V ports is very well supported in FreeBSD/OPNsense out of the box so at a bare minimum your LAN interface should be working, barring any problems with your hardware of course.

EDIT: You can replay the kernel messages with the "dmesg" command from the shell (menu option 8 when you log in as root).  Use "dmesg | more" to page your way through with the space bar.

#4

26.1, 26,4 Series / Re: OPNsense 26.1.7-amd64 - Gu...

Last post by lmoore - Today at 03:06:09 AM

After installing OPNsense version 26.1.7, users (including root) are unable to save changes through the GUI (e.g., comments, emails, etc.).

Edit: It doesn't show an error, but the Save button does nothing. There are no error logs in the GUI.

Can you help?

Some suggestions:

- Invalid character
- Clear your browser's cache
- Test using your browser in In-Private mode

#5

General Discussion / Re: OPNSense 26.1 installs but...

Last post by dooda - Today at 02:47:35 AM

@OPNenthu:  Thanks for the response.  I was unaware that the initial install would provide DHCP.  I was using statics in hope that it would make what is going on more visible.  Perhaps it causes some problem. 

I deliberately left the 'wan' port disconnected so that it wouldn't get assigned.  Everything I read told me that this wouldn't cause a problem. I'm not ready yet to connect this thing to the real Wan.

There are also a couple of 10 Gb SFP+ that I have been trying to keep out of the picture.  My ISP provides a fairly unconfabulated 2.5 Gb F-Dplx fiber connection. But they include a fiber -> 2.5 G conversion, so I don't need those ports right now.

I am most concerned that there is some problem with pre-installed drivers.  But I see no indication of that so far.  I don't know if there are particular logs that I should check.

Dave

#6

High availability / Re: Kea DHCP duplicating respo...

Last post by badyusuke - Today at 02:32:55 AM

I wonder how big the problem you describe actually is because you have the first report. There are lots of big HA setups out there that run this just fine it seems even if there is the potential for a race condition in lease assignment.

Well, perhaps I wasn't fully understood because I didn't provide enough context for the issues that led me to the explanations I've been sharing since my first post. I apologize in advance for any misunderstanding.

We recently migrated from ISC DHCP to Kea. To perform this migration, I read the OPNsense documentation, searched this forum for any questions other colleagues might have had regarding this transition, and watched some online videos to ensure everything was correct. Like with any service migration, I kept a close eye on the logs over the past few weeks to ensure everything was running smoothly. From the beginning, I noticed the DHCPSRV_MULTIPLE_RAW_SOCKETS_PER_IFACE warning, but since it was just a warning, I let the service run, assuming it might be normal for the way OPNsense configures it.

After running Kea for a few days, I received a report of an IP conflict—something we hadn't experienced in years. Naturally, I looked into the Kea logs to understand what was happening. In most cases, we see DHCP packet duplication where Kea hands out the same IP, which only impacts the lease time. However, under certain conditions that I can't completely pinpoint (but I suspect are related to the timing of how threads handle duplicated packets), we can observe a single thread offering one IP for the first duplicated packet, and then offering a different IP for the second duplicated packet. Here is an example:

Code Select Expand

2026-05-01T15:10:31-03:00 Informational kea-dhcp4 INFO [kea-dhcp4.packets.0x2da78ea76008] DHCP4_PACKET_SEND [hwtype=1 00:1e:e5:xx:xx:9d], cid=[01:00:1e:e5:xx:xx:9d], tid=0x5573: trying to send packet DHCPOFFER (type 2) from 10.y.y.2:67 to 10.y.y.89:68 on interface vlan04
2026-05-01T15:10:31-03:00 Informational kea-dhcp4 INFO [kea-dhcp4.leases.0x2da78ea76008] DHCP4_LEASE_OFFER [hwtype=1 00:1e:e5:xx:xx:9d], cid=[01:00:1e:e5:xx:xx:9d], tid=0x5573: lease 10.y.y.89 will be offered
2026-05-01T15:10:31-03:00 Informational kea-dhcp4 INFO [kea-dhcp4.packets.0x2da78ea76808] DHCP4_PACKET_SEND [hwtype=1 00:1e:e5:xx:xx:9d], cid=[01:00:1e:e5:xx:xx:9d], tid=0x5573: trying to send packet DHCPOFFER (type 2) from 10.y.y.2:67 to 10.y.y.88:68 on interface vlan04
2026-05-01T15:10:31-03:00 Informational kea-dhcp4 INFO [kea-dhcp4.leases.0x2da78ea76808] DHCP4_LEASE_OFFER [hwtype=1 00:1e:e5:xx:xx:9d], cid=[01:00:1e:e5:xx:xx:9d], tid=0x5573: lease 10.y.y.88 will be offered
2026-05-01T15:10:31-03:00 Informational kea-dhcp4 INFO [kea-dhcp4.packets.0x2da78ea76008] DHCP4_PACKET_RECEIVED [hwtype=1 00:1e:e5:xx:xx:9d], cid=[01:00:1e:e5:xx:xx:9d], tid=0x5573: DHCPDISCOVER (type 1) received from 0.0.0.0 to 255.255.255.255 on interface vlan04
2026-05-01T15:10:31-03:00 Informational kea-dhcp4 INFO [kea-dhcp4.packets.0x2da78ea76808] DHCP4_PACKET_RECEIVED [hwtype=1 00:1e:e5:xx:xx:9d], cid=[01:00:1e:e5:xx:xx:9d], tid=0x5573: DHCPDISCOVER (type 1) received from 0.0.0.0 to 255.255.255.255 on interface vlan04
2026-05-01T15:10:31-03:00 Informational kea-dhcp4 INFO [kea-dhcp4.dhcp4.0x2da78ea76808] DHCP4_QUERY_LABEL received query: [hwtype=1 00:1e:e5:xx:xx:9d], cid=[01:00:1e:e5:xx:xx:9d], tid=0x5573
2026-05-01T15:10:31-03:00 Informational kea-dhcp4 INFO [kea-dhcp4.dhcp4.0x2da78ea76008] DHCP4_QUERY_LABEL received query: [hwtype=1 00:1e:e5:xx:xx:9d], cid=[01:00:1e:e5:xx:xx:9d], tid=0x5573
In other situations, since I have 4 threads available, each thread grabs one of these packet copies at the exact same time and offers up to 4 different IPs to the exact same computer:

Code Select Expand

2026-04-23T09:58:15-03:00 Informational kea-dhcp4 INFO [kea-dhcp4.leases.0x4aae83ac9008] DHCP4_LEASE_OFFER [hwtype=1 90:09:df:xx:xx:50], cid=[01:90:09:df:xx:xx:50], tid=0x9a6360f6: lease 10.y.y.67 will be offered
2026-04-23T09:58:15-03:00 Informational kea-dhcp4 INFO [kea-dhcp4.packets.0x4aae83ad0008] DHCP4_PACKET_SEND [hwtype=1 90:09:df:xx:xx:50], cid=[01:90:09:df:xx:xx:50], tid=0x9a6360f6: trying to send packet DHCPOFFER (type 2) from 10.y.y.2:67 to 10.y.y.66:68 on interface vlan02
2026-04-23T09:58:15-03:00 Informational kea-dhcp4 INFO [kea-dhcp4.leases.0x4aae83ad0008] DHCP4_LEASE_OFFER [hwtype=1 90:09:df:xx:xx:50], cid=[01:90:09:df:xx:xx:50], tid=0x9a6360f6: lease 10.y.y.66 will be offered
2026-04-23T09:58:15-03:00 Informational kea-dhcp4 INFO [kea-dhcp4.packets.0x4aae83ac9008] DHCP4_PACKET_RECEIVED [hwtype=1 90:09:df:xx:xx:50], cid=[01:90:09:df:xx:xx:50], tid=0x9a6360f6: DHCPDISCOVER (type 1) received from 0.0.0.0 to 255.255.255.255 on interface vlan02
2026-04-23T09:58:15-03:00 Informational kea-dhcp4 INFO [kea-dhcp4.packets.0x4aae83ad0008] DHCP4_PACKET_RECEIVED [hwtype=1 90:09:df:xx:xx:50], cid=[01:90:09:df:xx:xx:50], tid=0x9a6360f6: DHCPDISCOVER (type 1) received from 0.0.0.0 to 255.255.255.255 on interface vlan02
2026-04-23T09:58:15-03:00 Informational kea-dhcp4 INFO [kea-dhcp4.dhcp4.0x4aae83ac9008] DHCP4_QUERY_LABEL received query: [hwtype=1 90:09:df:xx:xx:50], cid=[01:90:09:df:xx:xx:50], tid=0x9a6360f6
2026-04-23T09:58:15-03:00 Informational kea-dhcp4 INFO [kea-dhcp4.dhcp4.0x4aae83ad0008] DHCP4_QUERY_LABEL received query: [hwtype=1 90:09:df:xx:xx:50], cid=[01:90:09:df:xx:xx:50], tid=0x9a6360f6
2026-04-23T09:58:12-03:00 Informational kea-dhcp4 INFO [kea-dhcp4.packets.0x4aae83ac9808] DHCP4_PACKET_SEND [hwtype=1 90:09:df:xx:xx:50], cid=[01:90:09:df:xx:xx:50], tid=0x9a6360f6: trying to send packet DHCPOFFER (type 2) from 10.y.y.2:67 to 10.y.y.65:68 on interface vlan02
2026-04-23T09:58:12-03:00 Informational kea-dhcp4 INFO [kea-dhcp4.leases.0x4aae83ac9808] DHCP4_LEASE_OFFER [hwtype=1 90:09:df:xx:xx:50], cid=[01:90:09:df:xx:xx:50], tid=0x9a6360f6: lease 10.y.y.65 will be offered
2026-04-23T09:58:12-03:00 Informational kea-dhcp4 INFO [kea-dhcp4.packets.0x4aae83a7b808] DHCP4_PACKET_SEND [hwtype=1 90:09:df:xx:xx:50], cid=[01:90:09:df:xx:xx:50], tid=0x9a6360f6: trying to send packet DHCPOFFER (type 2) from 10.y.y.2:67 to 10.y.y.64:68 on interface vlan02
2026-04-23T09:58:12-03:00 Informational kea-dhcp4 INFO [kea-dhcp4.leases.0x4aae83a7b808] DHCP4_LEASE_OFFER [hwtype=1 90:09:df:xx:xx:50], cid=[01:90:09:df:xx:xx:50], tid=0x9a6360f6: lease 10.y.y.64 will be offered
2026-04-23T09:58:12-03:00 Informational kea-dhcp4 INFO [kea-dhcp4.packets.0x4aae83ac9808] DHCP4_PACKET_RECEIVED [hwtype=1 90:09:df:xx:xx:50], cid=[01:90:09:df:xx:xx:50], tid=0x9a6360f6: DHCPDISCOVER (type 1) received from 0.0.0.0 to 255.255.255.255 on interface vlan02
2026-04-23T09:58:12-03:00 Informational kea-dhcp4 INFO [kea-dhcp4.packets.0x4aae83a7b808] DHCP4_PACKET_RECEIVED [hwtype=1 90:09:df:xx:xx:50], cid=[01:90:09:df:xx:xx:50], tid=0x9a6360f6: DHCPDISCOVER (type 1) received from 0.0.0.0 to 255.255.255.255 on interface vlan02
2026-04-23T09:58:12-03:00 Informational kea-dhcp4 INFO [kea-dhcp4.dhcp4.0x4aae83a7b808] DHCP4_QUERY_LABEL received query: [hwtype=1 90:09:df:xx:xx:50], cid=[01:90:09:df:xx:xx:50], tid=0x9a6360f6
2026-04-23T09:58:12-03:00 Informational kea-dhcp4 INFO [kea-dhcp4.dhcp4.0x4aae83ac9808] DHCP4_QUERY_LABEL received query: [hwtype=1 90:09:df:xx:xx:50], cid=[01:90:09:df:xx:xx:50], tid=0x9a6360f6
I have a Wi-Fi network with controllers from different vendors, and one of them has flagged the detection of clients with conflicting IPs on different interfaces/VLANs in its logs, as shown in image below.

You cannot view this attachment.

I have been deep-diving into this issue over the last few weeks, and the only logical reason I can find for these IP conflicts is this packet duplication. I can't explain the exact internal mechanics behind it (maybe Kea ends up offering the same IP to two different devices, or tries to use an IP already assigned to someone else due to the race condition). I have also been monitoring leases to see if there is any premature exhaustion of the available IP pool, but that hasn't happened so far.

Since an IP conflict directly affects the client device, it's usually hard to get end-users to actively report it to the network admin. I was lucky that a coworker reported it to me and that one of our Wi-Fi controllers also logs this specific event. Additionally, processing these duplicated packets wastes CPU cycles, which could become a problem during peak hours.

I came to this forum because I genuinely couldn't find anyone else reporting this, so I might be the first to post about it. However, that doesn't invalidate the fact that there is something negatively impacting my setup. I am confident I read all the configuration recommendations from the official OPNsense and Kea documentation, and I believe I configured it correctly, but there is always a chance I missed something. Since my very first post, my intention has been to present the issue and see if anyone could point out a configuration flaw on my end. My goal here is simply to seek help and collaborate with the community to resolve this issue.

Finally, to be fully transparent as requested: I have indeed been using AI assistance (Gemini) to help me with my research, log parsing, and to structure my technical analyses. Furthermore, since English is not my native language, I use it to translate and properly adapt what I write into English.

#7

26.1, 26,4 Series / Re: [closed] Unbound fails to ...

Last post by lmoore - Today at 01:41:18 AM

I tested enabling the options Use System Nameserver under Query Forwarding and DNS over TLS and reviewed the Unbound configuration files. These options will create the forward-zone for "." and point to the name servers listed in System -> Settings -> General.

Quad9 have a set up guide for various OS's to forward queries to them using DoT. The "full help" for the above options in OPNsense clearly state DoT will never be used for queries to system nameservers.

#8

General Discussion / Re: OPNSense 26.1 installs but...

Last post by OPNenthu - Today at 01:20:57 AM

By default on a fresh OPNsense installation you'll get the first port (igc0 in your case) configured as the LAN interface with 192.168.1.1 (subnet 192.168.1.0/24).  Your second port (igc1) would be the WAN port, which it sounds like it's not able to get an internet connection yet.  That's not needed if you're just trying to access OPNsense, anyway.

The DHCP server should already be running on OPNsense so you don't need any static config on your laptop.

Make sure you are connecting to the igc0 port and not any of the others.  Hopefully your router has the first port marked in some way.  They aren't always obvious or in left-to-right order.

I have a small display connected by HDMI that lets me see the the text-mode setup menu.  A keyboard allows me to change settings, reboot, etc.  But I have no way to open a serial console as the instructions suggest.

Since you already have a VGA console then the serial console should not be needed.

OBTW, in case it matters, I did pay for a one year license.

Doesn't matter here- this is a community support forum :)  Though thank you for supporting them.  We all benefit.

Since you paid for the business edition license, don't forget to switch your configuration to it once you have access to the OPNsense UI.  The one you have installed now (26.1) is a Community edition.  The latest Business edition is 26.4:

https://docs.opnsense.org/releases.html

You can activate your Business edition under System->Firmware->Settings

#9

26.1, 26,4 Series / Re: Destination NAT - changes ...

Last post by lmoore - Today at 01:20:18 AM

Also, when set to "Register rule", it will appear in your rules as an "Automatic Rule", which will be visible when "Inspect" is enabled.

#10

26.1, 26,4 Series / Re: [closed] Unbound fails to ...

Last post by passeri - Today at 12:59:40 AM

What is your setting for System -> Settings -> General -> DNS server options -> Allow DNS server list to be overridden by DHCP/PPP on WAN?

No override.

Yes, my intention was to make the connections to root servers, as Unbound defaults.

configure Unbound to forward all other zones, i.e., not local, to an upstream DNS server but this doesn't seem possible in OPNsense

I am not sure what you mean by this. In my network there is effectively a couple of layers such that the 'green' zone is firewalled from the rest independently from the fact the Opnsense edge router distinguishes three zones in its rules. The internal router caches (as do computers) and addresses all new DNS enquiries directly to the edge Opnsense, where Unbound listens on all interfaces and sends its queries to root servers. Is this the general idea you were discussing?