"Recent posts
#1
Hardware and Performance / Re: latencyspikes of seconds...
Last post by cookiemonster - July 06, 2026, 11:39:50 PMI suppose this is now answered with more detail here https://forum.opnsense.org/index.php?topic=52307.msg269775;boardseen#new so no need to repeat.
#2
Development and Code Review / Re: vibecoded plugin
Last post by OPNenthu - July 06, 2026, 11:28:51 PMAn almost poetic distillation of the times. What you guys captured in just three posts is stunning.
#3
Development and Code Review / PROBan Progressive banning plu...
Last post by FreeFlite - July 06, 2026, 11:27:44 PMHi all,
Sharing a plugin I've been building — ProBAN (Progressive Ban).
Instead of fixed-tier, fail2ban-style blocking, ProBAN grows an attacker's ban the more they knock and decays it while they're quiet. A drive-by scanner earns a 30-second timeout; a relentless one digs itself into a ban measured in days, then months — no tiers to tune.
Banned IPs can be silently dropped, funneled into a zero-window tarpit that burns their time and sockets (it never reads their input — zero parser attack surface), or redirected to a honeypot on ports you choose. All live under Reporting → ProBAN:
A few things I cared about:
Status: v0.1.0-rc.1, validated live on OPNsense 26.1 / PHP 8.3. It's a release candidate — testers, review, and honest feedback all very welcome.
Plugin: github.com/Freeflite/PROBan
Tarpit companion (Rust): github.com/Freeflite/TinyPit
Thanks for taking a look!
Sharing a plugin I've been building — ProBAN (Progressive Ban).
Instead of fixed-tier, fail2ban-style blocking, ProBAN grows an attacker's ban the more they knock and decays it while they're quiet. A drive-by scanner earns a 30-second timeout; a relentless one digs itself into a ban measured in days, then months — no tiers to tune.
Banned IPs can be silently dropped, funneled into a zero-window tarpit that burns their time and sockets (it never reads their input — zero parser attack surface), or redirected to a honeypot on ports you choose. All live under Reporting → ProBAN:
A few things I cared about:
- IPv6 at full parity — with evidence-based /64 aggregation: ban /128s, escalate to the whole /64 only after N distinct offenders, so a shared-hosting /64 keeps its innocent neighbours.
- VPN-friendly — UDP tunnels (WireGuard/IPsec) are invisible to it, and a "protected ports" setting keeps OpenVPN-over-TCP and other inbound services from being mistaken for attacks.
- Safe by design — the tarpit target is reflection-locked to private/LAN/VPN addresses and tamper-checked every run, so it can't be aimed at a victim.
- Built the proper OPNsense way — settings in a model XML (config.xml), a configd/rc.d service, config.json from a template, firewall rules owned by a plugins.inc.d hook.
Status: v0.1.0-rc.1, validated live on OPNsense 26.1 / PHP 8.3. It's a release candidate — testers, review, and honest feedback all very welcome.
Plugin: github.com/Freeflite/PROBan
Tarpit companion (Rust): github.com/Freeflite/TinyPit
Thanks for taking a look!
#4
Development and Code Review / Re: vibecoded plugin
Last post by Vectralis - July 06, 2026, 10:17:46 PMWell idk, the reason i didn't make the effort to code it is because i don't know how to code
#5
Development and Code Review / Re: vibecoded plugin
Last post by Patrick M. Hausen - July 06, 2026, 10:16:09 PMIf you did not make the effort to code it why should anyone make the effort to review it?
#6
Development and Code Review / vibecoded plugin
Last post by Vectralis - July 06, 2026, 10:12:27 PMhello
i vibecoded a opnsense plugin because there was a feature i found missing and i really needed it fast.
can someone maybe test/check if the plugin is actually working and bug free?
Thanks in advance
github repo:
https://github.com/VulcanoSoftware/opnsense-backup-plugin
i vibecoded a opnsense plugin because there was a feature i found missing and i really needed it fast.
can someone maybe test/check if the plugin is actually working and bug free?
Thanks in advance
github repo:
https://github.com/VulcanoSoftware/opnsense-backup-plugin
#7
Zenarmor (Sensei) / Re: Free Edition: Policy Based...
Last post by sy - July 06, 2026, 10:10:49 PMHi,
Thank you for choosing Zenarmor and reaching out to the community! We completely understand your perspective; it is highly practical to prefer using the "Exempted Networks" feature for flexibility in network management.
The logic behind why these two features are separated into different tiers comes down to how they function technically:
Policy-Based Whitelisting (Free Edition): With this method, traffic is still processed and analyzed by the Zenarmor engine. It simply allows specific items (like websites or IPs) based on your custom rules. Since the traffic remains within the filtering mechanism, it is available in the Free edition.
Exempted VLANs & Networks (Premium): This feature completely bypasses the Zenarmor engine. Traffic coming from the VLANs or networks you select goes straight through without being analyzed or processed by Zenarmor at all.
Because this advanced bypass control and total traffic exemption go beyond the standard filtering capabilities of the Free edition, it is included in our premium features. To unlock and use this feature, a minimum of a Zenarmor Home Edition license is required. The Home license is specifically designed to be a budget-friendly option for home users who need these advanced networking capabilities.
Best regards
Thank you for choosing Zenarmor and reaching out to the community! We completely understand your perspective; it is highly practical to prefer using the "Exempted Networks" feature for flexibility in network management.
The logic behind why these two features are separated into different tiers comes down to how they function technically:
Policy-Based Whitelisting (Free Edition): With this method, traffic is still processed and analyzed by the Zenarmor engine. It simply allows specific items (like websites or IPs) based on your custom rules. Since the traffic remains within the filtering mechanism, it is available in the Free edition.
Exempted VLANs & Networks (Premium): This feature completely bypasses the Zenarmor engine. Traffic coming from the VLANs or networks you select goes straight through without being analyzed or processed by Zenarmor at all.
Because this advanced bypass control and total traffic exemption go beyond the standard filtering capabilities of the Free edition, it is included in our premium features. To unlock and use this feature, a minimum of a Zenarmor Home Edition license is required. The Home license is specifically designed to be a budget-friendly option for home users who need these advanced networking capabilities.
Best regards
#8
High availability / Re: CARP with DHCP on WAN
Last post by toreamun - July 06, 2026, 10:01:38 PMThis thread is about exactly the problem I had - running a CARP WAN when the ISP hands you the address over DHCP (mine is a CGNAT fiber link). I ended up solving it as a proper OPNsense plugin rather than a script, in case it's useful to anyone here.
Approach: the scripts in this thread up/down the WAN interface (and juggle MAC spoofing / write_config) on each CARP transition. This plugin does something different - it keeps a dedicated DHCP lease alive for the CARP VIP's virtual MAC (00:00:5e:00:01:<vhid>). Whichever node is MASTER answers on that MAC and holds the lease, so the ISP hands the WAN address to the active node. No interface up/down, no MAC-spoof juggling, no write_config on every event.
Prerequisite: your ISP's DHCP server has to be willing to hand out a lease to the CARP VIP's virtual MAC - i.e. it can serve more than one active address on your WAN (your box already has its own, the VIP needs an additional one). If your ISP binds the line to a single MAC / a single address, this approach won't work. In my case the ISP gives the VIP MAC its own DHCP reservation.
What it gives you over a raw script:
- Native plugin with a GUI (Interfaces -> Virtual IPs DHCP) - no editing PHP/shell
- Signed releases + a one-line verified installer
Install (OPNsense 26.1, as root):
The installer verifies the release signature against the committed public key before installing.
Repo: https://github.com/toreamun/opnsense-plugins
Full disclosure: my own project, currently v1.0, and tested mainly in my own setup (CGNAT fiber, active/passive OPNsense pair) - not yet widely deployed. Feedback and issues very welcome, happy to answer questions here.
If you give it a try, I'd love to hear how it goes — drop a comment or open an issue on GitHub. If there's enough interest I'm considering submitting it to the official OPNsense plugins repo.
Approach: the scripts in this thread up/down the WAN interface (and juggle MAC spoofing / write_config) on each CARP transition. This plugin does something different - it keeps a dedicated DHCP lease alive for the CARP VIP's virtual MAC (00:00:5e:00:01:<vhid>). Whichever node is MASTER answers on that MAC and holds the lease, so the ISP hands the WAN address to the active node. No interface up/down, no MAC-spoof juggling, no write_config on every event.
Prerequisite: your ISP's DHCP server has to be willing to hand out a lease to the CARP VIP's virtual MAC - i.e. it can serve more than one active address on your WAN (your box already has its own, the VIP needs an additional one). If your ISP binds the line to a single MAC / a single address, this approach won't work. In my case the ISP gives the VIP MAC its own DHCP reservation.
What it gives you over a raw script:
- Native plugin with a GUI (Interfaces -> Virtual IPs DHCP) - no editing PHP/shell
- Signed releases + a one-line verified installer
Install (OPNsense 26.1, as root):
Code Select
fetch -o - https://raw.githubusercontent.com/toreamun/opnsense-plugins/main/install.sh | shThe installer verifies the release signature against the committed public key before installing.
Repo: https://github.com/toreamun/opnsense-plugins
Full disclosure: my own project, currently v1.0, and tested mainly in my own setup (CGNAT fiber, active/passive OPNsense pair) - not yet widely deployed. Feedback and issues very welcome, happy to answer questions here.
If you give it a try, I'd love to hear how it goes — drop a comment or open an issue on GitHub. If there's enough interest I'm considering submitting it to the official OPNsense plugins repo.
#9
26.1, 26,4 Series / Re: a few hundreds of messages...
Last post by meyergru - July 06, 2026, 10:00:30 PMCorrect.
#10
26.1, 26,4 Series / Re: a few hundreds of messages...
Last post by thelittleblackbird - July 06, 2026, 09:59:54 PMQuote from: meyergru on July 06, 2026, 09:14:34 PMI mean that it is probably the CPU waiting for I/O operations to finish because the storage subsystem is struggling. With NVMe storage, writing very small, frequent log lines leads to heavy 'write amplification' due to the large underlying flash block sizes, causing significant latency spikes.
The fact that reducing the logging activity resolved the issue completely confirms the storage bottleneck theory. When the logging was set to high, the frequent, small writes to the NVMe caused massive write amplification and continuous synchronous I/O blocks.
In FreeBSD/OPNsense, such a severe storage backlog causes 'Lock Contention' in the kernel and forces an influx of Software Interrupts (SWIs) to manage the blocked I/O buffers. This is why the IRQ handler threads (intr) ran hot: they weren't just processing network packets, but handling the massive overhead of a stalling filesystem trying to commit log rows to a struggling SSD. Turning down the logs broke this vicious cycle.
got it, then it means that if instead of writing to disk, I set the option to write to ram or to send the message to another equipemetn, as you suggested, i should be able to combine a "high" level of verbosity with a low cpu usage, right?
if it is so, i will tested it tomorrow and see what is happening.
