Recent posts

#1
26.7, 26.10 Series / Re: WAN PPPoE IPv6 default rou...
Last post by Taomyn - Today at 10:51:06 AM
Quote from: franco on November 05, 2026, 07:47:49 PMWell these pop out immediately:
> Sending Information Request on vtnet0_vlan250
> Sending Information Request on vtnet0_vlan100
What's their purpose? There could be bugs regarding this. I've never seen anyone using this feature in the last decade. Functionally it's not supposed to do anything other than fetching nameserver information.
> /usr/local/etc/rc.newwanipv6: IP renewal starting (reason: request, address: fe80::be24:11ff:fe78:54d5%pppoe0, interface: wan, device: pppoe0)
This looks good...
> Bypassing address release because of -n flag
This is a dangerous setting from a long time ago.
> /usr/local/etc/rc.newwanipv6: ROUTING: entering configure using wan, lan

Routing for IPv6 never produces any default route, which means FreeBSD decides what the default route is based on the RAs it sees, likely from one of the INFOREQ calls.  Why WAN doesn't even bother adding an IPv6 default route I'm not sure of.
Cheers,
Franco
Cheers,
Franco

For vtnet0_vlan100 + vtnet0_vlan250 are just two VLANs on my local network configured in Interfaces: Devices: VLAN, they're quite old although I no longer use vlan250 so I could remove that at some point, and vlan100 is used by one of my WiFi APs to take guest traffic direct to the Internet.

For the -n I have no idea about this, where would this be coming from and what should I do?

It also seems that my workaround has stopped working or my ISP has made another change and broken it, so now I need to re-do my diagnosis again.
#2
26.7, 26.10 Series / Re: No link with Intel E810 on...
Last post by bugacha - Today at 10:44:17 AM
Quote from: tuto2 on November 09, 2026, 04:47:51 PM
Quote from: bugacha on November 09, 2026, 04:33:56 PMhttps://reviews.freebsd.org/D60168

Fix was committed to master and MFCed to stable/15.


Fix is in 26.10, separate issue.

hey mate, your FEC thing is not related to what this thread is about. You should really create a new thread about it.

ice driver fix for the original problem is soon going to be in stable/15.
#3
26.7, 26.10 Series / Re: No health graphs since 26....
Last post by tuto2 - Today at 10:35:00 AM
Quote from: szty0pa on November 09, 2026, 03:36:00 PMI saw that there had been changes to this in the update.

Only on the development version. Are you currently on that?
#4
Good progress, and thanks for all the screenshots.

1. About 127.0.0.53. That is not your firewall: it is the local DNS stub of your Linux laptop (systemd-resolved). It forwards to whichever DNS servers your connections give it. To ask the firewall directly, run: nslookup example.com 192.168.20.1 (and resolvectl status to see which servers each connection uses).

2. The leak test showing ISP-like servers. If the laptop is also connected via Wi-Fi to your ISP router, systemd-resolved can send queries to that router's DNS. Disconnect Wi-Fi (or any other connection), then run dnsleaktest again. Also check that your browser isn't using its own DNS (e.g. Firefox "DNS over HTTPS"). And check in Services > Dnsmasq DNS & DHCP that PERSONAL20 hands out 192.168.20.1 as the DNS server.

3. Proton gateway "active". That is fine. "(active)" only marks the default gateway, which is WAN. Your VLAN rules force traffic through Proton, as shown by "Proton End point" on the IP test. Only the firewall's own traffic uses WAN.

4. Xbox. One thing at a time: set the Xbox DNS manually to 1.1.1.1 (as on your phone). If the homepage and Game Pass load, the problem is DNS: check Services > Unbound DNS > Blocklists (disable them) and try disabling DNSSEC for a test. If it still doesn't load, it may be the tunnel MTU: on Interfaces > WgProtonVPN set MSS to 1380 and test again.

Please take a config backup before each change, and tell us the result of each step.

Sergio
#5
26.7, 26.10 Series / Re: Is sloppy state tracking a...
Last post by FlyveHest - Today at 08:32:53 AM
Quote from: pfry on November 08, 2026, 02:50:54 PMFrom your subject I figured you were talking about "Bind states to interface". Personally I'd dig into why normal "State Type: keep state" does not work for you. It suggests a client/server TCP issue, packet loss, and/or partial bypass of the firewall. Packet loss at least should be obvious - it kills performance. I can't think of a practical security exploit for sloppy state offhand, but that doesn't say much.

Sorry for not getting back, I finalized my setup yesterday evening and during that I have changed some routing issues that I had when I wrote this entry, which I think may have been the cause of the sloppy state issue (packages leaving through one interface but returning through another)

I will check up on it tonight.
#6
Since 26.7.8 you can paste your API Token at the end of the Download Section.

Please see the release notes of 26.7.8:

Quoteintrusion detection: add abuse.ch API token input

Please be aware that abuse.ch has at the moment some throttling issues. Some Rulesets are not loaded on my 4x Daily schedule. Not a big deal for most of us.

Regards,
Wrigleys
#7
German - Deutsch / Re: Netzwerk, Security & Firew...
Last post by vina010 - Today at 06:06:34 AM
It's great to see this community continuing to grow and making room for people with different schedules. Having a later evening option sounds like a good idea, especially for those who have family commitments during the day.
The informal format is also a nice way for OPNsense users to exchange experiences, discuss technical challenges, and learn from each other. Hopefully, more members will join these sessions!
#8
Zenarmor (Sensei) / Re: Am I missing something or ...
Last post by mb - Today at 05:48:51 AM
Hi everyone, Murat here, founder of Zenarmor. I want to respond to this thread directly.

We read these forums, and we read every message. I'd rather address the concerns here openly than let people guess at our intentions. There are a few separate things tangled together in this thread, so let me take them one at a time.

1. The OPNsense plugin is not going anywhere.

Let me be direct: we are not killing the OPNsense plugin. It is actively being developed and maintained, it continues to receive new features and engine updates, and OPNsense is and will remain a primary platform for Zenarmor. It remains a product we invest in.

2. The Business Next-Gen Firewall plan still exists.

The Business NGFW plan remains available for purchase and renewal; it's just not on the pricing web page, since we're actively promoting unified plans (See below for why we are promoting unified network security). Having said that, if you log into Zenconsole and try to purchase a subscription, you'll see it offered as an option, and our FAQ says the same. Reach out to us or your partner if it's all you need.

3. What we're actually building, and why the plans changed shape.

The plan restructuring makes more sense once you see what we're trying to do as a product company, so let me clarify:

Nobody works 100% from the office anymore. The same employee is on the office LAN in the morning, a café Wi-Fi at lunch, and their home network in the evening; and they expect everything to just work from all three. Meanwhile some of your workloads have moved to several dozen cloud VPCs. The network you're responsible for is no longer in one place; it's wherever your users and assets happen to be at the moment.

The traditional way to secure that is a separate product for each piece: a firewall for the office, a VPN or ZTNA product for remote users, something else for cloud egress, and then you spend your time making them agree with each other: separate policies, separate logs,etc etc. For a large enterprise with a security team, that's an annoyance. For a small company where one person runs all of IT, it's the reason the laptop on café Wi-Fi usually just goes unprotected... not because anyone decided that, but because the stack to cover it was too expensive and too much work to operate.

Our answer is unified network security that deploys anywhere, instantly.

Unified means the functions are one product: NGFW, web and content filtering, TLS inspection, IDS/IPS, CASB, secure web gateway, zero-trust network access, mesh VPN, one engine doing all of it under one policy and one console.

Deploys-anywhere means that one engine runs wherever your network is: on your OPNsense gateway at the office, in a cloud VPC in front of your workloads, on the laptop that's at a café right now. Same software, same policies, all locations.. so covering a new place is a deployment step done in minutes. One security fabric across the office, the cloud, and everywhere your people actually work.

Our enterprise plans — SSE, ZTNA, SASE — were our first answer to this, and they're priced very competitively against other products in that category. But as those plans got traction, we kept hearing the same thing from partners and smaller businesses: the architecture is right, now make it affordable on a small-company budget.

That feedback is where the Unified plans came from. This decision is the output of a year of those conversations.

And to my knowledge, no other vendor offers this at a small-business entry point. The single-vendor SASE products this architecture competes with aren't built to be bought small: for example, FortiSASE's standard minimum order is 50 user licenses and the cloud-SASE vendors typically come with minimum annual commitments that start where a small company's entire IT budget ends.

The Unified plans are that same exact architecture, priced as one product: small company can justify. A per-user subscription that covers the gateway, the cloud deployments, and the endpoint agents together; because to us those aren't three products, they're three places the same software runs.

For instance, one of our partners was evaluating Fortinet for gateway security plus Tailscale for connectivity; they deployed Zenarmor (on OPNsense on the gw) instead because Unified Secure Plus cost about the same as Tailscale alone and covered both.

That's the product and that's what we want to achieve. And we're not the only ones who think this architecture is where the market is heading  (e.g., EMA named Zenarmor a Vendor to Watch in its 2026 SASE report & Zenarmor earning several awards throughout the year).

4. On the pricing math.

With Unified Secure, we're not actually increasing prices. When we built the original NGFW device tiers, we priced them on an assumption of roughly 2.5 devices per user.. and that ratio included the non-user devices (IoT, printers, etc.) on a typical network, because under the old plan everything with an IP/MAC counted toward your tier: workstations, but also printers, cameras, and IoT. So a "50-device" plan was, in our planning, a ~20-user plan carrying its share of IoT overhead.

The entry NGFW tier was $50/month for 25 devices; Unified Secure starts at the same $50/month for 10 users. Same money. What changed is the unit, and the unit change is an improvement in most use-cases: we stopped billing non-user devices entirely. One license covers two actual user devices, and a device only counts as a user device if it generates real traffic through Zenarmor, i.e. 3,000+ sessions on at least two days in a month. Printers, cameras, switches, and quiet servers fall below that and are simply not charged.

Where the two plans start to land apart is at the margins. A very lean network like one workstation per person, almost nothing else on the wire,  comes out $120–220/yr higher on Unified Secure than on the old 50-device tier, roughly a dollar per license per month. I won't pretend that's zero. But that dollar buys things the NGFW plan never had at any price: mesh VPN and zero-trust access, desktop endpoint agents that cover your people when they work off-network, centralized reporting and management. A mesh-VPN product alone typically costs more per user than the entire Unified Secure plan.

Additionally, under Unified plans you no longer pay extra for the HA gateway: every Unified site license now includes two gateway keys, active and passive, so an HA pair costs the same as a single gateway. Under NGFW pricing, an HA pair meant paying roughly 40% extra for the second node. If you run HA, that change alone typically outweighs the per-license delta.

But again: if this is not what you want, the Business NGFW plan is still here.

5. On being "the cheapest."

I want to be honest about this rather than tell everyone what they want to hear. Our goal is not to be the cheapest option on the market. if you're comparing us with free, open-source blocklists, we will never win that comparison, and those are also different tools solving different problems. Our goal is to be the best unified network security solution at the best possible price for what it does. For some people here, a free stack, or even our free edition is genuinely the right answer, and that's fine. For those who want one integrated engine instead of maintaining and correlating multiple disparate utilities, the value we provide is hard to beat... and the NGFW plan remains there for everyone in between.

Thanks for caring enough to post about this. It beats silence.
#9
I tried enabling ThreatFox and URLHaus from abuse.ch but they show as "not downloaded" in the Last Updated column in the Surricata administration page. OTOH, Feodo Tracker and SSL Fingerprint Blacklist show current updates. I think this related to messages that these now require API keys to download:

https://threatfox.abuse.ch/export/
https://urlhaus.abuse.ch/api/

Unfortunately, it seems like there is no way to add a key after obtaining one.
#10
General Discussion / Re: How do I know if a non-off...
Last post by franco - November 09, 2026, 10:35:43 PM
> I asked a genuine question

Fair enough.  I gave a genuine answer and you scolded me for it.  ;)


Cheers,
Franco