Topics

I noticed a quirk in the Event Viewer under Security > Q-Feeds Connect: the default sort order is inconsistent. Events are grouped by day in descending order (today first, then yesterday, etc.), but within each day they are sorted ascending by time (00:00 to 23:59).
The result is a non-continuous timeline that makes finding recent events unintuitive: the most recent events of any given day appear at the bottom of that day's group, not at the top.
The workaround is to manually click the timestamp column to re-sort, but the default behavior seems unintentional and is confusing on first encounter.

I tried to enable basic auth in Caddy to protect from brute-force attacks; I have done so by enabling basic auth on the domain. When testing this, I noticed I need to re-enter my credentials on every webpage I browse to. Somehow it doesn't stick.
A chatgpt consultation finds issues with the generated config file, but because it's generated by the GUI I am not able to try out any of the suggestions which would require manual editing of the config file, or make the changes permanent after that.
What would be the best way to proceed here?

I have an IPv6-enabled system, and noticed that the automatically generated rule 'let out anything from firewall host itself' is IPv4 only, and I couldn't find a similar rule for IPv6. Are more people seeing this?

It looks like the search bar in Interfaces → Neighbors → Automatic Discovery does a partial match. Searching for 192.168.1.1 also shows 192.168.1.1xx. Is there any way to force an exact match search?

I received an email this morning regarding the release of ZenArmor 2.1. Could you please confirm whether any action is required on my part to install the update? It doesn't appear to have upgraded automatically.

Additionally, does this release include the long-awaited multi-core / multi-thread support?

The new 2.0 release of ZenArmor contains bugs that make it unreliable for my setup. Is there a way to install an older version and prevent it from being upgraded automatically during system updates?

I'm getting this sequence of warnings, and it's always the same duid:

Code Select Expand

WARN [kea-dhcp6.alloc-engine.0x1340fa505700] ALLOC_ENGINE_V6_ALLOC_FAIL_CLASSES duid=[00:03:00:01:da:c5:77:4c:86:f0], [no hwaddr info],
tid=0x41270a: Failed to allocate an IPv6 address for client with classes: ALL, UNKNOWN
WARN [kea-dhcp6.alloc-engine.0x1340fa505700] ALLOC_ENGINE_V6_ALLOC_FAIL_NO_POOLS duid=[00:03:00:01:da:c5:77:4c:86:f0], [no hwaddr info],
tid=0x41270a: no pools were available for the lease allocation
WARN [kea-dhcp6.alloc-engine.0x1340fa505700] ALLOC_ENGINE_V6_ALLOC_FAIL_SUBNET duid=[00:03:00:01:da:c5:77:4c:86:f0], [no hwaddr info],
tid=0x41270a: failed to allocate an IPv6 lease in the subnet 2a02:xxxx:xxxx::/64, subnet-id 1, shared network (none)

A ChatGPT consultation suggests the generated config has some kind of class restriction, because the client has both the classes ALL and UNKNOWN, hence it not being assigned a pool to distribute an address from. I looked in the generated config files, and it doesn't seem to use anything with classes or reservations.

This is my kea-dhcpd6.conf:

Code Select Expand

{
    "Dhcp6": {
        "valid-lifetime": 4000,
        "interfaces-config": {
            "interfaces": [
                "igc0"
            ]
        },
        "lease-database": {
            "type": "memfile",
            "persist": true
        },
        "control-socket": {
            "socket-type": "unix",
            "socket-name": "\/var\/run\/kea6-ctrl-socket"
        },
        "loggers": [
            {
                "name": "kea-dhcp6",
                "output_options": [
                    {
                        "output": "syslog"
                    }
                ],
                "severity": "INFO"
            }
        ],
        "subnet6": [
            {
                "id": 1,
                "subnet": "2a02:xxxx:xxxx::\/64",
                "option-data": [],
                "pools": [
                    {
                        "pool": "2a02:xxxx:xxxx::1000-2a02:xxxx:xxxx::2000"
                    }
                ],
                "pd-pools": [],
                "reservations": [],
                "interface": "igc0",
                "pd-allocator": "random",
                "allocator": "random"
            }
        ],
        "hooks-libraries": [
            {
                "library": "\/usr\/local\/lib\/kea\/hooks\/libdhcp_lease_cmds.so"
            }
        ]
    }

Any ideas what the issue could be, or what to try further?

I was testing the recently added DHCP support in DNSmasq and wanted to report that while IPv6 DHCP appears to be working fine, DHCPv4 was not. The service started up without issues, but no DHCPv4 requests seemed to reach it initially. After a reboot, requests started coming through, suggesting a possible firewall-related issue.

However, on the client side (Windows 11), things got even stranger: after said reboot the client received an IP address that was outside the assigned range, while an address within the assigned range was allocated as the DHCP server/DNS/Gateway. Very odd behavior.

Unfortunately, I wasn't able to investigate further because of angry users (a.k.a. my kids) demanding working internet.

I reported the issue here https://forum.opnsense.org/index.php?topic=44880.0
Created a github issue as requested: https://github.com/opnsense/core/issues/8176

Now the issue has apparently been fixed in github by kulikov-a, but the fixes never made it into OPNsense.
Could someone have a look at this?

I would like to report that starting with the latest update (25.1.2), the dashboard widgets/graphs are constantly redrawing/resizing, giving a very jittery look. I have a 27" monitor with 3840 × 2160 resolution, and this only happens when the browser is being displayed full screen. As soon as I resize the browser window, the issue is gone. Anything I can do to assist in fixing this?

I have been playing around with nginx as a reverse proxy, and noticed something peculiar: every time I enable sendfile support in the main config page, it gets disabled automatically after some time. Is this expected behavior?
I have it enabled in the individual HTTP server entries as well.

I noticed that starting with 24.7.11, the plugins and packages tabs are not populating anymore. Another thing I noticed, is the 'status' tab wheelie thing keeps spinning.
Are other people seeing this?

I recently came across the website https://www.unibet.nl/ which is apparently one the larger gambling websites in my country. Unfortunately this wasn't recognized by Zenarmor.
Every once in while I come across an URL which isn't categorized or is categorized wrongly.
This leads me to the more general question: what is the preferred way of submitting these cases for (re)classification?

The site www.hamrick.com is the website of Vuescan software. However, this is currently being classified as Botnet C&C. Could you please verify this to be correct and adjust if necessary?
They may have been hacked, or been hacked in the past and remedied this since, or perhaps this is a misclassification of some sort.

I have installed the crowdsec plugin, which seems to working alright. There is however one thing that bothers me: the ipv6 blocklist as viewed in the Firewall/Aliases page is not being populated, while the ipv4 list is. I have subscribed to the following lists: Firehol greensnow.co, botscout, and cruzit.com.
Am I missing something?

Title pretty much says it all. I'm currently using my phone to look at the OPNsense gui, and I noticed the 'Inspect' button in the firewall rules section is not visible, so I am not able to observe the evaluation and state count. Could this functionality perhaps be brought back?

Some time ago, I posted the message below to the 24.1 stable forum. One of the hypothesis is that kea fails to startup properly due to link flapping, caused by Zenarmor binding to the interface at the same time. This issue still exists with 24.7 final. When I disable Zenarmor, all is well.

A few OPNsense releases ago, I migrated from isc-dhcp4 to kea. This mostly works, however there is one nagging issue: Every once in a while, after a reboot, kea appears not to be running. In the logs, the message 'no interface configured to listen to DHCP traffic' is shown. After a manual restart of kea all is well.
The error is not readily visible on the OPNsense dashboard, as kea appears to be running, it just isn't doing anything.
As this doesn't always happen, it seems to be a timing-sensitive issue. Are other people seeing this?

Code Select Expand

2024-07-11T15:35:01 WARN [kea-dhcp4.dhcp4.0x834bcb000] DHCP4_MULTI_THREADING_INFO enabled: yes, number of threads: 2, queue size: 64
2024-07-11T15:35:01 WARN [kea-dhcp4.dhcpsrv.0x834bcb000] DHCPSRV_NO_SOCKETS_OPEN no interface configured to listen to DHCP traffic
2024-07-11T15:35:01 WARN [kea-dhcp4.dhcpsrv.0x834bcb000] DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface igb0 is not running
2024-07-11T15:35:01 WARN [kea-dhcp4.dhcp4.0x834bcb000] DHCP4_RESERVATIONS_LOOKUP_FIRST_ENABLED Multi-threading is enabled and host reservations lookup is always performed first.
2024-07-11T15:35:01 WARN [kea-dhcp4.dhcpsrv.0x834bcb000] DHCPSRV_MT_DISABLED_QUEUE_CONTROL disabling dhcp queue control when multi-threading is enabled.
2024-07-11T15:34:57 WARN [kea-dhcp4.dhcp4.0x834bcb000] DHCP4_MULTI_THREADING_INFO enabled: yes, number of threads: 2, queue size: 64
2024-07-11T15:34:57 WARN [kea-dhcp4.dhcp4.0x834bcb000] DHCP4_RESERVATIONS_LOOKUP_FIRST_ENABLED Multi-threading is enabled and host reservations lookup is always performed first.
2024-07-11T15:34:57 WARN [kea-dhcp4.dhcpsrv.0x834bcb000] DHCPSRV_MT_DISABLED_QUEUE_CONTROL disabling dhcp queue control when multi-threading is enabled.


The URL https://www.teamnl.org/ is currently being classified as 'gambling'. It is however the official Dutch site covering the Olympic Games 2024 in France. Maybe the site has shown gambling ads at some point, but it isn't related to gambling in itself. Could you please recategorize it?

A few OPNsense releases ago, I migrated from isc-dhcp4 to kea. This mostly works, however there is one nagging issue: Every once in a while, after a reboot, kea appears not to be running. In the logs, the message 'no interface configured to listen to DHCP traffic' is shown. After a manual restart all is well.
The error is not readily visible on the OPNsense dashboard, as kea appears to be running, it just isn't doing anything.
As this doesn't always happen, it seems to be a timing-sensitive issue. Are other people seeing this?

Code Select Expand

2024-07-11T15:35:01 WARN [kea-dhcp4.dhcp4.0x834bcb000] DHCP4_MULTI_THREADING_INFO enabled: yes, number of threads: 2, queue size: 64
2024-07-11T15:35:01 WARN [kea-dhcp4.dhcpsrv.0x834bcb000] DHCPSRV_NO_SOCKETS_OPEN no interface configured to listen to DHCP traffic
2024-07-11T15:35:01 WARN [kea-dhcp4.dhcpsrv.0x834bcb000] DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface igb0 is not running
2024-07-11T15:35:01 WARN [kea-dhcp4.dhcp4.0x834bcb000] DHCP4_RESERVATIONS_LOOKUP_FIRST_ENABLED Multi-threading is enabled and host reservations lookup is always performed first.
2024-07-11T15:35:01 WARN [kea-dhcp4.dhcpsrv.0x834bcb000] DHCPSRV_MT_DISABLED_QUEUE_CONTROL disabling dhcp queue control when multi-threading is enabled.
2024-07-11T15:34:57 WARN [kea-dhcp4.dhcp4.0x834bcb000] DHCP4_MULTI_THREADING_INFO enabled: yes, number of threads: 2, queue size: 64
2024-07-11T15:34:57 WARN [kea-dhcp4.dhcp4.0x834bcb000] DHCP4_RESERVATIONS_LOOKUP_FIRST_ENABLED Multi-threading is enabled and host reservations lookup is always performed first.
2024-07-11T15:34:57 WARN [kea-dhcp4.dhcpsrv.0x834bcb000] DHCPSRV_MT_DISABLED_QUEUE_CONTROL disabling dhcp queue control when multi-threading is enabled.


Sometimes I log into the OPNsense web interface, go to the Zenarmor dashboard page, and then I'm greeted with the message that the packet engine has been updated, and needs to be restarted manually in order to activate the new version.
I try to configure my systems so they need as little manual intervention as possible. Would it be possible to restart the packet engine (not daily, but as part of an upgrade) using cron or something? I wouldn't mind a few seconds of downtime during the night for this.