Ok, seems that I won't get any further help here. I did remove the Shaping yesterday as I was doing some more testing and realized that p2p traffic now was able to consume 50Mbit fine, while with shaping I only got 20 Mbit, so there is either something completely wrong in my setup/logic, or .. don't know ? If anyone can shed some light into this, it would be much appreciated.

It's a bug as far as I can tell.  I see the same thing, as do others.  It seems to happen for me most when I manually refresh the view with F5.

@ermal: That is just an input validation limited to the number of 30. Its not limiting the number of pipes. Hi , thanks for  answering. I havent managed to get more than 30 pipes due to this. The  message " you need at least one bw specification" shows as you try to add the 31st bw specification. How could I get more than 30 pipes?

I was recently trying to do something similar so I feel your pain. What I can tell you is that at least as far as I can tell (I'm still experimenting) this is definitely possible…but information on how to do it is slim to none. In part it's because it's difficult and time consuming to fully explain. I don't have enough time to sort through all the details with you but maybe the summary below will give you enough to get it going... What you need to know is that you can have parent and child queues where children inherit all of the bandwidth restrictions from the parent in addition to more restrictions you might specify. So for EACH VLAN interface you will want a default queue (probably whose parent is the default queue). You will then want something like "qInternet" which is a parent queue for "qAck", "qHighPriority" and "qBulk" or any other queues you want. You will then setup qInternet to have your 20Mbps cap by setting the upperlimit m2 to 20Mb (I'm assuming you are using HFSC) which will put a hard cap on that VLAN at 20Mb for traffic in qInternet or it's children. Inside of the child queues of qInternet you can specify hard limits (upperlimit) or portions of a congested link (link shares) for each of the child queues. Now you need to assign traffic to the queues. Do this using floating firewall rules. Set the action to "Match", the interface to your WAN interface (so you are limiting only packets originating from the WAN), the direction to "any", the Ackqueue/Queue to "qAck"/"qBulk" and you're set. This should place all your Internet traffic into the bulk queue (and the Ack queue). You can verify this on the queue status page (you may need to clear out your state table first). Now you can create additional similar floating rules except also define ports, etc. for them to put your high priority traffic into your high priority queue.

Traffic shaping can be done on any interface of the firewall. In your case, traffic between LANs must go through your pfSense box. Are there two different physical interfaces for each LAN?

Ah, hidden in rules.  Nice.

Thank you. Helped a lot.

I did several more tests on this. Whenever the queues don't have the letter "q" in front of the name they didn't show up in the RRD graphs. Just in case anyone is having the same issue…

bump I'm still getting this error: ipfw-classifyd: unable to write to divert socket: Invalid argument I'm at a loss, any ideas?

Please try to clarify your question. Is it really the case you only want to shape traffic to the router itself? Or is it really the case that you want to shape traffic from the WAN to any host on a LAN but not between different LAN/DMZ hosts. It would be helpful if you made a network diagram and then gave some examples of traffic you would and would not like to shape.

Well, after playing around some more with rules I think I got it to do what I want but I don't understand why. If someone can explain I would appreciate it. The rule I created which ended up working (it seems) is a floating match rule applied in all directions on all interfaces with a SOURCE IP address of the inside system who's traffic I want to put through the queue (172.17.110.61 in my example). Why it's the source IP is the mystery to me because the traffic I want to shape is traffic DESTINED for 172.17.110.61 and originating from the Internet not traffic originating from 172.17.110.61… Can anyone explain how/why this works?

The queues aren't my issue (I GUESS!) its about the queues are ignoring the shaping (kinda). At least that's how it feels to me. I give it a whirl on the weekend and report back :)

I think you could do this with either of the 2. There might be less work involved with the limiter.

In the meantime I found a workaround which makes the PPS and the Bandwidth column showing the correct values. status_queues.php is reading from a file called /tmp/qstats This /tmp/qstats file is already having the sum of each child queues for the root queue for bandwidth and PPS. But the PHP code still adds the amount of all child queues to it which is causing the doubles. I did a change in status_queues.php to fix it. I commented two lines (highlighted in red): function statsQueues($xml){ global $statistics; $current = new QueueStats(); $child = new QueueStats(); $current->queuename = $xml['name'] . $xml['interface']; $current->queuelength = $xml['qlength']; $current->pps = $xml['measured']; $current->bandwidth = $xml['measuredspeedint']; $current->borrows = intval($xml['borrows']); $current->suspends = intval($xml['suspends']); $current->drops = intval($xml['droppedpkts']); if (is_array($xml['queue'])) { foreach($xml['queue'] as $q) { $child = statsQueues($q); /* $current->pps += $child->pps; $current->bandwidth += $child->bandwidth; */ $current->borrows += $child->borrows; $current->suspends += $child->suspends; $current->drops += $child->drops; } } unset($child); $statistics[] = $current; return $current; }

I guess that could be one probable reason why it is really hard blocking P2P in Layer7 now due to this encryption using random ports. [image: 2.jpg.html] As you can see one sample we can site, on bittorrent program by default the encryption is disabled but for other peers it is possible that it is encrypted on their end. Others are welcome to chip in their ideas on this. Thanks again Harvy66.