Messages

> There was a section where I had entered 10000 Mbp/s because there was no limit on the number of Mbp/s, and I had to retype this as 40000 Mbp/s or 4 Gbp/s, or use the command revert

Validations were added to the GUI to prevent entries above 4Gbps a long time ago, perhaps this configuration was from before this validation was added, and now crashes due to the backend service change.

Before this patch the shaping was fully handled by IPFW, so if it broke there, traffic would likely still pass through pf. However, since pf now handles this and crashes on the pipe configuration it's reasonable to assume this would lock up traffic as well. However, since it's an incorrect configuration in both scenarios the right thing to do is to ditch the 10Gbps pipes.

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.

Hi there,

I'm not aware of anyone working on this. If you could take a stab at it that'd be great. You don't have to submit a PR for every file, the PR should be limited to a single subject that the changes are trying to address, which may include multiple files.

That being said, if the PR is large, make sure you limit yourself to only the markup attributes (such as aria-hidden etc.) and don't introduce large changes in logic that need proper vetting - these should be submitted in a more isolated manner.

Cheers,
Stephan

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