Messages

Also the temp values jump around quite a bit (for me on a n150 at least). Just check the sysctl a view times and you may get +/-5°C each time. :)

vvd@mrqu:~ $ cpuinfo
dev.cpu.0.freq: 955
dev.cpu.0.temperature: 48.0C
dev.cpu.1.freq: 1171
dev.cpu.1.temperature: 48.0C
dev.cpu.2.freq: 1389
dev.cpu.2.temperature: 47.0C
dev.cpu.3.freq: 1511
dev.cpu.3.temperature: 47.0C
vvd@mrqu:~ $ cpuinfo
dev.cpu.0.freq: 1876
dev.cpu.0.temperature: 54.0C
dev.cpu.1.freq: 1664
dev.cpu.1.temperature: 53.0C
dev.cpu.2.freq: 1612
dev.cpu.2.temperature: 51.0C
dev.cpu.3.freq: 1612
dev.cpu.3.temperature: 51.0C
vvd@mrqu:~ $

Ah ha. Yes that makes sense.


Will there be a way that you can stop it looking for IPv6, maybe after a short timeout, if it's not available?

Probably not. Then it would stop trying for legitimate ipv6 setups that have a temporary failure.

The serial console spams the login prompt when I initally connect to it (putty). Once I hit enter it stops and I can login and use it normally.
Should I be worried? Anytging I should check? Thanks!

Maybe @franco or another developer can chime in on this. Seems like we have some air for improvement here. :)

Well, when you select multiple targets for a pass rule then there are multiple rules created in the background, one for each target (or source in your case). When you invert the meaning for the target (or source) you basically get an allow all ruleset. Because the second rule passes traffic that the first one did not allow.

I also think that this is an issue.

To not break current rulesets the only solution that I can see is to reflect the fact that there are multiple rules created in the background in the UI (you can have a look at /tmp/rules.debug). Like showing those rules indented and slightly greyed out below the rule. That way you get a hint why it does not work as you may have intended.

I think it is better to keep using aliases for this usecase, as you end up with only one rule.. which results in better lookup performance.

I am not sure if this is a bug. It is certainly not working as you and I expected. But changing the behavior now (like using an automatically created alias) would potentially break existing rulesets... even though that would probably ,,fix" what this feature intends to do, but currently does not? I don't know.

Maybe there is a developer reading this :)
Anyway, it is always good to have one good, working Boot Environment other than the default, running one!
It's a good safety net, should you mess up

Why aren't they called boot environments though? Or bootable snapshots?

Did you set a ,,DHCP Unique Identifier" and enabled ,,Prevent release" in Interfaces->Settings?
For the unique identifier you can use the ,,insert existing DUID" below the input field.

I don't actually know if it will work, but I had the same issue. But since I set the DUID yesterday, I ll get the same prefix after a reboot. Hope it will stay that way...

This explains the DUID: https://datatracker.ietf.org/doc/html/rfc8415

I just got one of those Topton Intel N150 4 port fanless mini PCs from AliExpress to replace my APU2D4 (160 Euros inkl shipping).
I feel I've made a good choice. I've added 16GB DDR5 and a "low power" nvme SSD (WD Green SN350 250GB 2G0C).
I just renamed all occurences of igb to igc in the config.xml and imported it, resetted tunables and added some for RSS and Intel Speed Step or whatever (PowerD is disabled).
So far no issues and a blazing fast web interfcae :)

It doesn't have a BIOS to limit the CPU voltages. But the box is not running hot:

Code Select Expand

$ sysctl -a |grep temperature
hw.acpi.thermal.tz0.temperature: 27.9C
dev.cpu.3.temperature: 50.0C
dev.cpu.2.temperature: 49.0C
dev.cpu.1.temperature: 47.0C
dev.cpu.0.temperature: 48.0C
You cannot view this attachment.

It could be used for the ,,This Firewall" and (self) UI rules...hmm

They are not used anywhere (it seems) but I have two of those: one includes all ipv4 node addresses and the other all ipv6 node addresses.
Using OPNsense v25.1

The policy based routing rule did not work as a solution (as you may have suspected). Basically it was a allow all rule that routed all traffic to the wan (including everything that would normally route to local networks). XD

So I created a nested alias and using that works as expected.

But shouldn't a selection of multiple target aliases create a new alias automatically?
The problem is: You see one rule in the UI but get multiple rules in the back which behave differently than expected.
Either that, or all the created rules should be visible in the UI as well.

@Franco is this something you would agree to?

Greetings,
this archived forum post is what I am currently wish to solve. Some good suggestions in that thread but they seem to behave weird for me.

For example, if you select multiple (inverted) destination aliases on a quick rule:
You cannot view this attachment.

Code Select Expand

pass in log quick on home inet proto {tcp udp} from {(home:network)} to !$Private keep state label "45a2751bd6a8450b96853b456e68e098" # allow wan traffic
pass in log quick on home inet6 proto {tcp udp} from {(home:network),fe80::/10} to !$Private keep state label "45a2751bd6a8450b96853b456e68e098" # allow wan traffic
pass in log quick on home inet proto {tcp udp} from {(home:network)} to !$Blocked keep state label "45a2751bd6a8450b96853b456e68e098" # allow wan traffic
pass in log quick on home inet6 proto {tcp udp} from {(home:network),fe80::/10} to !$Blocked keep state label "45a2751bd6a8450b96853b456e68e098" # allow wan traffic
pass in log quick on home inet proto {tcp udp} from {(home:network)} to {!(self)} keep state label "45a2751bd6a8450b96853b456e68e098" # allow wan traffic
pass in log quick on home inet6 proto {tcp udp} from {(home:network),fe80::/10} to {!(self)} keep state label "45a2751bd6a8450b96853b456e68e098" # allow wan traffic
pass in log quick on home inet proto {tcp udp} from {(home:network)} to {!(home:network)} keep state label "45a2751bd6a8450b96853b456e68e098" # allow wan traffic

The result is probably not as intended, because the "!$Private" rule will pass traffic that the "!$Blocked" would block for example.

So it seems you should create a new alias that contains all the other aliases...but:

Isn't the "better" solution to use a "policy based routing" rule? Eg. using a "allow all via wan gateway" rule on those interfaces? That should only allow internet access afaik? Are there any problems with that solution?

Or would that possibly route some local traffic to wan as well? Thats at least what the "routing" part would suggest...


Thank you

Looks similar for me on apu2. Lots of holes in the data. For all metrics. As if the gathering process pauses or something.

I have a stupid question: if you want secure DNS queries, why not just use DNS over TCL?