Messages

A CARP VIP got deleted here while an IP alias was still present with the same VHID group, this should be a validation.

I'll add a patch that bails if no primary CARP is found, but your leftover IP alias should have its VHID group stripped as well.

Hi,

The development documentation is not live yet, but you can find it here: https://github.com/opnsense/docs/tree/dashboard.

Cheers,
Stephan

I did spin it as well in a VM, and I must say I am impressed, that new dashboard is fluid, also in regards of resources drain, I don't see anything significant.

Well done OPN devs.

Much appreciated! The design focuses on efficiency as much as possible in contrast to the old dashboard, which had a tendency to be slow on page load.

When you consider resource drain, there's always going to be a cost to data collection. Things are now better with the streaming implementations which prevent backend processes from having to start/stop all the time - reducing a lot of the overhead.

While the roadmap for the dashboard for 24.7 is set (some widgets have yet to be added), new ideas for widgets are welcome of course. For anyone willing to have a go at this themselves, the development documentation will be synced around the time of the 24.7 release.

Cheers,
Stephan

I just hope that will not be 'heavy' on CPU like the current one....

Which CPU, client or firewall?

In general, CPU/GPU usage has increased somewhat on the client side (neat graphics aren't free), and reduced on the firewall side.

Cheers,
Stephan

Thank for checking on the mobile too.

Yes that may be uncomfortable I am logging a lot via phone when I am on VPN or not on my PC.
Hopefully here will be some lock function or something to prevent widget movement when scrolling.

Regards,
S.

Sure, here you go: https://github.com/opnsense/core/commit/34cafe3e9835cb48c41ad063d2aba2700e7f701a

I hadn't done extensive tests on touch yet other than increasing the responsiveness with auto-sizing widgets based on screen size, but this is an obvious one.

Thanks for the feedback! The other points have been noted as well.

Cheers,
Stephan

Probably best to inspect the certificate chain in your browser to see what's being returned.

The system log (system -> log files -> general), under process "kernel" should reveal if the driver has anything to say about it. The fact that the LEDs are not coming up shows that this is a low level linking issue. Either there is no other end, or the module is not compatible with the intel chipset.

the Max-Payload is a bit weird.. have you configured an MTU on the parent interface? If so, try removing it

What do you suggest putting as a prefix for the log statement besides just "dnsbl_module:"?  I'm currently using Result but not sure if there's anything better.

Perhaps "logger:" would suffice, it should only be unique within the scope of Unbound. I need to think a bit on this, but this can always be reviewed in the PR.

I have it working locally.  Now I just need to figure out the config setup to add a UI toggle.

Most of the steps required to build this are documented: https://docs.opnsense.org/development/frontend.html. Luckily the general page was already migrated to MVC, so this should be plug&play.

What might not be obvious is the communication to the dnsbl_module itself. There's a concrete example here: https://github.com/opnsense/core/blob/master/src/opnsense/service/templates/OPNsense/Unbound/core/dnsbl_module.py#L167, in combination with https://github.com/opnsense/core/blob/master/src/etc/inc/plugins.inc.d/unbound.inc#L413

I'm not sure I follow either, I assume you're customizing the plumbing to fit your needs? Did you try to send the necessary info straight to syslog from the dnsbl_module? A simple log_info() call sends it straight to the resolver log.

My original point is that there's no hook available for you to inject custom code which can survive upgrades for your use case. You're welcome to submit a PR if you think this is a useful addition. In this case make sure the feature is included as an option with a warning that this impacts performance.

I'm happy to provide feedback if you plan on implementing something like this.

I knew about the actions and API and had already looked at that but I'd prefer to have the info inside the logs themselves instead of having to correlate from an additional source.

This one is going to be rather difficult with the plumbing that's available.

I have query and reply logging turned on but it doesn't provide me any information about the blocklists.

This information can be used to determine if a domain was blocked, which I believe to be your original question, but it indeed does not correlate anything to configured blocklists. You'd still have to build your own source for that.

Perhaps it's an option for you to see if you can send some bulk data to syslog using the actual logger: https://github.com/opnsense/core/blob/master/src/opnsense/scripts/unbound/logger.py. All the information you require is in there.

Hi,

Yes, the DNSBL implementation changed. The Unbound configuration method had the drawback of having a significant reload time, regardless of whether this was done dynamically or statically. The blocklists themselves are still being preprocessed by https://github.com/opnsense/core/blob/master/src/opnsense/scripts/unbound/blocklists.py

You can check out the following actions: https://github.com/opnsense/core/blob/master/src/opnsense/service/conf/actions.d/actions_unbound.conf#L19-L47 which handle the reporting end, but can also be utilized to query some details. DuckDb is used to store queries up to a maximum of 7 days, so as to not needlessly fill up disk space.

For logging purposes you can also consider enabling logging in Unbound -> Advanced, we've done a bit of work there to better differentiate between query/reply if you want to run the data through syslog.

Cheers,
Stephan

Can you try

Code Select Expand

# opnsense-patch fb2d2f6

Might've been a spacing issue, but this would require isc-dhcpd to suddenly deviate from the usual format. If this doesn't solve the issue I'll likely need the original file (not a paste) to be able to reproduce it.

Cheers,

Stephan

Devices showing as offline, missing interfaces and general readability issues should be addressed in:

https://github.com/opnsense/core/commit/a2b9144233df873c24ec3360267499b41bbe6444
https://github.com/opnsense/core/commit/c605175d85b7b6f9a70e9adbb2eedac8f85ba022
https://github.com/opnsense/core/commit/a88fae84f6c670e57545bdce3b752f5c43391b64

If you want to test:

Code Select Expand

# opnsense-patch a2b914423 c605175d8 a88fae84f

Cheers,
Stephan

The format is governed by isc-dhcpd, which in the legacy codebase was always assumed as a base 16 integer.

Can you try

Code Select Expand

opnsense-patch 23318015b 4ec97df4c

https://github.com/opnsense/core/commit/23318015b2abc075a3bf506533da07ea740d2250
https://github.com/opnsense/core/commit/4ec97df4c475223b31df31cb61e78f1bdb71d789

Cheers,
Stephan