@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.

Need a pictorial representation of your setup for a more complete answer. The short of it is:  Catch your VOIP traffic by using the IP address of the Asterisk server in the rules.  Catch your OVPN traffic by using the destination port (address as well if both sides have static IPs).

Adjust your TBR size for starters.  This will prevent large downloads from hogging the line. If using Squid, look under Bandwidth management, you should be able to set it to throttle by extension or throttle per HOST.  The former will allow you to target downloads specifically without throttling webpages (the content might be affected if you don't do up the extensions properly).