How do predefined net aliases work?

[OPNenthu]

There are no magic other attributes to a "Floating" rules than just the processing order.

Nice to see this explicitly stated :)

I came to the realization after studying /tmp/rules.debug, but in the past had spent a lot of time wading through misinformation in online searches and A.I. chatbots.  There are still claims out there that floating rules have special properties.

[Bob.Dig]

that floating rules have special properties.

They have, in pfSense. And you can select different interfaces, which is special too, for both. 

Btw. I don't understand, why the choice for creating a floating rule for one interface only has been taken away from users. Is there an actual, good reason? What does it solve to not allowing it. 

[Monviech (Cedrik)]

It solves that it slowly paths the way to a unified ruleset without special hardcoded prorities in which you can move rules at any spot you want.

At least thats my wish for the long run:
https://github.com/opnsense/core/issues/9652#issuecomment-4274523794

Demystifying floating plays well into that strategy.

[Bob.Dig]

Thanks for pointing to that discussion. My English ain't that good, so I have the feeling, that I still might miss something. Let's say I have two WANs, for both I block RFC1918 outgoing, so I used one floating rule. But for one WAN, I have an allow rule for WAN_network before that. Now I am forced to do things differently.

in which you can move rules at any spot you want

That sounds like more freedom but yet we will get less. :)
I kinda think that you could achieve that goal in the same time without that floating-decision, I can't see that benefit, yet. ;) And some people hate any friction.

[Monviech (Cedrik)]

Sorry it feels like we are hijacking this thread now. If this needs to be discussed further best create a new thread.

[OPNenthu]

[...] if I put in any predefined interface net alias into a rule it will allow all the networks from the interfaces in the rules. So if I have a floating rule with interfaceA and interfaceB, sources as exact-host-from-interfaceA-network and the predefined interfaceB net alias, then the rule will still match traffic from interfaceA from any host in that network, instead of just the exact-host-from-interfaceA-network.

A test rule like you describe expands like this on the back end:

You cannot view this attachment.

Code Select Expand

# [prio: 200000]
pass in quick on vlan0.1030 inet from $HOSTS_MGMT to {any} keep state label "e92ba5aa-e088-4435-8244-1410fd42334b" # test
pass in quick on vlan0.1040 inet from $HOSTS_MGMT to {any} keep state label "e92ba5aa-e088-4435-8244-1410fd42334b" # test
pass in quick on vlan0.1030 inet from {(vlan0.1040:network)} to {any} keep state label "e92ba5aa-e088-4435-8244-1410fd42334b" # test
pass in quick on vlan0.1040 inet from {(vlan0.1040:network)} to {any} keep state label "e92ba5aa-e088-4435-8244-1410fd42334b" # test

I can see that using multiple sources in a rule creates a potential hole where any of the sources will pass on either interface.  Maybe two rules would be better than a single rule here to avoid the spoofed source IP problem but then they can't stay in Floating and would change to interface level rules.

I don't see that other sources from vlan0.1030 (the source network for hosts defined in HOSTS_MGMT alias) would pass, unless either the HOSTS_MGMT alias contained a netmask (which they can't) as Patrick suggested, or, the hosts alias contained an incorrect entry.

Another possibility: did you have an active state from a prior rule change?  Maybe it would clear up after a reset.

They have, in pfSense.

Yeah, that's an important distinction too.  It's not safe to read pfSense docs/tutorials and assume floating works the same here.