2.0 is taking quite a bit longer than anyone expected, but we won't bind a cycle to a given date just for the sake of releasing it. It'll be ready when it's ready. :-) Hopefully the cycle will be much shorter for 2.1, but 2.0 is very ambitious, so much was added and changed it's taking quite a while to shake out all the bugs.

On my 1.2.3 pf system I run the shaper wizard and selected a few games from the list for higher priority then changed the mapped ports and names to the ports I actually wanted to use. This seems to work fine. Teamspeak Witch is already in the wizard (I host a server) and I Host an Urban Terror server . I have 6 other users that at any time could be using the connection for what ever 1 pounding on xbox live ( also shaped) and more on the lan playing Urban with 3 to 4 connecting from the internet to Urban and teamspeak. I also selected a few services I don't use to lower priority and most of the rest selected and left to normal. I have tested it by down loading a couple of torrents while we are all playing and the wan side players seemed fine.

@Cino: under traffic shaper, you can create limiters. You need to create 2 limters, one for upload and another for download. search the forum… There were semi-how-to post less then 2 months ago.. also check doc.pfsense.org I tried this on PF 1.2.3 and found that it did slow them down . I set time limits with xxx amount of Kb for x amount of seconds ( 30 usually) and then drop to xx Kb . This worked fine for web surfing and dropped the constant download speed after 30 seconds. The problem I found was my next months invoice from the ISP was HUGE with over usage charges . We had used close to double the normal and the next 2 months were the same so I deleted all my shaper rules and things went back to normal. Am I correct is the shaper drops packets on the lan side ? So the client pc resends the (we didn't get it ) ack and that's why the usage doubled?

Well, to answer my own question: Clone the queue to the lan interface and adjust the bandwidth. The Wizard does not create any rules for the LAN (at least in my case.) I was on the verge of reflashing to zeroshell, but I must admit I'm glad I didn't.  Like many things in pfsense, it works great once you finally figure it out.

I think you might take a look to the book Building Firewalls with OpenBSD and PF from Jacek Artymiak, I think its a very good reference. Hope this help

After further testing the problem only appears to be with passive FTP. Non-passive mode works ok so maybe the passive ports are outside of the dummynet pipes? I did try to create a seperate rule for the passive ports and also assigned them to the same limiter pipes but that did not work either. Will continue looking.

Hello All, Got this working…  So the following rules which can be added by the traffic shaper gui set the queues for VOIP traffic from LAN <-> WAN. block in all tag unshaped label "SHAPER: first match rule" pass in on  $lan proto tcp from 192.168.10.0/24  to any port 5060:5080  keep state tagged unshaped tag qVOIPDown pass out on $wan proto tcp from any to any port 5060:5080 keep state tagged qVOIPDown tag qVOIPUp pass in on  $wan proto tcp from any  to 192.168.10.0/24 port 5060:5080  keep state tagged unshaped tag qVOIPUp pass out on $lan proto tcp from any to 192.168.10.0/24 port 5060:5080 keep state tagged qVOIPUp tag qVOIPDown pass in on  $wan proto udp from any  to 192.168.10.0/24 port 5060:5080  keep state tagged unshaped tag qVOIPUp pass out on $lan proto udp from any to 192.168.10.0/24 port 5060:5080 keep state tagged qVOIPUp tag qVOIPDown pass in on  $lan proto udp from 192.168.10.0/24  to any port 5060:5080  keep state tagged unshaped tag qVOIPDown pass out on $wan proto udp from any to any port 5060:5080 keep state tagged qVOIPDown tag qVOIPUp pass in on  $wan proto udp from any  to 192.168.10.0/24 port 16384:32768  keep state tagged unshaped tag qVOIPUp pass out on $lan proto udp from any to 192.168.10.0/24 port 16384:32768 keep state tagged qVOIPUp tag qVOIPDown pass in on  $lan proto udp from 192.168.10.0/24  to any port 16384:32768  keep state tagged unshaped tag qVOIPDown pass out on $wan proto udp from any to any port 16384:32768 keep state tagged qVOIPDown tag qVOIPUp Nothing special there. However, as stated previously unless additional rules are added the FreeSwitch process on the box does not have its traffic sent through the Voip queues.  The default pfSense configuration sends the traffic through the wan default queues without priority elevation. /etc/inc/filter.inc needs to be modified to add the following rules. Setup FreeSwitch Server <-> Provider Traffic Shapper pass out on $wan proto udp from 192.168.0.12 port 16384:32768 to any keep state tag qVOIPUp pass out on $wan proto udp from 192.168.0.12 port 5060:5080 to any port 5060:5080 keep state tag qVOIPUp pass out on $wan proto tcp from 192.168.0.12 port 5060:5080 to any port 5060:5080 keep state tag qVOIPUp pass in on $wan proto udp from any to 192.168.0.12 port 16384:32768 keep state tag qVOIPUp pass in on $wan proto udp from any port 5060:5080 to 192.168.0.12 port 5060:5080 keep state tag qVOIPUp pass in on $wan proto tcp from any port 5060:5080 to 192.168.0.12 port 5060:5080 keep state tag qVOIPUp Note that this takes care of box <-> wan  it does nothing about prioritizing traffic to the LAN.  In our setup traffic to the LAN was fast enough not to require queuing so we just send the traffic through the default lan queue. However, a mirror set of rules could be added to also elevate LAN <-> FreeSwitch on pfSense router. Take care. --luis

You need to run the wizzard and do not choose any thing till you get to the section on P2P And in there add a host and choose the otions Once you come out of the wizard, customize to your hearts content. The defaults are "basic" lan defaults wan defaults and ACK queues. if you set you maximum internet speed for upload and download. Setting your up and down speeds auto shapes the default queues to those values.

I just pushed a fix for that error value. You have to wait for a new snapshot to come out since its a binary file fix. Thanks for reporting.

You can perform traffic shaping without NAT.  i.e.  pfsense box has 2 interfaces (2 VLANs) but you disable NAT. Basically, you retain pfsense as a routing firewall but without NAT.  I believe what you have done is to disable the packet filter (which is what the traffic shaper is based on).

First: You must have pf 1.2.3 Final Realease - not 1.2.2! Second: Use Traffic Shaper wizard again and then delete(disable) unused rules. Don't check "Random Early Detection In and Out". Settings created by Wizard's are TRUE . Don't change their unnecessarily. That's all.

Great, will try that and post back, thanks a lot  :)

PRIQ has this limitation as part of its algorithm. I will try to teach the GUI about this so people get a reasonable message. Otherwise there is a limitation of 4096 iirc on other algorithms.

You can make a WAN rule with a destination of the LAN IP involved (NAT happens before the rules are processed) or you could put a rule on the floating tab, on lan, in the 'out' direction.