I have about the same setup as devnull, and the same issues, i have read that the traffic shaper just will not work for multiple lans in 1.2.x.

But i just have to find a solution!!

no i can't go to a beta 2.0 i would love too but i just can't yet.

What i have been thinking lately is setting up a 2nd pfsense box in front of my existing and using it just for shaping.  My only problem is that i just can't seam to get my head around if i'm on the right track.

How can i configure PF sense to pass all my public ip traffic from one IF to the Next, traffic shape and not consume one of my public IPs.

basically looking for a transparent firewall.

I know i'm just missing one piece that is going to make it click i just need a kick in the butt to get me going.

Anyone got a big boot to help me out.

Run the traffic shaper and enable the catch all rule and input the lowest kb speed for up and down that you want.

Actually, traffic shaping works both ways even if installed at one side of the link for any application that has flow control (like everything over TCP).

A traffic shaper will take all incoming packets (with or without data - including TCP acks) and will release it according to the bandwidth min/max/priority policies that were set. This way, for example, ISPs can shape uploads with nothing installed at the subscriber home.

Azi Ronen - The Broadband Traffic Management Blog - http://broabandtrafficmanagement.blogspot.com/

I can confirm that. I moved from 1.2.2 to 1.2.3 and ping issues started with nearly the same configuration.

That kind of suck cause I mainly choosed pfsense for it traffic shaper and it seems that the stable version with proper shaper would be 1.2.2 only which is somehow not stable on my net5500 box :(

Well I'm quite fresh after the wizard and in the Rules tab all qOthersH are higher then the qp2pDown or qp2pUp so I guess we have different results with similar setup  :-[

Traffic shaping doesn't work properly on 1.2.x with multiple WANs, this is one of its well-known limitations. You can't fix the problem you are seeing without making traffic shaping essentially useless on the downstream side.

You can upgrade from 1.2.x to 2.0 without any problems, or that is the goal. It won't be out "shortly" though, it's several months away from anything like that.

No, that doesn't work on 1.2.x.

If you need to do complex shaping tasks, you really should try out the 2.0 BETA.

From what I've heard, Skype is particularly hard to classify. Like bittorrent, its clients don't always use the same port, and it opens whatever it wants via UPnP. However you can set a specific port inside of the skype client.

With only 10 people it wouldn't be hard to ensure that they were all set to use a small range of ports, and then manually set those ports to make it into the proper queue. That doesn't solve the problem of the outgoing traffic, which will still be to a random client port, but it may at least help.

thanks for your reply ermal,any documentation about new shaper?

@jhabers:

Thanks dusan, dumb question but for the values you gave me for the ack queues, do i put those nubers in the real time m2 or in the bandwidth for the queue (the one at the top)

That's not a trivial problem.

1. Actually, the numbers say that for 6M/384K ACK packets occupy 63.15% (or 51.28% if you believe in formulas) of uplink if uplink and downlink are both saturated by TCP only. (The underlying model is robust enough to cover virtually all TCP protocols so there are no needs to care about the specific TCP protocols in use.) In reality, however, there are UDP, ESP and other traffics which may reduce the ACK queue size requirements. It would be therefore reasonable if you start at about 40% and increment it a bit in case of need.

2. Real-time curve protects queue's bandwidth better. But real-time bandwidth is a resource that should be allocated very carefully. So, don't use the entire 40% of real-time bandwidth for the qWANack. Rather, set qWANack linkshare's m2 (i.e. the Bandwidth) = 40% and real-time's m2 = 5-10%.

3. The rest (70-75%) of real-time bandwidth should be allocated to other traffics, again, with great care. Therefore, for the most bandwidth demanding traffic (VoIP) I've recommended to try with 200 kb/s = 52%.

What you describe is closer to the truth, but I think there is a little confusion in both areas.

Traffic shaping does not happen on the interface it enters, it happens on the interface it leaves. That is a fact of life, it's the only way shaping can happen, because that's the only place it can possibly be limited. So, downloads are limited when they leave LAN, uploads are limited when they leave WAN.

Content is not "cached" in any way, but if some packets are dropped, which will trigger a resend, eventually the sending side will throttle itself back. Through a combination of this dropping/throttling of packets, the traffic is effectively limited.

Hi people!

After three weeks of intense research and to bother some great guys in the forums( ;D) I realized that the way to accomplish that I want it is easy(i am lair :D) to do with a pfSense 2.0 box, and almost impossible to do with pfSense 1.2.3.

Finally I'm be able to configure the traffic shaper(ufffff) and I want to share my experiences with both newbies and old-mans in this matters.

When I have a five(and I will have), I will post data of my network topology, the requeriments for my network and a guide how I accomplished the requeriments.

I believe the main difference is that PRIQ will reorder packets so that the higher priority ones are passed first, and can't control bandwidth used in the way that HSFC can.

If you really want to reserve that bandwidth for VoIP, you may have better luck with HFSC. (but I may be wrong here, someone who knows the altq innards better than I do would probably know for certain)