Messages

On the Opnsense dashboard, is the "Blocked" figure a rolling number over a period or will it increase infinitely?

If over a period, is that a setting somewhere?

Good to hear you have it running as you want.

That FM is not bad at all ;-)

To clarify for my own part, I am working on information or hypotheses like these:

• I have spotted no errors in your Kea configuration.
• Kea is working for you on other sub-nets
• therefore, I do not believe there is a problem with Kea.
• Your initial logs show in one case zero client communication and in the other, a client being offered one address while manually wanting another, with no resultant communication or configuration.
• I have not seen evidence that the client has requested an address via DHCP
• therefore, I am trying to set up a controlled experiment to see whether there is any such communication in Kea's log.

Given I think the problem is not in Kea which is otherwise a critical component, we try to falsify that before looking elsewhere.

coatmaker618, this may seem pedantic but your answers are not actually clarifying things.

The OPNSense log or client log?  I posted the OPNSense log here https://forum.opnsense.org/index.php?topic=49321.msg250177#msg250177  only filtered by MAC, so it should have everything with the desktop.

kea(2).log or kea(3).log? You do not say. This is extracted from my opnsense kea log as an example of a successful allocation to a reserved address (opnsense.lan is a name substitution]:

Code Select Expand

<134>1 2025-10-19T05:38:39+11:00 opnsense.lan kea-dhcp4 25170 - [meta sequenceId="2"] INFO  [kea-dhcp4.packets.0x460dffe76008] DHCP4_PACKET_RECEIVED [hwtype=1 a4:fc:14:05:cc:a6], cid=[01:a4:fc:14:05:cc:a6], tid=0xc6b38095: DHCPREQUEST (type 3) received from 0.0.0.0 to 255.255.255.255 on interface igc0
<134>1 2025-10-19T05:38:39+11:00 opnsense.lan kea-dhcp4 25170 - [meta sequenceId="3"] INFO  [kea-dhcp4.leases.0x460dffe76008] DHCP4_INIT_REBOOT [hwtype=1 a4:fc:14:05:cc:a6], cid=[01:a4:fc:14:05:cc:a6], tid=0xc6b38095: client is in INIT-REBOOT state and requests address 10.2.1.10
<134>1 2025-10-19T05:38:39+11:00 opnsense.lan kea-dhcp4 25170 - [meta sequenceId="4"] INFO  [kea-dhcp4.leases.0x460dffe76008] DHCP4_LEASE_ALLOC [hwtype=1 a4:fc:14:05:cc:a6], cid=[01:a4:fc:14:05:cc:a6], tid=0xc6b38095: lease 10.2.1.10 has been allocated for 86400 seconds
<134>1 2025-10-19T05:38:39+11:00 opnsense.lan kea-dhcp4 25170 - [meta sequenceId="5"] INFO  [kea-dhcp4.leases.0x460dffe76008] DHCP4_LEASE_REUSE [hwtype=1 a4:fc:14:05:cc:a6], cid=[01:a4:fc:14:05:cc:a6], tid=0xc6b38095: lease 10.2.1.10 has been reused for 81159 seconds
<134>1 2025-10-19T05:38:39+11:00 opnsense.lan kea-dhcp4 25170 - [meta sequenceId="6"] INFO  [kea-dhcp4.packets.0x460dffe76008] DHCP4_PACKET_SEND [hwtype=1 a4:fc:14:05:cc:a6], cid=[01:a4:fc:14:05:cc:a6], tid=0xc6b38095: trying to send packet DHCPACK (type 5) from 10.2.1.1:67 to 10.2.1.10:68 on interface igc0
<134>1 2025-10-19T05:58:22+11:00 opnsense.lan kea-dhcp4 25170 - [meta sequenceId="1"] INFO  [kea-dhcp4.dhcpsrv.0x460dffe5c008] DHCPSRV_MEMFILE_LFC_START starting Lease File Cleanup



My pool is 100-199, so everything below 100 is actually reserved.

Whether you choose a reservation below or above the pool is not critical The question at hand is to

• Check your client configuration is (if possible) pointed at your DHCP server
• In Kea reserve any address so long as it is outside your pool, using the client's MAC address
• Ask the client to renew its lease
• Show exactly what was the client configuration before you tried
• Show /var/log/kea/latest.log where there is any record of the client's MAC or IP.

As a precaution, you may want to restart Kea after step 2.

Made some improvements on this; you can now set it to your own liking under 'account settings'. Also created a browser auto-detect function. That said it was a Saturday-morning (Europe/Amsterdam) quicky so please let me know if I missed a few timestamps :)

Thank you, seems to work well. I found myself on Reykjavik time; Mullvad browser declines or fails to auto-detect but Safari does.

I see that you have even picked up on Eucla time, an unofficial zone, and an entry for Broken Hill in case they forget they are on Central not Eastern. The national capital is missing (same as Sydney and Melbourne times) though no-one pays Canberra much attention anyway so that is fine. :)

Currently I am getting an error "An error occurred while searching" while trying to do a threat lookup. Tried three different blocked IPs. When I then went to History those searches are present with results, including the one I did twice, so the error message appears to be an error.

Consistent with the fact of an error message, available searches did not decrement.

A separate cosmetic query: I do not mind seeing time stamps in the European zone, but is there anything to be done to see those dates in a format which is not American? ISO format would cover all territories more sensibly.

There are no requests for, or allocations of, 192.168.1.42 in either log.

So what happens if you set assignment to DHCP rather than manual?

If I set assignments to DHCP (automatic) I don't get an IP on the client.
    "inet 169.254.41.44/16 brd 169.254.255.255 scope global dynamic"

Just to confirm, if the client knows the gateway and is set to get an IP by DHCP then it gets nothing? Is communication from LAN client to server verified as happening, e.g. with a ping?

What does the log show in that situation? Have you tried giving the client's MAC a reserved address above the .1-.199 pool? I found that where I wanted a fixed client IP I needed to reserve rather than relying on manual IP configuration of the client.

The situation is somewhat confused for me because I do not have a consistent case of basic client configuration with an associated log. You can also enable logs of LAN rules to verify the packets are passed on that interface. I am stopping short of packet tracing although that may be a next step.

There are no requests for, or allocations of, 192.168.1.42 in either log.

So what happens if you set assignment to DHCP rather than manual?

Implied because it is the default or usual gateway in a /24 range.

What about the failure of a device to respond at all to an offer, or where is the client request? Is the client config consistent with the gateway?

These are just a couple of things I noticed and which caused me to pause. It is not an analysis but a couple of queries which may or may not matter.

In Kea(2).log it simply keeps offering 192.168.1.40 with no apparent reply, but why do the offers appear to be coming from 192.168.1.3 when your implied gateway in Kea Subnets is 192.168.1.1 (192.168.1.1/24)?

In your Kea(3).log you have a warning DHCPSRV_LEASE_SANITY_FAIL where it thinks subnet ID 4 should be subnet ID 3 (lines 4-27 of your log). This is described in  Kea docs as:

This warning message is printed when the lease being loaded does not match the configuration. Due to lease-checks value, the lease will be loaded, but it will most likely be unused by Kea, as there is no subnet that matches the IP address associated with the lease.

It then appears to allocate successfully from 192.168.10.3

Is there any easy way to export those? I only ask as screenshots are kind of tough with the low filesize limit.

Plenty of screenshots have been posted here without issues around file size. You can reduce size if needed while keeping it screen-viewable.

I use Kea so would try to help if I could see the settings.

Sorry about the link. Fixed.

For my part I never click tinyurl.com or bit.ly links because I do not know where they go.

Your link has no destination. Based on the descriptive text, it would be fine.

As a general case, if the purpose is to be a firewall/router then you need less than you think you do.

I experimented with Threat Lookup using the first couple of entries in the Events list, i.e. the most recent. One of those IPs, 118.38.108.242, returned no results?

Does that mean it is not on or no longer on any threat list or it is but nobody knows why it is there?

Security: Q-Feeds Connect: Events shows every event twice. Also, the interface column is empty.

(Sorry if this is a known issue, just started testing Q-Feeds and didn't read all 200+ comments.)

You cannot view this attachment.

I am seeing the same, no interface and every event twice.

More information will be needed. Mine operates normally, populating the interface and without duplication.

I use a DEC697 and have no extras beyond Q-Feeds Plus and Crowdsec free.