Recent posts

#1

26.1 Series / Re: PF rejects UUID overload t...

Last post by Monviech (Cedrik) - Today at 01:38:30 PM

Hello thanks for the report we are looking into it.

#2

26.1 Series / PF rejects UUID overload table...

Last post by daygle - Today at 01:11:11 PM

After upgrading to OPNsense 26.1, PF is refusing to load the ruleset whenever a firewall rule uses rate‑limit / max‑src‑conn‑rate options.
The overload table names appear to be UUIDs, which exceed PF's maximum table‑name length.
This results in PF rejecting the entire ruleset.

Error output:
There were error(s) loading the rules: /tmp/rules.debug:317:
table name 'cc63f2df-3dc0-4fe5-a002-b8e7a2d5ade1' too long

The line in question reads [317]:
pass in quick on igc0 inet proto tcp from {any} to $ssh_ipv4 port {22}
keep state ( max 100 max-src-nodes 50 max-src-conn 20 max-src-states 3
tcp.established 300 max-src-conn-rate 2 /60,
overload <cc63f2df-3dc0-4fe5-a002-b8e7a2d5ade1> flush global )
label "4622edd3-7c20-497c-ba73-8c044b3cfcca" # SSH/RL/IPv4

Multiple similar UUID‑style table names are generated for other rules with rate‑limit settings, and PF rejects all of them.

Steps to reproduce
1. Create a firewall rule (e.g., SSH on WAN)
2. Open Advanced Options
3. Enable - Max src‑conn‑rate and Overload table alias.
4. Apply changes
5. PF fails to load ruleset with "table name too long"

For those who have the same issue - you can remove the overload alias from the rule until a fix has been applied.

#3

26.1 Series / Re: New rule system

Last post by keeka - Today at 12:50:28 PM

I take your point. If on the other hand you have only known ASNs or subnets that you wish to allow, Pass would seem OK. But I am now feeling cautious about mixing Pass forward rules with those requiring explicit filter rules. It starts to feel messy.

#4

26.1 Series / Re: New rule system

Last post by Patrick M. Hausen - Today at 12:33:46 PM

- source/destination criteria in the port forward rule will serve as the filtering criteria.

Sure. Only thing is this is getting increasingly difficult in a single rule - regardless of NAT or filtering. Picture on WAN:

    block all known bad actors: free block lists, Q-Feeds, Crowdsec, ...
    permit inbound from GeoIP Europe but block everyone else

In a single rule you can have either source invert or not. You cannot combine in this fashion e.g.

    allow from (not (bad actors)) and (GeoIP Europe)

You can of course

    block from (bad actors) and (GeoIP except Europe)

only that the second variant generates an alias with orders of magnitude more entries.

So for me essentially "pass" is dead and I need two rules, one block, one allow.

#5

26.1 Series / Re: New rule system

Last post by keeka - Today at 12:27:15 PM

That leaves the question in which situations the "Pass" mechanism might be useful at all.

AISI pass may be useful when:
- source/destination criteria in the port forward rule will serve all needed filtering criteria.
- no egress filtering is needed.
- no tagging, policy routing, traffic shaping (or something else?) is needed.

Would that be about right?

@meyergru I have a couple of portforwards on the WAN where the pass action won't be satisfactory. However I also have some on the WAN and almost all those on the local interfaces, where I think it will be appropriate. Just that it never occurred to me use that option in the past and so I have, what I now think, may be redundant filtering.

EDIT Having said that, it may get confusing in the future having the cause of passed traffic not visible in the filter list. I'm sure that would catch me out especially with my memory these days. In fact I think this is a good enough reason for me not to use Pass and instead explicitly define filter rules to pass port forwards.

#6

26.1 Series / Re: New rule system

Last post by meyergru - Today at 12:11:27 PM

If the source/destination criteria on the forwarding rule are sufficiently selective, then I suppose a 'pass' action is sufficient.

True, but there is a problem with it: Imagine you have some blocking rules. You can use them in the floating rules, but just for WAN. You can enable or disable each of them selectively and that combination works work all port forwarding and allow rules after that alike. I mean something like this:

You cannot view this attachment.

If you want to mimic that with separate source criteria for each port forwarding rule, you look at a lot of work. Also, some of the block rules cannot be combined in a single network group alias, because of their type (say, __qfeeds_malware_ip).

Therefore, you probably still need separate rules (I do) to be able to shift their priorities, but you must take care of them manually after 26.1, because they become disassociated from their respective NAT rules.

#7

25.7, 25.10 Series / Re: Let's Encrypt IP address c...

Last post by gspannu - Today at 11:54:16 AM

I have created a #5170 feature request on Github for the same.

#8

26.1 Series / Re: New rule system

Last post by keeka - Today at 11:53:30 AM

Thanks all for the pass clarification. That makes it clear and makes sense. I have been aware of the packet processing order but somehow got misled ;-)

If the source/destination criteria on the forwarding rule are sufficiently selective, then I suppose a 'pass' action is sufficient. In fact it now occurs to me that some of my associated rules may be redundant.

#9

26.1 Series / Re: RC1: hundreds of rc.newwan...

Last post by meyergru - Today at 11:40:11 AM

IDK if this is related, but just now, after ~16hour of running time, my system crashed and rebooted silently (no core dumps or anything and nothing in the crash reporter).

After startup, I find a host of these messages in the logs:

Code Select Expand

/usr/local/opnsense/scripts/health/updaterrd.php: The command </usr/local/bin/rrdtool create '/var/db/rrd/wireguard-traffic.rrd' --step 0 DS:'inpass:COUNTER:120:0:2500000000' DS:'outpass:COUNTER:120:0:2500000000' DS:'inblock:COUNTER:120:0:2500000000' DS:'outblock:COUNTER:120:0:2500000000' DS:'inpass6:COUNTER:120:0:2500000000' DS:'outpass6:COUNTER:120:0:2500000000' DS:'inblock6:COUNTER:120:0:2500000000' DS:'outblock6:COUNTER:120:0:2500000000' RRA:'AVERAGE:0.5:1:1200' RRA:'AVERAGE:0.5:5:720' RRA:'AVERAGE:0.5:60:1860' RRA:'AVERAGE:0.5:1440:2284'> returned exit code 1 and the output was "ERROR: step size: value must be positive"

I also have remote logging for that system. Nothing particular shows before the reboot:

You cannot view this attachment.

#10

26.1 Series / Re: New rule system

Last post by Seimus - Today at 11:27:06 AM

I thought reStructured supported flow diagrams (but maybe I am making things up).

It is bit lousy yes, but it as well says a lot.

Anyway got ya. But its something that sooner or later would be worth a while.

Regards,
S.