Messages

lol, shots fired :)

Here is: https://github.com/opnsense/core/issues/10892

Where oh where have my auto rules gone... where oh where can they be? :)

You cannot view this attachment.


(Kidding aside, thanks for another great update.  I'm loving the advanced mode markers.)

as my emmc is dead and I'm barely within warranty I might still send it to them

did you try updating the NIC's firmware with the newer build?

I kept the NIC firmware as-is and honestly now with OPNsense 26.7.x I feel even less of a reason to change it.  Things seem to be behaving.

If they're going to ship you a new one anyway you might as well ask them if they can update it.

BTW, you probably saw my note above about setting the date manually in FreeBSD the first time you boot after a battery change / CMOS reset.  Coreboot doesn't let you set the system time unfortunately so until you do it in the OS you'll have problems getting NTP to sync.  FYI.

I agree w/ Nullman, these things do seem to go through batteries faster than the typical PC/laptops I'm used to.  However, I think the first production units (the "v1" if you will) did have some issue.

Hi @cottec,

Not sure what's going on with yours specifically but the COM issue sounds familiar.  I have a newer production run of the V1410 now and these issues haven't come back.  I would reach out to Protectli support.

You might be able to get COM port responding again with a CMOS reset: https://kb.protectli.com/kb/cmos-reset/.  I remember this working for me.

Replace the battery first if you can, and make sure you are on the latest firmware.

I'm using LocalAI in Vulkan mode which seems to be the highest performance I can get out of the little machine I'm using.

I would like to do the same kind of thing, but the only machine I have that might be adequate enough is my main PC (RTX 5070 Ti, 16GB).  It's running a linux desktop but that's not the problem, I think.  The issue is that I would want to run the LLMs in some kind of strong isolation like KVM but Nvidia doesn't allow partitioning on their consumer class GPUs. :(  I don't know how to expose it to the VM without completely losing display output on the host.

Anybody have luck with containers?  Assuming it works for getting access to the GPU, is it safe enough for this purpose?

How does "Firewall->Settings->Advanced->Disable force gateway" fit in here (or not)?

you are better than DuckDuckGo.

Lol, I probably deserved that!

[...] I will enjoy the discussions in the OPNsense Science Fiction and Philosophy forum.

You found the discussion engaging, or at least the opportunity to project subject matter expertise.  Why this bit of shade at the end?

In context with opnsense firewall you can combine IPv6 with ICMP (echo request) and IPV6-ICMP (echo service request) - both work. To keep it simple, a single rule for IPv4/v6 (any) with ICMP (echo request) seems to work. So my two questions are:

Hmm, if that does work then 1) it's news to me, and 2) there must be some logic in OPNsense which is creating the two version-specific rules on the backend.  I always just create them separately.  I'm happy to be wrong about this because then I can consolidate my ruleset :)

I think that because icmp and icmp6 are distinct protocols belonging to their respective IP version that 'pf' cannot handle both in a single rule.  IMO, the OPNsense rules GUI is a bit misleading in that it allows you to select them freely.

"Echo request" and "Echo service request" are synonymous, just for their respective version.  Maybe OPNsense maps them intelligently if you choose either one.  I don't know.

You can find references to "Echo request" (type 8) and "Echo service request" (type 128) in the FreeBSD ICMP(4) and ICMP6(4) man pages, respectively:

https://man.freebsd.org/cgi/man.cgi?query=icmp&apropos=0&sektion=0&manpath=FreeBSD+15.1-RELEASE&format=html

https://man.freebsd.org/cgi/man.cgi?query=icmp6&apropos=0&sektion=0&manpath=FreeBSD+15.1-RELEASE&format=html

Any advice from the graybeards on what you see as worth investing time into learning now?  How would you advise a colleague who, for example, had just entered middle age and was let go from a company where they had worked for many years and now find themselves lost?

As I see it AI is still in flux and not stable enough to make long term plans around.  Had AI not come into the picture, I would have maybe advised the colleague to learn a new in-demand programming skill such as web development, say, but now programming is not even valued.  The "value" seems to be in managing the AI and taking personal responsibility for its outcomes, while dealing with increasing demand for output.  It's an idea that Cory Doctorow coined as the "Reverse Centaur," where now humans are in service to the machine rather than vice-versa.

What are the good jobs now and in the foreseeable future?

ICMP / Echo Request is for IPv4.

Side note: I've seen a bug in OPNsense when editing rules that sometimes the "ICMP / Echo Request" values stick around when changing the IP version from IPv4 to IPv6.  You get an error when trying to save the rule in that case and then you have to just change them to "IPV6-ICMP / Echo service request" manually and re-save.

Got curious as I'd never seen a 'policy editor' UI.

That text seems related to IDS:

https://github.com/opnsense/core/blob/e5f01510072b2602cfe215fbb0d51cda33999035/src/opnsense/mvc/app/controllers/OPNsense/IDS/Api/SettingsController.php#L741

It links to /ui/ids/policy#rules and I guess triggers if rule count > 100.

Makes sense why I never saw this before as I'm not running IDS.  OP was right to post in this section but the 'policy' wording is ambiguous and made me also think 'pf' rules :P

Oh, but I think there might be a wrinkle with how the floating rules expand.  One rule in OPNsense could really be several rules in pf, so best to check the ruleset on the backend.

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)?

Going off of the man page description for 'max-pkt-rate', I think it should count for all the clients in the source alias I used.  The manual says it measures "packets matching the rule and states created by it," which I interpret this way.

I can say that the earlier Unbound reports corroborated this.  While both of the Rokus were actively spamming, the total rate of queries between them was capped at the set rate.

Maybe a dev can confirm this.

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.

You cannot view this attachment.

The millions of queries that were bogging down the Unbound reports have also now dropped off naturally and are capped:

You cannot view this attachment.

One of the Rokus has recently stopped its spamming but another one remains 'active'.  It's no longer making the firewall unresponsive though and now the reporting also loads normally.

I think pf rate limiting is a nice one to have in the toolbox.  Good feature update :)