Messages

Did you try to restart ZA engine after whitelisting it?

Regards,
S.

Hello,

What deployment you are using, driver, interfaces, DB, etc. ?
Did you check top output?

If its ZA doing this,
Best to contact ZA support directly via a ticket using the UI.


Regards,
S.

The counter increases only for non Port based aliases.

Regards,
S.

As already mentioned by others,
DO NOT test iperf using the FW as a client or a server, test THRU it but not TO it.

As well post output of command on FW as root.

Code Select Expand

netstat -Q
If Dispatch policy & IP is not hybrid you have it set wrongly. In that case set a tunable

Code Select Expand

net.isr.dispatch with value

Code Select Expand

hybrid
Restart your FW and check the command again.

You should see something like this

Code Select Expand

# netstat -Q
Configuration:
Setting                        Current        Limit
Thread count                        8            8
Default queue limit              2048        10240
Dispatch policy                hybrid          n/a
Threads bound to CPUs          enabled          n/a

Protocols:
Name  Proto QLimit Policy Dispatch Flags
ip        1  1000    cpu  hybrid  C--
igmp      2  2048 source  default  ---
rtsock    3  2048 source  default  ---
arp        4  2048 source  default  ---
ether      5  2048    cpu  direct  C--
ip6        6  1000    cpu  hybrid  C--
ip_direct    9  2048    cpu  hybrid  C--
ip6_direct    10  2048    cpu  hybrid  C--

Regards,
S.

Yea they should definitely revisit the docs.

But all round its like you said.
The benefit of emulated is that you can run it on HW that does not have a native support of Netmap in the first place.

Regards,
S.

The reason why the advised deployment is to use emulated Netmap driver is that the Devs on ZA and OPN did advances on the emulated netmap driver.

I run with it for a half year and in my case it outperforms the native one both in performance and latency.

Regards,
S.

Yop as Patrick said, the dashboard for all monitored systems is prereconfigured and standardized.
You have some options how to show it like cards or pages etc. But its standardized.

Beszels works in a HUB&Spoke model.
Where the HUB is the server that collects & visualizes metrics.
Where the Spoke is the server/system you collect from.

Beszel spoke can run as a binary (recommended) or in a docker container on the monitored system.
I run the HUB in an LXC as docker container and Spoke beszel clients are binaries.

All you need, is to install somewhere the HUB, in the HUB add new system and choose platform + deployment method.
Than you just copy over the command and execute it on the spoke.
In case of a binary its just command in case of a docker it will give you a compose or docker run command.

And yes, read the beszel docs, beszel automatically detects most of the stuff. If you however have multiple disks you need to add them extra for monitoring and SMARTs.

Regards,
S.

You are welcome,

Its really nice, and seamless to integrate. Basically I have all my LCXs, and whole network (expect mikrotik) in there.

Pic Of OPNsense ZFS pool monitoring.


Regards,
S.

I lately started to use Beszel, which is slowly replacing my needs for the Grafana stack.
The last update added as well ZFS pool monitoring.

It works on every platform even OPN(FBSD), Proxmox PVE, LXCs etc.
So I have one uniform pane of view for metrics.

Beszel has as well a PR open for a possibility to monitor a device via SNMP, when that happens I can as well put it into my mikrotik switch.

Regards,
S.

Block it via DNS,

If you use unbound on the OPNsense or Adguard, just choose a block list that targets gambling websites.

Regards,
S.

This sounds like the BUG with Intel iGPUs on Linux.
I have had this with one of my Proxmox nodes, where the issue was not during the reboot cycles but during usage of the iGPU and a deep power state.

Is it possible if not already that you try to disable the iGPU(but if you do that you may not have any video output) in BIOS or at least look at the C states and disable them for a test.

Note here that in order for intel to use Turbo, you need to have at least a C3 state.

Regards,
S.

Franco I did test this.

Tried with reboot of the OPN.
Now when the OPN boots up the sessions/states are under correct Rule labels/descriptions.

Regards,
S.

I get your point why you dont want yet make the repo public. But on the other hand, we have developers like Cedrik here communicating with the community and they can provide feedback and guideline to have it more standardized to OPN as such.

So even if your plugin has bugs, is not stable they can actually help you ;)

Regards,
S.

Oh thats nasty...

Thanks for providing the official ticket!

Regards,
S.

2. Would there be a way to have the desired behavior for block rules (i.e. "rate-limit logging without affecting rule matching"), probably as a feature request for OpnSense?
3. Should there be a more prominent web UI warning about this "unexpected" behaviour for block rules?

I think this is more for a feature request.
But its bothersome that the DDOS came actually within when you think about it. A DDOS attack was prevented by block rules yet it was so huge that a feedback loop via logging happened that caused practically a DDOS caused by the logging rules.

So the only feasible way, is to disable logging for block rules?

Regards,
S.