Bufferbloat recipe and rule direction
-
Regarding the bufferbloat recipe, why is the floating rule direction 'out' rather than 'any'?
I have implemented the recipe for the WAN and it it does make a significant improvement according to waveform test. Just wanted to understand the reasoning for that config of the floating rule. Thanks. -
@darcey The direction there is "out" because of this setting:
If it was "any" and you have any port forwards set up to allow incoming connections on WAN (maybe to allow SSH to one of your LAN clients, for example) then the traffic would be put in the wrong pipes (i.e. download in your upload limiter and vice versa).Or it may prohibit you from choosing the "any" direction at all when you set in/out pipes, or fail in some other way (floating rules can be tricky). But the point is really: when you're setting in/out pipes in the rule it does not make sense to have direction set to "any".
-
Many thanks.
I was aware of the opposite sense of 'in' and 'out' with respect to floating rules.So, taking the buffer bloat recipe as an example, with direction set to 'out':
- The wanDownQ gets applied to packets entering via the WAN only by virtue of their being asscoiated with outgiong packets (because of state/connection tracking)?
- The rule will not affect incoming or outgoing traffic associated with any port forward rules on the WAN.
I already had, and still do have, two limiters (no queues associated) which I applied to a WAN rule. This to to cap the bandwidth available to a service I exposed using a port forward on the WAN. I take it, therefore, the bufferbloat rule will not associate with that traffic (because of the floating rule's 'out' direction)?
Am I understanding that correctly?
-
@darcey With the disclosure that I don't consider myself an expert on this subject, I do believe that your understanding is correct. It sounds like for your limiters you just have a WAN firewall rule to handle the "in" direction on WAN for the port forward you have and a floating rule to handle the "out" direction on WAN, and that should be fine.
You didn't specify, but just make sure that your floating rule's action is Match, not Pass, and that it is not a "Quick" rule. In my setup I just have two floating rules with the Match action, one for In on WAN and one for Out on WAN. That way you don't need to remember to assign the limiters if you add extra Pass rules on the WAN interface.
-
@TheNarc said in Bufferbloat recipe and rule direction:
@darcey With the disclosure that I don't consider myself an expert on this subject, I do believe that your understanding is correct. It sounds like for your limiters you just have a WAN firewall rule to handle the "in" direction on WAN for the port forward you have and a floating rule to handle the "out" direction on WAN, and that should be fine.
You didn't specify, but just make sure that your floating rule's action is Match, not Pass, and that it is not a "Quick" rule. In my setup I just have two floating rules with the Match action, one for In on WAN and one for Out on WAN. That way you don't need to remember to assign the limiters if you add extra Pass rules on the WAN interface.
For the floating rule re bufferbloat, I followed the recipe, which has action:pass, quick:checked, direction:out.
However what you say makes sense! With the rule, as set out in the recipe, it would allow all traffic out the wan. Since, AIUI, floating rules, more so quick rules, will act on the packets before any other rules. I'm going to change it to 'match' and see what effect that has. Thanks! -
@TheNarc said in Bufferbloat recipe and rule direction:
You didn't specify, but just make sure that your floating rule's action is Match, not Pass, and that it is not a "Quick" rule. In my setup I just have two floating rules with the Match action, one for In on WAN and one for Out on WAN. That way you don't need to remember to assign the limiters if you add extra Pass rules on the WAN interface.
Thinking about it, this makes good sense. I have a few services port forwarded. One is my VPN and the others are web based services. I want to throttle the latter but keep the VPN speed unfettered.
If I were to take a consistent approach (i.e. apply similar traffic shaping methods to the inbound), I think I'd need to create multiple limiters/queues in order to differenciate the speeds available to VPN vs the 'slower' services.