Messages

My unit works like a charm; all services loaded and no issues whatsoever; hardware and running features as per signature.

For the sake of completeness, the microcode plugin is currently running in late load mode.

If you ever want to run the microcode plugin in early load mode, my understanding is that you need to upgrade the bootloader first, which essentially involves copying some files from one OPNsense directory to another. While I also run the microcode plugin with default settings (late mode IIRC), I did go through those steps, since I figured that it doesn't hurt to get my bootloader current.

My upgrade was similarly smooth (perhaps due to uninstalling the microcode plugin first) and I applaud the team for their ability to manage the ever shifting sands of their foundations (FreeBSD, etc.) and still provide a smooth experience with minimal manual steps (provided one reads the release notes, of course).

I would doubt that Deciso will "preconfigure" a new device, unless it's done under a consulting agreement and I assume you're not willing to pay for that. But I might be wrong...

You have two problems:
1. You're about 10 major releases behind (assuming the 6 month release cycle has been going on since 2021) and
2. you also want to switch to a different hardware.

#2 means they even with a config file from the current version you may have to do some manual editing, because the network interfaces might have different names on your new hardware. That's the smaller problem by far.

#1 is the real problem: I seriously doubt that you can jump 10 releases ahead and expect everything to work, since nobody will ever test for that. It might work for a very simple setup, but I wouldn't bet on it. So you either upgrade manually through each release, carefully reading all the release notes for any breaking changes and/ or necessary manual steps, or alternatively just get a new device and start configuring it from scratch. For a simple setup, this might be the easier path.

Whatever you decide to do, in the future you should keep your router software more current. I don't see OPNsense (or any router/firewall software for that matter) as something you can leave unattended for months on end, let alone 5 years.

I upgraded 5 weeks ago to 26.7.1_1 with Zenarmor, Crowdsec, QFeeds and Tailscale installed and I didn't have any problem with the upgrade, but I paid attention to the things below:

- There were some issues with the newer FreeBSD version in 27.1, which manifested when running the os-cpu-microcode-intel plugin. At the time the recommendation was to uninstall this plugin before upgrading, update the OPNsense bootloader and only afterwards reinstall the plugin. I suggest that you search the forum for this, since there were plenty of posts on this subject.

- If you have not yet migrated the firewall and NAT rules to the new UI, you will need to install a new plugin in 26.7 to be able to edit them. That plugin (os-firewall-legacy IIRC) is already available in later versions of 26.1, at which time I installed it. I waited with the migration until after the upgrade to 26.7, but it's probably better to execute that migration before the upgrade. I found the migration to be very easy, just follow the instruction in the migration tool and remember to go through all the tabs of that tool.

As always, read the release notes and download your config before the upgrade and (if you run ZFS, which I hope everyone does) create a snapshot.

My OPNsense box is a little over two years old and I had Zenarmor running for two years with a home subscription, using a local elasticsearch DB. The lifetime writes of my SSD are about 5.7 TiB, which is very mild compared to the rated typical lifespan of an SSD. So I suspect those who have a wear problem with their SSD have some additional features or logs turned on or turned to a higher logging level.

What made me discontinue my Zenarmor home subscription and ultimately uninstall Zenarmor were performance problems like the one I described here. I don't know, if those particular problems could have been solved by multicore support (single I don't know how granular the workload for a particular connection can be shared between different threads), but not having it or getting it means that I definitely would have to get a system with a CPU that has higher single-core performance than an Intel J6412. And that just didn't seem to be worth it.

So I would agree with the assessment that Zenarmor has a growing problem with positioning themselves. I understand that they don't want their free edition or their home edition subscription to cannibalize their commercial subscriptions (particularly in the SMB sector, where you might not need enterprise-level sizing). My assumption is that the main purpose of the free and home tiers is to have a showcase to home-labbers, in the hope that some of them would carry a positive experience into their workplace and thus increase Zenarmor's commercial subscription base. However as the home-labber experience turns less positive, that "carryover" effect is much less likely to happen. Thus I am surprised that they don't offer multithreading (with a limited thread count) in the free and home editions.

I don't know why, but now it's working.  I didn't change anything from my original post.
Was it time?  Was it a cache?  I have no idea.

What might have happened is that the state for internet access was still active in the firewall state table. You can clear individual states under Firewall -> Diagnostics -> States and under the "Actions" tab you can also reset the whole state table.

Thanks, Steve.

Sure, just run all connections through the firewall. I do this. In general you just need enough compute power in your firewall (varies by application) and appropriate connectivity (e.g. lots of ports on the firewall and/or virtual ports via one or more managed Ethernet switches).

Just to clarify: That would mean running every device directly into a port on the firewall, would it not? Because if you connect them via a switch, that traffic would never hit the firewall, since the switch would just pass it directly via the applicable port to the target device.

Of course now that I think of it, if you had a managed(!) switch, then you could put each device into a separate VLAN that you also created in OPNsense. Then there would be no intra-VLAN traffic and the switch would forward all traffic to OPNsense. Pretty extreme, but workable. Perhaps someone has a better idea?

I'm going to call this a win.  Been following the issue for some days now and the pf rate limiter is reliably capping the queries from the Roku group to just around 300/min, which corresponds perfectly to the 50 / 10s rate that I set in the rules.

That "50 per 10s" you set, is this per individual device (e.g. per source ip) or is this across all matches for that rule (so the matches for Roku1 would also count towards the rate limiting of Roku2 and vice versa)?

The repo on github is back online. IMHO that won't be the solution:

https://github.com/AdguardTeam/AdGuardHome/issues/8561

All, pay attention to Patrick's note here ^ about "dnsbunker.org" being blocked by DOH lists.  It is also blocked by this one, if not others:

https://dbl.ipfire.org/lists/doh/domains.txt

So you might need to add an override.  I don't know if the firewall itself is affected by DNSBL policy (maybe depending on your setup), so may or may not be an issue for you.

This is a kind of ironic situation.  Hopefully hagezi can settle on a host that is NOT also a DNS provider.

One way one might also circumvent this problem is to set the option "Do not use the local DNS service as a nameserver for this system" under System->Settings->General. Then OPNsense should go upstream for all its DNS requests, instead of using the local Unbound DNS and its blocklists.

The repo on github is back online. IMHO that won't be the solution:

https://github.com/AdguardTeam/AdGuardHome/issues/8561

Indeed, it won't be. Hagezi himself recommends a different mirror for his repo and the new patch points to that one, IIRC. But until that patch ships in a release and folks have updated to it, at least their old blocklist entry will work again (at least until the next github suspension).

On a side note, I am very surprised that github doesn't have a mechanism to prevent certain repos that are frequently subject to reporting spam from being blocked without human review. But perhaps I'm expecting too much...

https://github.com/opnsense/core/pull/10709

Thank you!  Is this going out soon or should we apply it as a patch for now?

As another option, you could switch to advanced mode in the blocklist entry, clear all blocklist types and enter the new URLs from the patch directly.

Just a quick glance at a home user, with 10G backbone, but currently nearly pinning a core with only ~600Mbps file transfer.  This is a Intel i3-9100  Please @Zenarmor re-consider this decision.  I've promoted this product since inception, this is a big thorn I'm struggling with. 

Make a separate route for heavy downloading/uploading which does not go through Zenarmor. Use Zenarmor for browsing and IoT.

A potentially stupid question: How would you do you bypass Zenarmor (the free version) for certain traffic to the WAN, if you want your client to otherwise go through Zenarmor (e.g. for regular web browsing)?

These being said, your CPU should support 1 Gbps through Zenarmor.

My OPNsense box has a Celeron J6412, which apparently has about half the single-core performance of the i3-9100 and I'm still getting 1.1 Gbps on an iperf3 test between two local VLANs, so the OP's network speed seems slow indeed. In my case that's with i226-V NICs, which can do do 2.5 Gbps, and with Zenarmor disabled I can indeed reach 2.3 Gbps. I'd recommend to the OP to check the download speed with Zenarmor disabled.

IIRC some folks on the forums had some success in increasing network speed by setting some tunables. There also is a guide for that here, though with my NICs I never had to do any tuning.

Yesterday I finally sat down and determined why the Youtube app on my Android Google Pixel Tablet was stalling for certain videos and determined that deactivating Zenarmor (by disabling the interface my tablet is connected to) solved the problem.

Here's the scenario:
- My OPNsense router (26.7.1_1) uses an Intel Celeron J6412 CPU.
- With Zenarmor enabled (on that interface) my tablet had a network speed of about 230 Mbit/s down and 33 Mbit/s up, so plenty of bandwidth for a 1440p video.
- With Zenarmor enabled, the 1080p version of the video would only stall very occasionally, but the 1440p version would stall constantly. Looking at the "Statistics for nerds" in the Android Youtube app, the 1440p video would load initially load only 6s into the readahead buffer and then stall, when the buffer goes to zero, then load another 6s and so on. With the 1080p video it would initially load more and then add to the readahead buffer, before it drops to zero. (Sometimes though, it would stall the first time and then increase the size of the readahead buffer during the subsequent load, which gave it enough buffer to initiate a followup http request before the read buffer goes empty.)
- When I disable Zenarmor, the initial readahead buffer is larger by several seconds, apparently giving the Youtube app time to add to it and enlarge it, before it ever goes to zero, so no stalls.
- Note: This does not happen for ALL Youtube videos, but just for a small subset of them. I am assuming it depends on the location of the Youtube CDN server that serves that particular video to me and may even change over time as videos get moved or replicated to different CDN servers. FWIW the 1440p version of this particular video had the problem for me (location: San Francisco Bay Area, South Bay).

I understand that the Youtube app is obviously programmed in a "suboptimal" way, e.g. it doesn't increase the readahead buffer, when it stalls at the 1440p videos with Zenarmor enabled, and it doesn't allow to set a size for a minimum initial readahead buffer. Still I doubt that Google will do anything about that (though I will report this problem).

Yet in the meantime it seems that the only solution is to disable Zenarmor, at least in the free version. (The paid version has options to exclude clients or domains from Zenarmor's processing that might mitigate this problems.) Or buy a new router with a CPU that has much higher single-thread performance... (Probably not.) Did anyone ever encounter a similar problem and found a better solution?

AFAIK that's a very old RealTek NIC Chip used as Onboard NIC for a lot of devices and might be declared as EOL by the people who build the FreeBSD Kernel so you could check that and see if there is a solution available for those who want to use it anyway ?

Yes, it's old - that's why I'm using this machine as a firewall box rather than a general-purpose computer.
I suppose it's *possible* that the upstream devs went to the work of removing support for some RTL8111 flavors while leaving other RTL8111 flavors supported, but that seems implausible.

You could test, if native FreeBSD (15.1 IIRC) boots on your system (e.g. from a USB flash drive) with network drivers enabled. If it doesn't, then you'd need to take your problem upstream.

Does your system have a free PCIe slot? Then buy a cheap used NIC (e.g. on eBay) that is known to work well with FreeBSD and put it in your system. (I don't have such a list of NICs, but I'm using Intel i226-V on my OPNsense and it's been working without a problem.)

Once again, the great thing about standards is that there are so many of them. :/

But wait, there is more! I had a similar problem in my network that non-fqdn requests from my Windows 11 client to my TrueNAS server didn't work properly. The culprit here was that apparently Windows 11 uses mDNS by default. And the TrueNAS server had two network interfaces and returned two IPv4 adresses, but Windows picked the wrong one. I had to disable the mDNS server on TrueNAS to get this to work.

Wanted to drop in a status update. I'm not ready to declare victory quite yet, but this is the longest I've gone without an incident in quite a while. Possibly it was an issue with coreboot? Fingers crossed. I'll give it another week and then consider this resolved.

I am also running a Protectli (VP2420) with I226-V NICs and AMI-Bios and never had any stability problems. While I like the idea of coreboot as an open source solution, I have never used it on my two Protectli units and issues like the one you describe make me even less likely to try it in the future.