Messages

It seems like limiting the threads would be more work than it's worth. Once the code base migrates to multi-thread, it seems like it would be worth just keeping that for all versions.

I believe that you're not assessing this correctly. With that new architecture all versions of the engine would use a multicore design and the maximum number of parallel threads is just a number that can be changed. And for home subscriptions and non-paying users this number would simply be set to "1". So the only way to avoid the jerks using a home subscription for their company is to tie the maximum number of threads to the subscription. Sadly home users apparently won't benefit at all from the new design.

Hi,

Yes, the expectation will be up to 10 Gbps with multicore support. Can you share the exact model of CPU?

So that means one has to pay up for the business edition to get multicore support and thus the 10 Gbps? At least that's what the roadmap at https://www.zenarmor.com/roadmap suggests.

To my great surprise I noticed that in the roadmap multicore support is a feature for business plans only. I'm "only" subscribed to the "Home" plan, but I would have expected that this feature would also come to that plan, even if I had a thread limit. In fact, if ZA is serious about attracting homelab users to the Home edition, I would also expect a limited form of multithreading in the free plan.

Apart from this I am wondering how serious that roadmap is with a 1 to 6 months timeframe. The problem is that this feature essentially pays back some technical debt, but isn't a flashy feature. I get it that ZA is a small company that needs to pay the bills and that those "flashy features" are much better at making that happen. Thus I'm concerned that multicore support will remain on the back burner for the foreseeable future.

I'm running OPNsense 26.1.2_5 and right now I'm using the CrowdSec and the ZenArmor plugins (the latter with a home subscription). Is Q-Feeds compatible with those, that means can I run Q-Feeds at the same time as the other two?

Also I'm trying to understand, what Q-Feeds does. My current understanding is that it works somewhat similar to CrowdSec in that it provides blocklists for IP-addresses that are deemed threats. Is that correct? If so, should I prefer Q-Feeds over CrowdSec (or vice versa) or does it make sense to run both?

Once again it is time to show my appreciation to all the OPNsense developers who are making the software better and better. I donated USD 50 to the project. I'm mentioning this, not to brag, but to encourage others to also donate to the project, if they can afford to do so.

The donation link (copied from the first post in this thread) is: https://opnsense.org/donate/

Happened again yesterday.

Only a restart of Unbound DNS would resolve the issue.

Yes  I had the same issue also a few days ago. All the sudden DNS resolution didn't work anymore, but a restart of Unbound within OPNsense got everything back to working again.

Looks like there is some fringe condition that causes Unbound to go into a freeze. I'm wondering how to debug this, when it happens again, so someone can find the root cause of this.

Please consider to include also multicore support in home plan, thanks in advance :-)

I, too, hope that they will do that. For differentiation purposes they could limit the number of threads in the home edition to something like 4 or 8 and allow unlimited threads in their Enterprise edition.

I'm not a enterprise but I could use the multicore support at home. Even if they don't want it on the base Home plan it would be nice to have it accessible to Homelabs.

Yes, multicore support is important to me as well, but I don't necessarily need 16 threads. So if they were to limit it to - say - 8 threads, I'd be perfectly okay with that.

Donated USD 50.00 to support the project. Thanks for a great piece of software.

Please consider to include also multicore support in home plan, thanks in advance :-)

I, too, hope that they will do that. For differentiation purposes they could limit the number of threads in the home edition to something like 4 or 8 and allow unlimited threads in their Enterprise edition.

I am not sure if this is possible for OPNSense, but a patreon would be kind of nice. That way we could make continual donation.

The problem with that is that Patreon's fees are much higher than Paypal's fees. The former apparently charges 5% to 12% and payment processing fees come on top of that.

Passively cooled:

https://mikrotik.com/product/crs309_1g_8s_in

I have this switch and I'm very happy with it. I'm running SwitchOS, instead of RouterOS for easier configuration.

We are already used to having to wait for Zenarmor to get right every time a new OPNsense update comes out.

If you are already used to it, why didn't you wait, until Zenarmor announces compatibility with OPNsense 25.1?

How can we know Zenarmore is ready for a new release so we can upgrade safely?

There is a dedicated Zenarmor board on this forum. They'll post there, when it is ready.

Unfortunately I'm still having trouble with Unbound on my OPNsense installation, this time it all the sudden was unable to resolve public hostnames after running fine since yesterday. So the symptom is different, but it's still Unbound acting up after running fine for a while (though this time the "while" only lasted about a day).

I ran the tests below from my Proxmox (Debian) box at 192.168.101.60 (hostname: prx-prod-01), with OPNsense as gateway/router and name server at 192.168.101.1. 192.168.101.0/24 is a VLAN on the LAN port of my OPNsense router.

Code Select Expand

root@prx-prod-01:~# nslookup opnsense.org
;; Got SERVFAIL reply from 192.168.101.1
Server:         192.168.101.1
Address:        192.168.101.1#53

** server can't find opnsense.org: SERVFAIL

root@prx-prod-01:~# nslookup opnsense.org 8.8.8.8
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   opnsense.org
Address: 178.162.131.118
Name:   opnsense.org
Address: 2001:1af8:4700:a1fa:3::2

root@prx-prod-01:~# nslookup google.com
;; Got SERVFAIL reply from 192.168.101.1
Server:         192.168.101.1
Address:        192.168.101.1#53

** server can't find google.com: SERVFAIL

root@prx-prod-01:~# nslookup google.com 8.8.8.8
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   google.com
Address: 142.251.46.206
Name:   google.com
Address: 2607:f8b0:4005:813::200e

root@prx-prod-01:~# ping 9.9.9.9
PING 9.9.9.9 (9.9.9.9) 56(84) bytes of data.
64 bytes from 9.9.9.9: icmp_seq=1 ttl=56 time=8.41 ms
64 bytes from 9.9.9.9: icmp_seq=2 ttl=56 time=11.1 ms
^C
--- 9.9.9.9 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 8.414/9.745/11.076/1.331 ms

Note: I pinged 9.9.9.9 above, because I have configured DNS over TLS from quad9 with the settings below. (I now realize that I should have used 9.9.9.9 as DNS server in my nslookup query as well. Oh, well, next time...)

Code Select Expand

Enabled  Domain   Address          Port   Hostname
  X               9.9.9.9           853   dns.quad9.net
  X               149.112.112.112   853   dns.quad9.net

After restarting the Unbound Service on my OPNsense box, things worked again:

Code Select Expand

root@prx-prod-01:~# nslookup google.com
Server:         192.168.101.1
Address:        192.168.101.1#53

Non-authoritative answer:
Name:   google.com
Address: 142.251.46.206
Name:   google.com
Address: 2607:f8b0:4005:812::200e

root@prx-prod-01:~#

I checked the logs at Services-> Unbound DNS -> Log File, but didn't notice anything re. my queries, except for a few "dhcpd expired" Notices for two Apple devices in my household, which do not have static ip addresses.

FWIW I have now enabled the following options in Services-> Unbound DNS -> Advanced (and then restarted the daemon):

Log Queries: Enabled
Log Replies: Enabled
Tag Queries and Replies: Enabled
Log SERVFAIL: Enabled

Is there anything else I should be doing in anticipation of the next occurrence of this problem? If it happens again, what should I be checking for?

For example:

I used nslookup in the past, when this problem occurred, and it did return my WAN address. After I "fixed" this as described above, it returned my LAN address once again (and also updated my local DNS cache to the LAN address).

By "my LAN address", you probably mean "OPN's WAN address"
By "my LAN address", you probably mean "Diskstation's LAN address"
I'm making assumptions. I might be wrong and then we're talking past each other...

Eric, thanks so much for bearing with me and responding again. Yes, you're absolutely right, that sentence slipped through the cracks and is totally confusing.

It should have properly said:

• I ran "nslookup diskstation" (on my Windows 10 PC) in the past, when this problem occurred, and it did return my WAN address. After I "fixed" this as described above, running another "nslookup diskstation" on my Windows 10 PC then returned the LAN address of my NAS (192.168.101.20) (and also updated the local DNS cache of my Windows Desktop PC to the LAN address of the NAS, when I use "ping diskstation").

You were also wondering, why nslookup would ever return my WAN address and I forgot to respond to that in my previous post. The reason is that for my domain <mydomain>.net I have configured a wildcard subdomain with Cloudflare, who provides the DNS resolution. This is what the A and CNAME records at Cloudflare for <mydomain>.net look like:

Code Select Expand

Type     Name            Content
A        ipv4            <ip-address>
CNAME    *               <mydomain>.net
CNAME    <mydomain>.net  ipv4.<mydomain>.net

(FWIW Cloudflare uses CNAME flattening to make the 2nd CNAME entry possible.)
If you are wondering, why this weird configuration with the ipv4 subdomain, this is because I don't have a static ipv4 address, so I use a DDNS service to set my ipv4 address dynamically and that works just better, if I do this on a subdomain.

With regards to "Register DHCP Static Mappings" setting in ISC:
As long as you do a host override in ISC (with IP equal to the static mapping), I don't understand the benefit of turning this on, because ISC already has all the information it needs to handle the DNS request.

Please correct me, if I am wrong, but I had thought that ISC is the DHCP server and Unbound is the DNS server and that this flag is necessary, so ISC registers the hostname and its static ip address with Unbound, thus enabling Unbound to resolve the hostname to the associated static IP address.
(Spoiler: This setting is indeed necessary, see my experiment below".)

If you specified a hostname in the DHCP static mapping (to override the one the NAS specifies), then this setting would enable ISC to become aware of this hostname to IP mapping. As mentioned before, it's my understanding ISC needs to be restarted after static mappings are updated (if they are relevant to ISC).
This said, a domain name will likely be added to hostname. Either OPN's domain name, or the domain name for the interface.

I have this unchecked: "Do not register system A/AAAA records". I have experimented enough with it to fully understand what that does, but I don't change defaults until I have to, and I didn't have to...

Ok, this motivated me to do a few experiments, this time using a Debian/Proxmox system (running Debian 12 [bookworm]) with the NIC's ip address 192.168.101.60) as my client to check the nslookup results.

I disabled the overrides in "Services: Unbound DNS: Overrides", activated the changes and then in "Services: Unbound DNS: General" I changed the settings to the following and then restarted the Unbound service:

Code Select Expand

Register ISC DHCP4 Leases: Checked
Register DHCP Static Mappings: Unchecked
Do not register system A/AAAA records: Unchecked

Then I ran nslookup on my Debian/Proxmox system:

Code Select Expand

root@prx-prod-01:~# nslookup diskstation
Server:         192.168.101.1
Address:        192.168.101.1#53

Non-authoritative answer:
Name:   diskstation.<mydomain>.net
Address: <my WAN IP address>

root@prx-prod-01:~#

So those settings didn't yield the desired result. Next attempt with "Register DHCP static mappings" enabled (followed of course by a restart of the Unbound service):

Code Select Expand

Register ISC DHCP4 Leases: Checked
Register DHCP Static Mappings: CHECKED
Do not register system A/AAAA records: Unchecked
Now this one works properly (remember the override is disabled):

Code Select Expand

root@prx-prod-01:~# nslookup diskstation
Server:         192.168.101.1
Address:        192.168.101.1#53

Name:   diskstation.<mydomain>.net
Address: 192.168.101.20

root@prx-prod-01:~#

It works!!! I'm not sure, why this didn't work, when I initially set it up, but I'm happy to see that it works now. Hopefully this will avoid the need for any future overrides. So it seems that activating the setting "Register DHCP Static Mappings" is indeed necessary.

I suppose we shall see if the issue with "nslookup diskstation" resolving to my WAN address will popup again in the future. For the moment though I'm happy with the result and I think that my overall configuration improved because of your feedback, @EricPerl. So thank you very much again for that.