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.

@KOM: From what I have also read, blank LAN bandwidth equates to "100%".  We might get more detail with the output of the pfctl command. Since bandwidth is just LinkShare, based on what I've read, the m2 in LinkShare should always override what's in bandwidth. Having said that, I went back and removed all of my link shares and just set my values in bandwidth instead and I set Real to the same as Bandwidth. It works! I may not have it set optimally, but good enough. I'm just a home user. It's easy for me to test my download, but it's hard to test my upload. Anyway, here's the results. You'l notice that my quality graph shows my ping going down. My ISP's gateway seems to respond to pings more quickly under load… Probably a thread scheduling thing, since ping responses are handled by the host CPU and not the ASIC. This has solved my random packet-loss during high utilization. I normally get 0%, but some times when hammering my connection, it will get into the 0.04% range. Thanks everyone! P.S. If someone has a better way to loadtest my connection than Torrenting Linux ISOs while running SpeedTest.Net, I'm all ears. [image: TrafficShapingResults.png]

Again, I have little experience and am just learning myself. You could set the default queue to have virtually no bandwidth, then create other queues for stuff like games and web. So 80/443 would get web, and you could add a list of known common games and add their ports.

But if you have multi-LAN and limit each LAN to it's proportional share of the WAN, then are you not essentially setting an upper limit for each LAN?  If you have a 40 Mb link and 4 LAN queues and giving each LAN queue 10 Mb, then if you have a busy LAN and 3 quiet ones, you are limiting the busy LAN to 10 Mb.  This all depends on how the WAN/LAN speed settings affect everything.  If it's just a value used in calculations and the queue will absorb whatever bandwidth is available, then fine.  If it also acts as a hard cap then that's a problem.

How will I setup port forward if I have 2x WANS? with LAGG!

@Ecnerwal: I do not concur that "no documentation is a good thing." FAIRQ is not an option in the Wizard setup (at least on 2.1.3, where my applicable system sits for now, but I bet the same is true in 2.1.5) though is IS an option for scheduler type on the shaper, non-wizardly. My experience of the "wizard" is not all that happy anyway. I suppose you could try PRIQ in the wizard and then change it to FAIRQ. Either way it's the moral equivalent of wiggling a screwdriver blindly in a high-voltage box in the hopes that it makes the right connection, with the documentation where it sits now. It appears to me that most of what's mentioned in this retired topic from 2010/11 still applies to the shaper today. It certainly feels all too familiar and current. The fact that the shaper documentation (as linked from 2.1) still starts off with 1.2.x and then has 2.0 (work in progress) [but the work has never progressed] is rather depressing. https://forum.pfsense.org/index.php?topic=26782.msg139435#msg139435 I don't see a question in there…  ??? There are (many) more places to find pfSense documentation than the official wiki. I gained a bit of insight by reading source-code for FAIRQ, which was initially introduced in DragonflyBSD. Maybe that will help you too? I'm no C coder, but there are useful comments in the source-code. For a super simple FAIRQ setup, you simply select your outbound interface in the Traffic Shaper, select FAIRQ and click Add queue. I think it is best to explicitly direct traffic into the queue because I think the maintainer of FAIRQ recently fixed a bug that was causing problems when traffic was defaulted into FAIRQ, and I'm not sure if that bugfix has been merged with pfSense's FAIRQ yet. (Disclaimer: I may not know wtf I am talking about.) P.S. - I never said "no documentation is a good thing". Documentation is out there, you just need to find it. I did, and I'm a newb. :)

Hi, did it work pierre_rs?

Ok… thank you for your confirmation.

@Derelict: When you set the destination slots there's really no reason to set burst.  They get the full download speed unless someone else is in contention for it anyway.  Unless there's a reason you don't want someone to run free if the capacity is available, I'd just ditch it. Actually, looking at it, it's really not going to do much for you, because the "Limit" that's going to be applied after the burst is exceeded will be the same as if no burst was applied at all. Thank you once again for the explanation - I see your point. I need to study up more on this. If bandwidth is available, I'd certainly want to allow any host to run free. However, when it's peak hours, I'd like to split evenly among hosts, which is what it does now and works great. The last think I'd love to have happen is to actually have it not quite split evenly between hosts when certain hosts have been downloading steadily while others are just trying to pull up a website. I thought that was something that burst would help with but perhaps I need to configure it differently.

I think you're going to have a hell of a time trying to get a TDM circuit transported over a 300ms RTT VPN link.  No amount of traffic shaping is going to make that any better.  SIP trunking would probably be better, but 300ms is a lot for that too.