Confused about the document of creating a fq_codel limiter
-
I just read the document of creating a fq_codel limiter.
And I am confused about the bottom of this document which tells to create a float rule with action "pass". Is that should be a "match"?
-
@yunan I’d noticed that also. My thought was, outbound on WAN, at that point packets are going out anyway…? The block outbound would normally be on LAN which processes before that.
Though I think Match would be fine…
-
@SteveITS This rule is not effect outbound traffic only. Although its direction is "out", its in/out pipe is set to upQ and downQ.
What I am very concerned about is setting this floating rule action to "pass" will allow any traffic inbound WAN interface.
-
@yunan It won't. You can easily test this yourself.
-
@Bob-Dig May I have your explaination to this?
Looks like it's true. But I haven't test it on VM. I only tried to access web admin page from outside by firewall WAN IP.
And this makes me confused instead of concerned.
-
@yunan You said it already, the direction is out, not in. I think this explains it.
-
@Bob-Dig
In the floating rule, in/out pipe is setting to upQ and downQ.From the point of view of WAN, when direction is out, upQ limiter effect my upload traffic and downQ is the opposite.
Because floating rule action is "pass", it will allow all income traffic from outside to WAN.
-
@yunan That’s not how it works actually. The packet has to match the rule first. The response packets to that now open state are put in the assigned queue. An inbound packet won’t match.
Browse to your pfSense WAN IP from your cell phone, off wireless.
The outbound rule using Pass I think would affect traffic from pfSense itself…
-
@Bob-Dig @SteveITS
Here is an article explained how the author implemented floating rule for limiter.In that article there is one part:
"
Next, we have to create the floating rules that will optimize the network traffic. There are some who suggest the usage of a single “Pass” action floating rule, and with the “Direction” option configured to “out”. This is not recommended. Firstly, according to Netgate documentation, Traffic Shaping related rules should utilize the “Match” action [7]. Secondly, by using only “out” for the “Direction” option, only outgoing traffic will be optimized and incoming traffic ignored. As such, 2 floating rules (one for incoming, and one for outgoing) should be created.
"He disagree with the pfsense document.
And he created two floating rules for the limiter. One is on WAN "in" direction, and other is on WAN "out" direction. Both have in/out pipe set to "upQ" / "downQ" (or "downQ" / "upQ")
Edit:
If the floating rule in phsense document works, then one floating rule is enough for both in out traffic. And this article's method will match both in / out traffic twice.Edit:
I have seen someone said by accidently set the floating rule direction to "in" or "any" instead of "out" will open the firewall to the world.But why is setting direction to "out" is safe?
Edit:
I may have some answer now. But I can't verify whether it is right.If I set a floating rule with direction "out" and in/out pipe to "upQ" "downQ", the traffic start with my network will hit this rule, and create state for reply traffic from internet and the traffic after it. So the initial upload traffic and the upload traffic after will catch by upQ, And the reply traffic will catch by downQ.
And the traffic initialed by internet will not hit this floating rule, because the rule has a direction set to "out". So the outcome traffic will be block by the default WAN rule.
-
@yunan Reading the netgate traffic shaping documentation, I took it to recommend: Create limiters and queues, implement floating match rules for outbound WAN traffic. However, the recipe does not appear to follow those guidelines. I am inclined toward floating match rules and only targetting outbound, but my initial attempts proved confusing. I disabled it and I hope to do more reading!
Watching your thread with interest. -
So , what should set finally? Pass out or match out?
-
@yunan correct on the “out” and state comment.
Re match/pass, it won’t hurt to use match so is arguably “safer.” Just make it the last rule(s) in your list since it’s a floating rule and “last match wins.”
-
@SteveITS @darcey @Bob-Dig @Antibiotic
Thanks for your replies. I think I have a better understand now.
Like Steve said, setting this floating rule action "pass" or "match" doesn't affect the limiter‘s proper functioning. Their difference is not clear except you have other floating rules.
"Match" will be better, because it will keep the firewall safe when you set direction to "any" or "in" by mistake. And in my opinion "match" is a "standard way".
I have test the security of the pfsense document way on VMs. Setting the floating rule "pass" indeed won't open the firewall, And both "match" and "pass" will work properly for limiter.
Again, thanks for all guys spend time to help me with this problem.
-
@SteveITS If set to match , quick box ( Apply the action immediately on match) to leave on?
-
@yunan said in Confused about the document of creating a fq_codel limiter:
"Match" will be better, because it will keep the firewall safe when you set direction to "any" or "in" by mistake. And in my opinion "match" is a "standard way".
Rules to set queue/limiter. Separate rules to determine whether traffic passes. I think they call it separation of concerns.
-
@Antibiotic said in Confused about the document of creating a fq_codel limiter:
@SteveITS If set to match , quick box ( Apply the action immediately on match) to leave on?
If it is the last rule, it does not matter. Quick tells it not to check later rules.
