Messages

Thanks, Franco, good call. This indeed fixed the issue.

Two more questions, if I may:
* Did this condition constitute a security risk whatsoever?
* What may have been the root cause of it?

Dear forum,

I am getting this error when running a health audit:

Code Select Expand

python313-3.13.13: checksum mismatch for /usr/local/lib/python3.13/__pycache__/weakref.cpython-313.pyc
Neither a reboot nor running a cleanup job fixed it.

I am currently on 26.1.7_3 but the issue had been present also in 26.1.6 or maybe even .5.

Any thoughts or ideas are much valued.

I updated to 25.1.6 and checked the xz version. It's still 5.4.5.

Do we have any ETA for the roll-out of a fixed version?

I can confirm that the log viewer still doesn't work.

On a side note, the dates in the drop-down menu are not sorted chronologically. It's not new, this "bug" has been around for quite some time. However, I wonder if there are any plans for fixing this?

I doubt in a firewall appliance context anyone will be able to feed untrusted data to liblzma.

I am also not overly concerned about this bug. However, just out of curiosity, what are the file types of e.g. Suricata rule updates or DNS block lists that OPNSense downloads regularly? I'd assume they are provided as .gz rather than .xz.

Hi forum,

Since the upgrade to 25.1.5, I cannot see any details of my Suricata logs. When clicking on an entry in the log, I just get an empty pop-up.

Clearing the browser cache does not help.

Any ideas are much welcome.

BR

I did my homework before asking. No CUPS package to be found in OPNsense and no port 631 listening.

However, since *BSD is potentially affected, I would like to confirm that there is indeed no risk for OPNsense. Could any third-party package install CUPS?

Thank you.

Thanks, franco, for the hint. I will check at my earliest convenience.

I haven't dug into this topic too much but I also notice that many Microsoft domains do not resolve on my internal network. Lookups on OPN directly work.

Example: g.msn[.]com

I was hoping that some update would fix that issue...

Hi forum,

I can completely confirm this issue.

After switching on a PC that is directly connected to one of the OPN ports, it takes approx. 10 minutes for the external network connection to become available. Connection to the OPN interface works, as does e.g. DNS. So it's not an issue on the "pc side" of the network.

All other physical OPN ports are not affected and continue to function as normal.

The only log entries that appear around the time the network starts to work are those:

SYSTEM/LOG/GENERAL
Notice   root   reload filter for configured schedules   
Notice   kernel   <6>igb1: promiscuous mode disabled   
Notice   kernel   <6>igb1: promiscuous mode enabled

This has only started after upgrading to 23.7.7_3.

Any ideas are much appreciated.

Hi fbtanner,

I guess we need more details on your configuration. However, if your OPN's LAN IF has 10.8.0.1/16, there is no such thing as a 10.8.1.0/?? subnet. The only network you have is 10.8/16.

My first guess is that you have configured 10.8.x.0/24 networks on your hosts which will not work as expected.

Any 10.8.x.0/24 where x!=0 will not have a route to your OPN box.

Dear forum,

I'm a bit puzzled.

I have a firewall deny rule that blocks access to a particular domain by means of an alias that I have created for that domain.

The rule has been working fine for months. Then I observed that the domain is accessible all of a sudden. I didn't touch the firewall config. For debugging purposes, I enabled logging for the rule in question and, voila, the rule works again as it should.

Any hints are much appreciated.

Thanks,
adk

Hi forum,

I am on 22.7.10_2. Yesterday, I configured some static DHCPv4 mappings. With every entry in the mapping table, my memory use increased. After having created three entries, something had hogged all my free memory (6GB) and filled up my entire swap.

Rebooting fixed the issue and everything was back to normal.

Creating more static mapping entries reliably reproduced the issue.

Is this a known bug?

Regards,
adk

I also noticed the vuln in the security audit.

However, the really interesting questions are:-
* Is OPNsense vulnerable in its default configuration?
* Are there any mitigation measures?
* Is access to the web UI needed or are there also other attack vectors?

Any feedback is much appreciated.

Dear forum,

I am trying to implement time-based restrictions for some IPs on my network that can be bypassed with a password or similar. I.e. for normal users, internet access should be terminated at a certain time. For some users, though, it should be possible to bypass this restriction. However, I haven't found a viable solution yet.

Time-triggered firewall rules do not appear to be suitable since they cannot be bypassed.

A captive portal is also not ideal as it is AFAIK always active.

Setting up a VPN server just for a few internal IPs to bypass time-based restrictions seems to be a bit over the top :).

Any suggestions are highly welcome.

Cheers,
adk