Messages

The 26.1 kernel might have a regression w.r.t. shaping w/ FQ-CoDel but it's inconsistent.  My Bufferbloat and Cloudflare speed tests have started stalling on the upload portion of the test (tests won't complete).  Download is fine, though.

Tomaž's videos would show up in my algorithm from time to time.  Awesome development w.r.t to OPNsense.  Very cool, @Maurice! 

I did cringe a bit when he mentioned Claude, but those are very appreciable gains that he discussed.  I guess the question I have is whether the AI produces fewer bugs and vulnerabilities than a team of humans would.

@franco, I just noticed this https://github.com/opnsense/core/issues/10048

In your opinion should I just go ahead and configure my internal interfaces with static ULAs and use NPTv6 for outbound?  There are two issues that I don't know if the project will be able to accommodate in the short term (or at all, in the case of #1):

1. As per RFC4941 some client OSes (at least Windows 10 & Linux from what I've tested) take a literal interpretation that they should not revive a deprecated prefix.  So even if the same prefix is seen again on WAN and a fresh RA is sent with positive valid & preferred lifetimes, those clients will not regenerate temporary addresses.  This effectively breaks SLAAC, or at least a subset of it.

Impact: mostly workstations and clients that stay running for long durations without sleep or reboot.  In order to observe the issue, the prefix must be deprecated while the client is running and the client must be powered on long enough for the next temporary SLAAC address to be due for generation (usually each 24 hours by default in most OSes).

2. As per the GH ticket above, adding a ULA prefix as a VIP to the internal interface for RA distribution also breaks when WAN loses its prefix.  Thus VIP ULAs cannot be relied on for internal networking.

I think the combination of those means that, at present, the way for people with dynamic prefixes to get stable internal SLAAC is to not track the WAN at all, and to not use ULA VIPs.  Instead we have to statically configure the interfaces with ULAs and rely on prefix translation for internet access. 

Is this a fair assessment, and, is there anything I can add in GH at this time that could reasonably be accepted and developed by OPNsense to help with this?  (I understand dynamic prefixes are not a high priority for the project, so I don't mean to come off pushy here.  Just asking.)

Thanks for considering. 

Thought it would be fun to mention something positive once in a while instead of all those issues everyone is having because of various reasons ;)

... proceeds to enumerate all the reasons why he skipped the versions in between and won't be migrating any rules ;)

In playing with an instance of 26.1 in a VM recently, I noticed that if you just delete an interface using the trash icon in Interfaces->Assignments to unassign it then the rules do not get deleted.  The configuration identifier (e.g. optX) gets recycled and the next interface you assign which inherits it will also inherit the old interface's rules.

Or something like that, it was confusing. What I do remember is that rules got reassigned somehow rather than getting deleted.  The references to interface names within the rules (e.g. src/dest) got replaced with 'optX' identifiers.

Take away: if you truly want to remove an interface, it's a good idea to manually delete its rules first then delete the interface.  Or, clean up the config file manually.

If you're changing VLAN assignments, which is what I was doing, this can get messy.

My own Vault hangs just like you describe if I have the VGA console enabled at all.  I run mine with just the serial console.

Not sure if that translates to your device but worth a look...

Also, make sure 'USB-based serial' is unchecked.

Hi everyone, I think this is a good way to use IPv6. I use OpenBSD with this configuration; it's very configurable.
If the prefix changes, it's easy to fix.
I don't know if Opnsense can configure something like that

https://eradman.com/posts/ipv6-strategy.html#:~:text=Use%20rad(8)%20to%20distribute%20the%20stable%20addresses,egress%20inet6%20from%20fd00:51::/64%20nat%2Dto%202603:7081:5506:d885::/64%20source%2Dhash.

I don't think we have an equivalent to 'nat-to ... source-hash' in the FreeBSD favor of pf.

If I'm not mistaken it can be approximated with a combination of stateless NPTv6 and privacy addresses on the clients.  With an EUI-64 address, NPTv6 will directly translate and expose the host bits.  As long as a privacy ULA is active on the client, it should be the one preferred for egress and NPTv6 will preserve the privacy bits.  There would be no way to mask the host bits at the firewall level unless regular Outbound NAT is used for the WAN address (?)

Am I on the right track?

Thank you!  Good that I asked.

The EUI-64 issue is workable, I anyway disable them on web clients.  Mobile OSes have privacy features and MAC randomization already enabled.  The desktop/laptop machines get configured to use stable privacy addresses with privacy extensions on top.  (This is what breaks when those pesky RAs with preferred lifetime=0 come in.)

The ULA routes that the ISP tries to install are definitely not needed.  DHCPv6 is preventing them from being configured on the LAN, but the routes still show up on the WAN interface.

You cannot view this attachment.

I'm not sure if those are coming from DHCPv6 or from rtsold which is running in the background.  Is there a way to disable rtsold on WAN from the OPNsense UI?  In Linux I could use a sysctl to selectively disable it for an interface but in FreeBSD I think it's a global systctl (net.inet6.ip6.accept_rtadv=0) which would kill my internal network.

EDIT: I added the tunable to not accept RAs and the ULA routes still got added, so must be from DHCPv6.

--

It seems I might be alone with the prefix deprecation issue.  I'll give it some more time to see if any discussion develops around this before submitting a ticket, but am hoping to save the embarrassment of raising a nonsensical request :)

, I'm running coreboot and it doesn't have an option do disable ASPM at that level, maybe that can be accomplished if running AMI BIOS

At least on the V1410 model, this is correct.  The coreboot image forces ASPM enabled and that's why my attempts to disable it from the OS in the past have failed.  Fortunately this model isn't affected by it (all NICs report 0 errors and I don't experience dropouts).

I will contact Protectli support

Thank you for driving this and keeping us informed.

I'd like to open a GH request for the option to not signal a prefix deprecation if the same prefix is seen again within X minutes, but I'm not sure how all the various components interact in this regard.  Even if I'm using DHCPv6, the ISP is still sending RAs and those could also signal a deprecation with preferred liftime=0.

Is this a stupid request, or a feasible one?

--

Also, @Monviech my questions about ndp-proxy-go were meant in good faith.  I wasn't trying to be critical.  Would really like to know:

- Are the ULA prefixes able to be omitted from distribution downstream?
- Is the high rate of RAs (I see up to 2/sec) a performance concern?  Can those be rate limited to downstream?
- If the ISP sends an RA with PreferredLifetime=0 to signal a deprecation, do I have essentially the same problem?
- What information (if any) does this method give to the ISP about my network internals?

Thanks!

Glad that seems to have helped, at least for the I226-V interfaces.

I'm still curious what's going on with the X710 ports?  I don't currently own one but I'm interested in this model and from what I read those are supposed to have a solid driver under FreeBSD (firmware depending).  The only downside of the -BM2 variant on the VP2440 is that it only negotiates at 1/10GbE.

The other oddity is that Protectli runs it at x4 rather than x8, but on their site they claim this is still enough and they have tested it at full line rate in both directions, port-to-port.  https://kb.protectli.com/kb/vp2440-hardware-overview/  (see section on SFP+ Ports)

If you are on ZFS you can take a system snapshot before deleting the legacy rules (ideally take one before the import step as well, but you are already past that).

Maybe do another export from "Firewall->Rules [new]" after the migration and compare the two .csv files if you really want to?

I assume "Remove all legacy rules" will clear out any rules seen under under Firewall > Rules.

Indeed, though don't expect the legacy rules UI to not show anything afterward.  This part has caused some confusion.

What you will see is that each of the sections in the legacy UI will be blank in terms of the rules that would have been managed from there, but you will still see folders for the rules on other levels.  Some have speculated that those are leftover legacy rules or somehow redundant with the ones imported to the new UI, but they aren't.

So for example if you click on an interface in the legacy UI, there won't be any interface level rules there.  However the Floating, Group, and Automatic rules will still show up:

You cannot view this attachment.

They're just being reflected there because they still exist as rules, regardless of which UI (legacy or new) they reside in.

Hope this helps.

If you used the "Register rule" option then it creates an associated system-generated F/W rule.  There's a separate category for those that you can only see if you enable the "Inspect" mode in Firewall->Rules [new].  The category is labeled as "Automatically generated rules."

There are actually two such buckets, one at the start of the ruleset and one at the end: https://docs.opnsense.org/manual/firewall.html#processing-order

The DNAT F/W rule goes in the second one (at the end of ruleset).

Example screenshot from a test VM attached.

The Unbound->Blocklists grid in 26.1.5 looks clean with the custom domains no longer being all on one line and the ability to click the grid cell to expand/collapse when it contains 10+ elements is a nice touch.  Looks consistent with Interfaces->Overview.  Thanks!

After making a change, I always have to wait about 10+ seconds per rule before I can make any further changes.

Also N5105 here.  The new UI is definitely slower to load (especially on first landing due to the default 'any' view), but making rule changes is fine.  I haven't noticed this extreme of a slow down.

How many rules are we talking about?  I'm only sitting at 87 according to the UI.