Messages

since we don't collect any telemetry data, we can't display your hits in the TIP. This is a deliberate choice, we prefer not to gather any data from your firewalls.

Something appreciated by this user, for one.

@leony, I formerly had pretty much what you are discussing, with three LAN ports and some physical switches. Rules are pretty straightforward and it all worked.

My current setup is more complex, yet can still be implemented comfortably with or without VLANS (mine is without). It depends what suits if or when your system grows. There is nothing wrong with your starting point, especially if it can re-use existing equipment effectively.

I had an emerging problem where my mail server ceased to be able to access or be found outside its sub-net. I found that crowdsec was marked as blocking those messages so switched it off after which normal service was restored. Q-Feeds is still running on the WAN side. My public IP is not listed as an IOC in TIP.

In the course of this, I looked at the firewall log to find these (sample, abbreviated, unmatched, fake internal) entries, all TCP:

Source: 10.68.166.221:443
Dest: 177.36.61.165:42577
Action: block
Label: Block access to private nets

Source: 177.36.56.101:14851
Dest: 10.68.166.221:443
Action: pass
Label: let out anything from firewall

Should not the first be a pass and the second a block?
The 177.x.x.x addresses are not found in TIP IOC. Nor are they found by dig -x so it is understandable that they should be blocked, except it then seems the messaging is wrong.

Has something inverted here, or have I misunderstood it? I have made no changes to my firewall rules in ages other than adding the WAN floating rule for Q-Feeds.

Sorry coatmaker618, I have been busy out of town for a while. It seems you have an angle to pursue so I'll wait on that. As I mentioned earlier, I am reasonably convinced at this point that your problem is not in Kea. I choose not to use VLANs so I cannot pursue that line with you.

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.