Should floating rules direction by specified?
-
Currently, pfBLockerNG-devel creates floating rules with direction of "any". This introduces unnecessary rule processing due to e.g. internal traffic being processed by a floating rule which checks for the source of a public IP.
As more IP aliases and interfaces are defined, the less efficient the rule processing. Ideally there should be an option on the pfBlockerNG-devel advanced firewall rules section to specify the direction for both Inbound and Outbound interface sections, keeping "any" as the default.
-
If you set pfBlocker to use Alias Native, it just creates an alias, and you can create your own rules.
-
There are a couple of drawbacks to that.
- Using your own rules with the alias means that pfBlockerNG is no longer able to keep track of stats for those aliases - hence an empty reports page.
- If anything happens with the package or process which populates the aliases, the custom rules are no longer valid and prevent filter reloads from completing.
To get around the direction "any" issue, one could select individual interfaces instead of using floating rules. The issue with this approach is that if there exists rules on an interface group that would match first, the pfBlockerNG auto rules would not work.
-
@marc05 Using any is good. I've noticed that the floating rules are not stateful. So if you allow "out" instead of "any" for example, a request can go out, but the reply is not allowed back in unless you specify "any" (where as the other rule tables are stateful and would allow the response in).
Why do you want to change it from any to out? any is fine.
-
@propercactus
I've explained why (reduce pf evaluations). As for the concern about states, you would select direction in as there are already automatic pf rules which allow the packets out; there wouldn't be any issues with states. -
@marc05 said in Should floating rules direction by specified?:
there are already automatic pf rules which allow the packets out;
If you keep the default allow LAN to everything in the rules yea.
@marc05 said in Should floating rules direction by specified?:
This introduces unnecessary rule processing due to e.g. internal traffic being processed by a floating rule which checks for the source of a public IP
Everything is checked anyway. There is not one packet that goes through the firewall that isn't evaluated against the iptables chains (BSD equivalent, pf I'm guessing lol).
I would not be stressing about "any" vs "out" it's not doing what you think, it's really only for allow rules, to ensure the return packets for the state can get back to the recipient. Out is out only and doesn't allow a response. If you are blocking out then there is no response anyway and so no packets matched against the rule set
-
@propercactus
I'm not talking about the default firewall rules. I'm referring to the pf rules that are automatically generated, e.g.:pass out inet all keep state allow-opts tracker 1000017365 label "let out anything IPv4 from firewall host itself"All packets are indeed evaluated, but packets don't need to be evaluated by multiple rules if it can be avoided.
-
@marc05 said in Should floating rules direction by specified?:
let out anything IPv4 from firewall host itself
Oh but that rule is for the actual firewall itself, not all traffic out from LAN devices. That rules makes sure stuff like Unbound can send DNS queries etc.
But what I'm saying is that the rule is going to be there whether it's "any" or "out" you will still have a rule and it's going to be matched against it either way. Only difference is "any" will keep state, "out" will not, it will allow out and not allow a response. And as you are blocking or rejecting with pfBlocker rules, there is no state to keep anyway as the connection is not made so it doesn't matter.
-
@propercactus
My concern was that with any on WAN, there would be redundant evaluations on the pf rule when traffic was going in the out direction. Running pfctl -vsr it would seem that evaluations take place even if a direction is specified which would make my point moot. -
@marc05 yes indeed, if the rule exists it is checked against it, unless you match with a quick rule then it stops matching further at that point. Advantage of floating rules you can make them quick rules. If you want to reduce the checks you would want to prune rules or try consolidate them etc. or structure quick rules for known good traffic.