Check http://doc.pfsense.org/index.php/Traffic_Shaping_Guide#Using_Layer_7_with_a_bridging_firewall on enabling the bridge for shaping.

You will then use the floating rules on per interface (of the bridge) to enable shaping.

Hi Mete,

Is it possible to show how you have it setup with screen shot preferably. It would help others too.

Tks
Eric

Sorry about the earlier post as I was really bogged down by the traffic shaper. Reading thru the forum and took the advise to look at pftop and not the GUI was showing proper queues but still there are a few quirks to iron out like bandwidth allocation. Maybe I still need to manually do it all by hand till the devs sort it out in the wizard. All in all though I am still very happy that squid and havp are working smoothly. :)

Tks in advance
Eric

Thanks!

I'll try it right away!

I have that with daloRADIUS. Each user has 1GB free per month (it's a hostel) and they can buy additional data packs. It does require a manual reset of the free plans, though. I suppose a clever cron job could run that every 1st of the month.

Bear in mind that traffic accounting seems to be broken in pfSense 2.0-RELEASE. I'm seeing a big increase in traffic usage reports from RADIUS even though the ISP saw no difference on the monthly usage. It seems pfSense is incorrectly multiplying the real traffic used (sometimes by 6 times).

Pretty much the same as here: http://forum.pfsense.org/index.php/topic,39555.0.html

Ahhhh
I think I found out the issue that you're describing.  If you do not assign HTTP (or whatever) to a higher or lower priority queue, it is left to the default, which doesn't automagically assign ACKs, due to no rule being there.

If you want that behavior though, the easiest way I've found is to create a rule on the floating tab, with something along these lines:
Action:queue
protocol: any
source: any
destination: any
queue: qACK/qDefault

Then, move this rule to the very top of the floating tab before all other rules.  All traffic will then have access to the ACK queue by default, and it will allow other assignments to change the traffic to another queue is needed.

The bad news is that there will be an extra rule to process for each state.  Under light use, this won't be a problem, but when you get to heavy business rates, it could choke the CPU.

Ugh… Nevermind. IE9 is not liking the button inside the A href.

OK…. Thanks.

Remove shaper should do exactly that.  If you are still experiencing issues, double check your modem by connecting directly and performing a speed test.  I'v ehad this issue myself, before, and learned that there was an issue with my DSL2 link that was the actual limiting factor.  A call to the ISP resolved it once a tech came and found a faulty bridge that had allowed water to seep into it.

If you still experience issues, double check the limiters page, and make sure that all floating rules are removed (which should have happened then you clicked remove shaper).

Really rare occassions you need to adjust source ports, but i mentioned needed ports. that may include 80 & 443, and not 80:443

I don't understand it fully but you should be okay following the wizards. Just put in some conservative numbers for up/down bandwidth and then use a static/reserved IP for the phone and put that in there. VoIP will have priority over everything else just like you want.

I have found the problem: the Trafic Shaper Wizard doesn’t create the Floating rules in the Firewall Rules.
I had test many time, but in 1 of my 2 virtual machine it doesn’t works.

Looking at the Firewall: Traffic Shaper page
The WAN queues are:
qACK
qDefault
qP2P
qVoIP
qOthersHigh
qOthersLow

In location B there are only drops in qACK and qDefault. In location A qDefault and qOthersHigh are the only queues with drops.

They each have the same queues configured the same way on the same provider's T1.

Thanks!! , I did a test with my system and works very ver well.

Regards and thanks again

Sounds like it's not quite the same issue but possibly reading this post may help you:
http://forum.pfsense.org/index.php/topic,32833.0.html

@skear:

I'm not sure what settings you have in place but you might consider clearing it out and checking out the guides below.

Traffic Shaper Walkthrough

http://doc.pfsense.org/index.php/Traffic_Shaping_Guide

I have done everything explained in those tut. Still I cant get it to work properly.

OK, so I went about this a different way.  Since port 80 traffic was already being treated as medium priority in the default queue, I got rid of that rule.  The roku device now goes into the correct qstream queue with high priority.

Thank you.

Sounds good, but that's not really what I meant.

My question is: in my scenario (nntp traffic lowest priority, all other traffic normal, processor PIII already straining to keep up with the traffic shaping (35% when there's a lot of nntp traffic)) which ones should I check? I guess there's a trade-off somewhere between processor power and extra methods checked.

Can anyone shine a light on this? I can read about the theory but I would like to hear some practical experience.

(Again thank you Setsun for your help!)