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!)

Check the limiters on Firewall->Traffic shaping.

Ignore me. There is always simple answer. DMZ port wasn't connected to anything. Once I plug the cable into the switch I could create rules without errors what I've mentioned in first post. Hopefully it will help someone.

Maybe open a ticket at pfsense bugtracker http://redmine.pfsense.org/projects/pfsense attaching the full contents of your /tmp/rules.debug and shaper-related portion of your config.xml file?

Hello, I've made this working as it should be in version 1.2.3. It was definitely down to our ISP provider as I didn't do to many changes, then we've switched over to fibre optic and QoS for VoIP is working as a charm. Even though I'm going to switch to 2.0 version of pfsense. Already some problems with the config but overall I think 2.0 version is a way to go right now. Thanks Andre