Recent posts

#1
26.1 Series / Re: New features
Last post by newsense - Today at 08:23:55 AM
FWIW I have 4 FWs on RACK since December and all are running fine on FreeBSD14.3/OPNsense25.7/26.1
#2
General Discussion / Re: opnsense-revert opnsense f...
Last post by franco - Today at 08:19:06 AM
Not a fan as we're mixing and matching responsibilities. opnsense-revert works with pkg. It doesn't know about config.xml and shouldn't.

That's also a reason why OPNsense.conf shouldn't be known to opnsense-revert. opnsense-update is the only service that really cares about it to make meaningful operations.

Do you want to try a PR in update.git?


Cheers,
Franco
#3
General Discussion / Re: AmneziaWG on OPNsense and ...
Last post by franco - Today at 08:15:19 AM
As mentioned in the tools PR we've always supported such technologies in the past.

I'll be honest here what I find odd about it:

Some of these replies and tickets sound like AI and/or a concerted effort to push the solution into OPNsense and I don't find myself appreciating that approach. The situation we find ourselves in is unlike any other solution we've integrated since.


Cheers,
Franco
#4
26.1 Series / Re: New IPv6 address assignmen...
Last post by franco - Today at 08:13:00 AM
Nope, this is about behaviour of core, how it already configures dhcp6c and then the server does something else and wanting the core to make a better "guess" after the fact. From a procedural standpoint that's not trivial to integrate if it even makes sense in the overall architecture.


Cheers,
Franco
#5
26.1 Series / Re: New features
Last post by franco - Today at 08:10:10 AM
Quote from: xpendable on April 08, 2026, 08:18:59 PMThe ability to use the RACK TCP Stack would be nice and might be beneficial to some.

https://github.com/opnsense/core/issues/9452
https://klarasystems.com/articles/using-the-freebsd-rack-tcp-stack/


You phrase it in such a way that it appears to not be usable but you can already use it manually without much effort.

It was also reworked in FreeBSD 15 and that's the reason we're halting further efforts to present it in the GUI until we're on 26.7 and things have stabilised.


Cheers,
Franco
#6
I am certain to have read somewhere that while site-locals technically are deprecated, existing deployments are not required to re-address, so they'd still be reserved for legacy environments, and given the available address space probably will not be re-purposed any time soon. However, RFC 4291 actually demands that "The special behavior of this prefix defined in [RFC3513] must no longer be supported in new implementations (i.e., new implementations must treat this prefix as Global Unicast).", so they're indeed no longer special.

However, https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml lists the entirety of "fc00::/7" as "Unique Local Unicast".

If these rules make no difference, then I must wonder why they can be created at all, maybe it is for logging only? Even if that is the case, I'd prefer these to be logged as "private" instead of being lumped in with all other denials.
#7
The type "script_output" doesn't pass on the parameters at all, while the type "stream_output" produces errors like those:
configd.py 24357 - [meta sequenceId="1"] [ed0118b6-cc66-4999-8f9f-ba9f9d59ced2] reordering IPv6 on interface re1...
configd.py 24357 - [meta sequenceId="2"] [ed0118b6-cc66-4999-8f9f-ba9f9d59ced2] Script action failed with [Errno 9] Bad file descriptor at Traceback (most recent call last):   File "/usr/local/opnsense/service/modules/actions/stream_output.py", line 70, in execute     callback(key.fileobj, mask)     ~~~~~~~~^^^^^^^^^^^^^^^^^^^   File "/usr/local/opnsense/service/modules/actions/stream_output.py", line 48, in stdout_reader     connection.send(data)     ~~~~~~~~~~~~~~~^^^^^^ OSError: [Errno 9] Bad file descriptor  (bytes processed 34)
configd.py 24357 - [meta sequenceId="3"] message ed0118b6-cc66-4999-8f9f-ba9f9d59ced2 [ipv6reorder reload re1] returned Execute error

The action file is this:
[reload]
parameter:%s
message:reordering IPv6 on interface %s...
command:/root/priorizeprivacy.sh
type:script
description:Reorder IPv6 addresses to priorize the PEA

The type "script" is the only one that works properly, but none of the other two.

What am I doing wrong this time?
#8
General Discussion / Re: AmneziaWG on OPNsense and ...
Last post by OPNenthu - Today at 01:53:28 AM
@unholy_saint: It's refreshing to find a networking professional supportive of user-centric and privacy enhancing technologies, even if they are needed for your business case.

I think sometimes admins get into a mindset of needing to insepct/filter/block everything, always.  It also leads to a kind of God complex in the wrong type of person (personality disorders exist).  I recently was listening to a radio interview of a landlord who admits to spying on his tenants via the WiFi he provides and when pressed on it, his justification was that 1) he sometimes discovers illegal activity, and 2) IT people do it all the time.

While corporations have an operational necessity to keep their networks secure, it's important that we don't bring that mindset back with us in our private lives.  Breaking the cryptographic chain of trust for users, for example, is not to be done lightly or promoted as a correct thing to do.  It's insidious.

More people have to say this, IMO.
#9
General Discussion / Re: AmneziaWG on OPNsense and ...
Last post by unholy_saint - Today at 01:26:31 AM
Quote from: nero355 on April 08, 2026, 11:42:16 PM
Quote from: unholy_saint on April 08, 2026, 07:20:25 PMespecially by somebody who actually lives in EU.
Europe area in general or one of the countries that are part of the European Union ?!

EU as composite of multiple countries and local authorities over a complex network infrastructure. Most issues I've seen were not clearly traceable although usually there is specific exchange or mobile operator that can be suspected to be most the likely place to block traffic. Unfortunately the only one i can clearly confirm is a DPI platform that was tested for several weeks in the Bulgarian BIX exchange. Also due to how the VPN structure i work with is spread my impressions are related mostly to eastern, central and southern Europe. Also we had to drop VPS in France because of to many blocking hits. It was before i started to migrate to Amnezia.

This is not WireGuard related only, VPN issues are something new, while random web site blocking (can speak mostly of Bulgaria here) started more than year ago. However until now never seen EU originated blocking (dnssec hijacking is clearly US originated) that i can explain logically (based on politics, legal reasons, etc.) and in most cases blocking live is just to short to be of practical use. This is why it leaves an impression of somehow discreet live tests instead of actual censorship, but this does not make it less obstructive when it hits your current work.

BTW: My impressions of Amnezia are great, not even a single randomly blocked destination for two months since first migration.
#10
General Discussion / Re: opnsense-revert opnsense f...
Last post by Greelan - Today at 12:52:22 AM
Quote from: franco on April 08, 2026, 02:48:18 PMWe could make opnsense-update a bit more helpful by adding a check if the origin is there (and script minimal recovery with it)?
Sounds fair. Maybe even an early check for file locks on config.xml in opnsense-revert so it can bail before that becomes an issue?