There are diagrams in the 2.1 book.  I'm not exactly sure where floating rules come in. Here's one paste.  I am operating on the assumption that a floating rule on WAN out pushes the firewall rules on WAN back into the path and that's the proper order.  LAN rules, then floating on WAN out for outbound states.  

@KOM: No idea.  I don't use captive portal. Maybe i'm the only one to use captive portable with the traffic shapping. I'll continue my research. Thanks.

This post looks like it may have the information you're looking for. https://forum.pfsense.org/index.php?topic=47856.0

If the other party has a slower connection, there is nothing you can do on your end, traffic shaping or not.

If all of your rules don't have a fixed upperbound, there should be a way to change the root to increase its upper limit. I'm not sure how, but there's bound to be a way.

Traffic management via the shaper is done with the use of queues and Floating Rules.

@Derelict: Get rid of the burst until you understand what it does. Done. Your comment says 1Mbit, but your limiter is 10Mbit. I was tweaking the settings without updating the comment.  You can ignore the comment. If that rule is on the customer interface, in is upload and out is download. What do you mean customer interface?  It is a type of LAN interface.  It is a VLAN (1003) of the LAN interface. There are countless questions asking how to do this.  Do a search.  You probably want a main limiter that gives your guests a pool then child limiters with a mask to evenly distribute the data while letting one user monopolize the entire pool if they're the only one on. Yes there are.  I have & will continue to search.  Is the main limiter with child limiters required?  I don't understand "a mask to evenly distribute the data".  I won't have problems with a lot of people being on it at one time.  It's for my home network & mainly just to keep the occasional guest from using my primary WiFi so I don't have to give out my WPA2 key & at the same time keep said guest from using up all my WAN pipe.

Thank you all so much the issue is resolved ;D. Just in case it becomes handy for someone else. Ill briefly write what I have learned and what I have done to fix the issue. As I already stated im pretty new to this networking stuff so if im not 100% right please correct me. What I understood in general about TCP/IP is dropping packets is a way to control speed. So I figured dropping packets at such a low transfer rate was bad. If these were packets for something not time sensitive like web browsing it would go unnoticed. -On my SRVS lan in Qinternet I added a new queue called MCservers. -On my SRVS lan I deleted the games queue as I have no other game traffic on that subnet. -On my WAN I set the game queue bandwidth to 5% service curve Link share 5% -On my WAN I set the MCserver queue bandwidth to 40% service curve (Real time : 7Mb, Link share : 40%) -On my firewall rules in the floating section I found the minecraft port entry and I edited the advanced features to use the ACK/MCServer Queues So far with 2 days of testing ive had up to 15 people = aprox 2-3 Mbps uploads and no complaints of lag and no more dropped packets in my graph. Actually it seems like this traffic is not showing on my RRD Queue graph at all anymore. Is this normal behavior with the real time service curve? I guessing that Realtime traffic skips the queue all together or for some reason just doesn’t show up on the graph? I still have more to learn about the service curve I found some awesome links in this forum. I should be ok from here. Thanks again!

@stenio: @Harvy66: Is there a reason why you can't treat this as a dual LAN setup, where the actual LAN is one network and the DMZ is another? Hi Harvy, Yes, there is: I would like to share the download bandwidth between the two interfaces. Thanks, Stenio Yes, seems I derped a bit there. I realized it when I read another post a few days later. Am I interested in how to best handle the issue of multi-lan where queues can't share interfaces. If there was a way, outside of yet another firewall, to have a single QoS queue for both Interfaces, that would make it simple.

That would work.  Read this to start.

little update: the problem is only vof trafic from remote site to my device in nat1:1. Upload is good. Thnx

its built-in pfSense… Status - RRD Graphs

What I did wrong? Posting a Squid question in the Traffic Shaping forum, for starters ;D You will have better luck getting a reply in the proper forum.  Questions about packages like Squid and Squidguard should be directed to the Packages forum.

@georgeman: Real solutions to this at the time: Use another pfSense in front of the other one, to shape based on the origin and destination subnets Bridge the interfaces so you can apply the shaper to the bridge as a whole (you can still somewhat control traffic among them but it is more a clever hack than real networking stuff) Use VLANs on the same physical interface As you can see, all of them are based on the principle of applying the shaper to a single physical interface Hi Georgeman, I've a similar situation in which I would like to limit the download speed of my DMZ and LAN interfaces. Could the limiter be another option to solve the problem? Thanks, Stenio

You are correct on torrents but I have a seperate torrent box at home (NAS computer) so I can direct its traffic to lowest priority queue by ip without a problem. I can advice everybody to do this. While it is easy to prioritize certain activities like voip and games to highest priority, it is becoming harder and harder to seperate traffic coming from port 80 generic servers. These include steam downloads and now this. So I created 3 seperate port80 queues. I'm trying to further prioritize certain web traffic from youtube,google etc. While doing this, I'm trying to deproritize port80 downloads to low priority port80 queue. But this isn't the best solution. It is still better than nothing.

You won't know about your priorities working or not working unless you set up a test where one of the higher priority queues is running enough traffic to shove the lower priority queue down, adequately continuously and for a long enough period that you can see what is or is not happening. It may be that "borrow must be on" for any of the children to borrow, rather than "it's trying to share your qlink." If qLink is not borrow=on, I think the borrow=on setting on qInternet does not provide it with any access to your 1GB LAN/qLink. You could explicitly set qLink to borrow=off and see what happens, but I think that is the default - but I'm also still very much in the place where the depths of what I don't know about the shaper exceed what I do know by a huge margin. You could also try setting qAck to borrow=off and see if you lose about 40% of your download on qLow, I guess. But that may not be the way borrow actually works. It would be a simpler experiment to set up, though.

I would assume so.

Hi Georgeman, I'm really interested in the solution you're using, we have to connect 4 remote sites and bring phones trafic to central site and priorise VOip in the VPN tunnel. Could you post the TS configuration you've done? Thanks, Thomas

I just set my receive queues to 2.5k. It's pretty much an issue just limited to traffic that can burst in quickly. Because interactive streams, like games, are on their own separate queue with reserved bandwidth, it seems to not affect anything except their own queues. Because the burst is being rate limited to fit into 48Mb/s in a much smoother fashion via PFSense, than Cisco, my machine cannot ACK data that it has not received yet, so the other side backs down. It seems to be that it's not so much the burst causing issues, but that my machine would normally ACK all of the data in that burst as quickly as it came in, indicating to the other side that I'm ready to receive more, when it really needs to back off before Cisco clamps down hard. This is mostly me just theorizing, but I am seeing much better results. I did find that I need to limit my P2P's queue size. During the ramp-up of a heavily seeded torrent, like Fedora, the hundreds of sending end-points would still peak over 50Mb/s on my WAN interface before leveling off, even though PFSense was making sure that I was only getting 48Mb/s. So while a large queue to soak the burst from a single sender works fine, a large queue for many senders that are all ramping up at the same time can cause issues. P2P also has a lot less burst than Google services. I don't really have the issue of 1gb micro-bursting from Torrents. If I remember correctly, Google uses a custom TCP setup where they purposefully burst the first X bytes at or near full line rate, to make better use of available bandwidth. They let network buffers worry about the bursts. The "problem" is that between my ISP and Google is Level 3, and no congestion. It just lets that 1gb burst right on through 8 hops and 250 miles.