Messages

well.   I didn't know that option was there, its been 40+ minutes and a new log has not appeared

   @franco this is my fault ill let your team decide on that GitHub request.


at the same time.  if someone thinks its better to have a faster check for host alias update times.    please education me,  I am all ears on this subject.   I am not a firewall expert I lean on the community

Edit: I just found that it depends on Type
URL Table: Refresh Frequency

I only have 1 alias where Type = Host(s). I change the default value here:
Firewall: Settings: Advanced
Aliases Resolve Interval [default (300s).]
my value = 14400

The new value is honored. Is this something different than the original post?

great question.   I just changed my setting to 604800

I should know fairly quickly

i would rather keep the spammers out.  it was a IVPN wireguard tunnel used at the time, so def shared address

been wanting to set this up for a while.   its strange only a few websites still do not work, im guessing they don't have their domain setup correctly.    no clue and not that important to me :)


is there a way to decrease the time it checks for hostname updates under alias?   or is 5-6 minutes expected


2026-02-09T04:58:01-05:00
Notice
firewall
resolving 199 hostnames (265 addresses) for webtowan took 0.84 seconds
2026-02-09T04:52:01-05:00
Notice
firewall
resolving 199 hostnames (274 addresses) for webtowan took 1.01 seconds
2026-02-09T04:46:01-05:00
Notice
firewall
resolving 199 hostnames (267 addresses) for webtowan took 1.03 seconds
2026-02-09T04:40:01-05:00
Notice
firewall
resolving 198 hostnames (264 addresses) for webtowan took 1.21 seconds
2026-02-09T04:34:01-05:00
Notice
firewall
resolving 198 hostnames (267 addresses) for webtowan took 0.74 seconds
2026-02-09T04:28:01-05:00
Notice
firewall
resolving 200 hostnames (266 addresses) for webtowan took 0.73 seconds
2026-02-09T04:22:01-05:00
Notice
firewall
resolving 201 hostnames (266 addresses) for webtowan took 0.91 seconds
2026-02-09T04:16:01-05:00
Notice
firewall
resolving 199 hostnames (266 addresses) for webtowan took 0.75 seconds
2026-02-09T04:10:01-05:00
Notice
firewall
resolving 200 hostnames (261 addresses) for webtowan took 0.75 seconds
2026-02-09T04:04:01-05:00
Notice
firewall
resolving 198 hostnames (259 addresses) for webtowan took 0.79 seconds
2026-02-09T03:58:01-05:00
Notice
firewall
resolving 199 hostnames (260 addresses) for webtowan took 0.83 seconds
2026-02-09T03:52:01-05:00
Notice
firewall
resolving 200 hostnames (260 addresses) for webtowan took 0.81 seconds
2026-02-09T03:46:01-05:00
Notice
firewall
resolving 199 hostnames (265 addresses) for webtowan took 1.02 seconds
2026-02-09T03:40:01-05:00
Notice
firewall
resolving 199 hostnames (263 addresses) for webtowan took 0.92 seconds
2026-02-09T03:34:01-05:00
Notice
firewall
resolving 199 hostnames (263 addresses) for webtowan took 0.74 seconds
2026-02-09T03:28:02-05:00
Notice
firewall
resolving 198 hostnames (255 addresses) for webtowan took 1.35 seconds
2026-02-09T03:22:02-05:00
Notice
firewall
resolving 200 hostnames (262 addresses) for webtowan took 1.01 seconds
2026-02-09T03:16:01-05:00
Notice
firewall
resolving 198 hostnames (266 addresses) for webtowan took 0.79 seconds

Context business edition I presume?  We'll do 25.10.2 in the coming week.


Cheers,
Franco

Yes Sir.  Thank you and the team  for keeping us secured

ended up learning how to create alias hosts  with a ton of websites.    and sent them over a different gateway

brain got some new wrinkles this morning.  thumbsup :)

i am far more concerned about the openssl ones:

Fetching vuln.xml.xz: .......... done
openssl-3.0.18,1 is vulnerable:
  OpenSSL -- Multiple vulnerabilities
  CVE: CVE-2026-22796
  CVE: CVE-2026-22795
  CVE: CVE-2025-69421
  CVE: CVE-2025-69420
  CVE: CVE-2025-69419
  CVE: CVE-2025-69418
  CVE: CVE-2025-68160
  CVE: CVE-2025-66199
  CVE: CVE-2025-15469
  CVE: CVE-2025-15468
  CVE: CVE-2025-15467
  CVE: CVE-2025-11187
  WWW: https://vuxml.freebsd.org/freebsd/4b824428-fb93-11f0-b194-8447094a420f.html

python311-3.11.14 is vulnerable:
  python -- several vulnerabilities
  CVE: CVE-2025-13836
  CVE: CVE-2025-12084
  WWW: https://vuxml.freebsd.org/freebsd/613d0f9e-d477-11f0-9e85-03ddfea11990.html

  python -- several security vulnerabilities
  CVE: CVE-2026-0865
  CVE: CVE-2026-1299
  WWW: https://vuxml.freebsd.org/freebsd/bfe9adc8-0224-11f1-8790-c5fb948922ad.html

libsodium-1.0.19 is vulnerable:
  security/libsodium -- crypto_core_ed25519_is_valid_point mishandles checks for whether an elliptic curve point is valid
  CVE: CVE-2025-69277
  WWW: https://vuxml.freebsd.org/freebsd/583b63f5-ebae-11f0-939f-47e3830276dd.html

4 problem(s) in 3 package(s) found.

Turned off forwarding and unbound. All 4 processes are using 474mb now
I changed it last night. That is what it shows this morning

Current business edition
System- diagnostic- activity

Shows 4 processes.  All of them using 489mb of ram?

Is this normal. This seems excessive to me
Can you change options so there are only two processes?

I am running a minimal setup, forwarding dns over tls to one server
Screen whots attached hopefully

apologies.  I did find a reply from Franco

it can be disabled but not deleted,  from a previous post

feel free to delete or lock this

Versions
OPNsense 25.10.1_2-amd64
FreeBSD 14.3-RELEASE-p7
OpenSSL 3.0.18

I scanned back 5 pages to see if this had been answered.   I am unable to delete the top rule for updating IDS rules.
I've stopped the service, enabled the service.   it will Not delete.

I can delete the dns block list cron below and recreate it without any issues.

I had several blocklists added.   I have now removed them entirely.   I am still utilizing DNS over TLS with Nextdns.    I can try just unbound if requested?   but it did the same thing yesterday with just unbound not forwarding

I uninstalled. and reinstalled the plugin,  rebooted the entire firewall.  qfeeds shows:  Database
Size: 138,912 on the widget.
reporting unbound:  234908
Size of blocklist

recreated the firewall rule on floating:
block
all utilized interfaces
direction in
destination Qfeeds malware IP
gateway is default.

on 2 different devices if I bring up " cherrypharm.com"
the website is not blocked and I get a warning on both browsers

wigdet and security > events are 0

This is supposed to work with Unbound according to the docs, but even after I checked "Register domain feeds", I cannot see anything w/r to Qfeeds in the Unbound blocklists, although both sets (IPs and domains) seem to be licensed.

Are You are running latest community?

At this time I do not see them listed under block list or extended block list.
If I am looking in the wrong area let me know

So the malware domains are listed/ downloaded but ignored?

Thanks
I exported both malware ip and malware domains to my device as a txt file.
As a free account. My device is running business edition opnsense and I am using Nextdns as my provider. DNS over tls.
All ip address visited within Firefox focus listed are blocked and show up as blocked in the console

If I choose and visit a malware domain they are not blocked. And my test device running Firefox focus warns me about the site could be malicious

I changed unbound to non forwarding, standard unbound

I am seeing the same issue.

I setup a floating rule
Block
Chose all interfaces utilized
Direction in
Destination  malware ip which is all that is available
And log
Gateway is default

Are my expectations incorrect that it should be blocking domains from what I exported and viewed?