Traffic Shaping Rules
-
I'm using the traffic shaper to create 7 queues for 7 host on a lan Along with corresponding rules to queue traffic into specific queue. After configuration the rules generated is causing the traffic shaping for uploads not to work or be shaped properly.
The problem is that all uploads fall into the qHighUpL queue particular because of the rule thats highlighted in bold red.
Im not sure I fully understand this but why is this rule genearted? I think its causing all my uploads to fall into that queue.Im using 1.0-BETA1-TESTING-SNAPSHOT-2-8-06 .
dc1 = Wan
dc0 = Lanblock all tag unshaped label "SHAPER: first match rule"
pass in on dc0 from $LeonIP to any keep state tagged unshaped tag qHighDownL
pass out on dc1 from any to any keep state tagged unshaped tag qHighUpL
pass in on dc1 from any to $LeonIP keep state tagged unshaped tag qHighUpL
pass out on dc0 from any to $LeonIP keep state tagged unshaped tag qHighDownL
pass in on dc0 from 192.168.1.10 to any keep state tagged unshaped tag q1DownL
pass out on dc1 from any to any keep state tagged unshaped tag q1UpL
pass in on dc1 from any to 192.168.1.10 keep state tagged unshaped tag q1UpL
pass out on dc0 from any to 192.168.1.10 keep state tagged unshaped tag q1DownL
pass in on dc0 from 192.168.1.11 to any keep state tagged unshaped tag q2DownL
pass out on dc1 from any to any keep state tagged unshaped tag q2UpL
pass in on dc1 from any to 192.168.1.11 keep state tagged unshaped tag q2UpL
pass out on dc0 from any to 192.168.1.11 keep state tagged unshaped tag q2DownL
pass in on dc0 from 192.168.1.12 to any keep state tagged unshaped tag q3DownL
pass out on dc1 from any to any keep state tagged unshaped tag q3UpL
pass in on dc1 from any to 192.168.1.12 keep state tagged unshaped tag q3UpL
pass out on dc0 from any to 192.168.1.12 keep state tagged unshaped tag q3DownL
pass in on dc0 from 192.168.1.13 to any keep state tagged unshaped tag q4DownL
pass out on dc1 from any to any keep state tagged unshaped tag q4UpL
pass in on dc1 from any to 192.168.1.13 keep state tagged unshaped tag q4UpL
pass out on dc0 from any to 192.168.1.13 keep state tagged unshaped tag q4DownL
pass in on dc0 from 192.168.1.14 to any keep state tagged unshaped tag q5DownL
pass out on dc1 from any to any keep state tagged unshaped tag q5UpL
pass in on dc1 from any to 192.168.1.14 keep state tagged unshaped tag q5UpL
pass out on dc0 from any to 192.168.1.14 keep state tagged unshaped tag q5DownL
pass in on dc0 from 192.168.1.15 to any keep state tagged unshaped tag q5DownL
pass out on dc1 from any to any keep state tagged unshaped tag q6UpL
pass in on dc1 from any to 192.168.1.15 keep state tagged unshaped tag q5UpL
pass out on dc0 from any to 192.168.1.15 keep state tagged unshaped tag q5DownL -
Yup, that'll do it. Shaper gets hit after NAT occurs so we don't know what the source IP really is, there's not a heck of a lot I can do about this issue right now I'm afraid. I'm open to suggestions on how to make our pf config better (and still keep shaping seperate from rules). In the meantime, I'm trying to figure out what I need to modify in kernel to make queue assignments sticky per packet which will allow us to fix this properly on the inside interface (note: this won't happen for 1.0, guaranteed).
–Bill
-
Here is another thing I observed today.. This rule:
pass out on dc0 from any to 192.168.1.7 keep state tagged unshaped tag qHighDownL (subset of rules posted earlier)
dc0 - LAN interface
Does not work for traffic originating from the firewall itself. Squid and ssh traffic to 192.168.1.7 for example would fall into the default queue instead of qHighDownL, so does all traffic to any ip whos traffic originated at the firewall. It only works for traffic comming through WAN.
Squid is boud to lo 127.0.0.1 while ssh is bound to the any address *. Is there any reason why this rule don't work for such traffic? I though about it and still can figure out why.
EDIT:
tried iperf from firewall to lan pc with ip address 192.168.1.7 -> the traffic found its way into the correct queue. however the others stated above still don't get queued properly. Could it have have something to do with the direction in which the connections were establish?