Messages

Thanks franco!

Cheers,
Wrigleys

Hi All

After updating to 25.7.2 I've got the following Error-logs in General Log Files:

Code Select Expand

/usr/local/etc/rc.bootup: The command '/usr/local/etc/rc.d/dnsmasq stop' returned exit code '1', the output was 'dnsmasq not running? (check /var/run/dnsmasq.pid).'
Am I the only one?

Many thanks and regards,
Wrigleys

Hi andrema2

There is no 25.7.2 Update out there. I expect it in approx. 2 weeks.

Cheers
Wrigleys

Hi Monviech

Thanks for your support.

A DHCP range with Mode "static" only allows a Start address. When I specify the Domain in DHCP range it requires an End address. In addition to, with a "static" DHCP Range of the same Host-IP as Start address (with empty Domain), I'm unable to get the Domain appended in Host Override under "Domain". Seems kind of strange to me.

With logging I mean the Log File listed in GUI Services --> Dnsmasq DNS & DHCP --> Log File. For a single DNS Lookup the following Logs will be added:

2025-05-16T16:56:07    Informational    dnsmasq    using nameserver 2620:fe::9#53   
2025-05-16T16:56:07    Informational    dnsmasq    using nameserver 2620:fe::fe#53   
2025-05-16T16:56:07    Informational    dnsmasq    using nameserver 149.112.112.112#53   
2025-05-16T16:56:07    Informational    dnsmasq    using nameserver 9.9.9.9#53   
2025-05-16T16:56:07    Warning              dnsmasq    ignoring nameserver 127.0.0.1 - local interface   
2025-05-16T16:56:07    Informational    dnsmasq    reading /etc/resolv.conf

Log the results of DNS queries under "Advanced Mode" is deactivated.

Thanks and cheers,
Wrigleys

Hi All

I've switched from KEA DHCPv4 and Unbound to dnsmasq DHCP and DNS for simplicity and noticed few things:

• Adding a "Domain" in Host Override will be ignored (only the default domain will be applied). The configured Domain attribute (in DHCP ranges) gets applied when the address reservation is in a specific DHCP range. Best pracices would be to set static leases outside of any DHCP ranges.
• The option "Query DNS servers sequentially" seems not working correctly. For any DNS resolution I've see all configured nameserver in the Log File of dnsmasq (in my case 4 nameservers will be used for any DNS resolution)
• Is it planned to limit logging of dnsmasq? Because actually it logs any DNS request for any configured nameserver including 127.0.0.1 (which mentioned will be ignored)

Regardless, I would like to say THANK YOU to any developer of OPNsense. Your effort is highly appreciated. Awesome development progress during the last 10 years.

Many thanks and kind regards,
Wrigleys

I'm relatively sure this is the actual fallout from which we suffered consequences from in 24.7.x (but not 24.7 and 24.7.12):

https://www.freebsd.org/security/advisories/FreeBSD-SA-24:05.pf.asc
https://www.freebsd.org/security/advisories/FreeBSD-EN-24:16.pf.asc

Truth be told we raised the issue through the proper channels, but nobody cares as much.

So when we moved to FreeBSD 14.2 we took the FreeBSD code as is.

Now we are more or less where we were back then, but reverting it eternally is not going to be the solution.

https://github.com/opnsense/changelog/blob/2c7e4b3e94b61e2e40acdf40e6bf9ac83634d4c9/community/25.1/25.1#L116



Cheers,
Franco

I had a little time, yesterday, so tried looking at this a little bit more. The issue, is that it should not be showing in the log as the rule does not have logging enabled. Whether the ipv6 icmp is having issues or not, I don't understand how that forces logging on? Also I am seeing ipv4 improper logging also. "let out anything from firewall host itself (force gw)"

I have tried to attach a screen shot of the log and rules.debug that shows the relevant rules do not have logging enabled, yet logs are showing up.

+1
Thanks for following up. This is exactly my issue I've tried to explain :-) I'm still searching for the root cause, but I assume it's related to some backend changes (rule order change that maybe all rules are logged till our configuration will apply).

@IsaacFL: are your improper logs persistent or like in my case just for a short period of time after booting up OPNsense?

all the best,
Wrigleys

Hi franco and all other contributors

Actually I'm sure that we have two issues on this topic. My initial observation was some BLOCKED FW-Logs (even IPv4 traffic) right after reboot.
I've made some investigations:

OPNsense Appliance finished booting at 2025-02-13T19:29:58 (last timestamp in Boot log).
Few seconds after, I see some BLOCKED FW-Logs which are affecting random FW-Rules which are configured to NOT log any matching traffic.
Picture of those FW-Logs which should not be logged: https://imgur.com/a/0uNIq6k

After few seconds the issue is resolving itself (no logging anymore). This behavior started after Updating to 25.1.1, the initial 25.1 Upgrade was working fine.

Many thanks for your help.

Cheers,
Wrigleys

Thanks for your reply. You're absolutely right. Those logged rules were  (in my case) default ALLOW rules but it was logged as BLOCKED.

I'm seeing those BLOCKED logs for just a few seconds during booting up and it seems that the traffic went trought.

Interesting behavior.

Cheers,
Wrigleys

Hi all

My update to 25.1.1 was smooth. Many thanks for your hard work.

After update and reboot i've noticed a small cosmetic issue. I've disabled logging of the default ruleset at Firewall: Settings: Advanced. But for a short period of time during a reboot, those matching packets are getting logged in the live log. After the rebooting procedure, everything is working as expected (no logging anymore).

Am I the only one with this behavior?

Many thanks for your replies.

Best regards,
Wrigleys

Hi MysteryIron

Do you have some Ports open to WAN? In your case maybe HTTPS on Port 443 for Remote Access the OPNsense? (Which would be a bad idea actually - there are better solutions to achieve this).

All the best.

Regards
Wrigleys

Many thanks franco. Fully understand your point.
Sorry for my additional question:
As far as I read inside this forum and github, the refresh frequency of any alias will be checked every minute and be fetched/updated automatically without any triggered cron job.

Possible source: https://github.com/opnsense/core/commit/c5555b2ebc4c2285fb40d3a1a22c1966820bc64e

Therefore, I assume that the cron job will never be fast enough to update any aliases before the aliases will do it by itself. It checks every minute and will fetch/updates it once the refresh frequency is over.

So can it be, that this cron job has no right to exist anymore? 😉

Or does fetching the Alias not updates the according NAT/Rules? Is the update and reload cron job always needed?

Many thanks and take care,
Wrigleys

[Update and reload firewall aliases]

Hi all

I would like to update my URL Tables (Aliases) at specific times during a day (eg. 6PM) and setup a specific Cron Job for that case "Update and reload firewall aliases".

I see the Log-Entry for it, but no Aliases gets updated:

Code Select Expand

2024-09-24T18:00:00 Notice configd.py [7d88bb16-4d1d-41bd-91a1-60eeb3b86689] refresh url table aliases

Does this Cron Job work for you or are you all using the "Refresh Frequency" attribute inside the URL Table Alias?

Updating URL Tables with "Refresh Frequency" setup works, but the updates will not occur on a specific time (eg. 6PM).

Many thanks for your help.

All the best,
Wrigleys

Hi all,

I can confirm that after reverting the tuneables to default and deleting the line "microcode_update_enable="YES"" in /etc/rc.conf, the microcode update will still be performed after reboot.

Many thanks franco and the whole team for another seamless and struggle-free update.

All the best,
Wrigleys

Update from my end:

After triggering some test log entries, the log Date and timestamp (dropdown on top right) gets renewed (really don't know why), but the logs are still visible.

Therefore no logs are getting deleted.

Thread closed.

Dear Community

I decided to give Suricata with the latest Update to 24.7.1 another try.

My goal is to drop any matching Rule from abuse.ch. As far so good. I noticed, that the Alert Log inside WebGUI gets deleted really often. Sometimes every 20 minutes or at least every few hours. My log rotation is set to Weekly and my logs are stored on RAM. I have used 2GB of my 16GB RAM and 50% of the capacity could be filled by logs.

The suricata service runs stable and it seems working normally exept of missing potential log history.

Did you experience something similar to my findings?

Many thanks for your help.

Best regards
Wrigleys