Hi, I tried this, but all the traffic went into the low priority queue. Is this because I had an 'Allow Any Any' on the LAN interface firewall rules?  I have at least one network where the requirement is that the traffic be shaped only, no egress filtering - how would I do this? Are you supposed to integrate the shaping rules into your regular firewall rules, or keep them separate in the Floating tab? Thanks, Todd

I'm not an expert by far but you'll find in the Firewall Rules -> Floating Rules where the wizard puts your VoIP queue rules. You can copy those and adjust them to make them work for FTP. As far as I understand it, usually if there is no VoIP traffic, other traffic will be able to use the whole pipe. I didn't use CBQ though so it might vary by the type.

Do not hijack threads. Start a new thread to ask new questions.

Hello, I just set floating rules for WAN and others interface but it doesn't have the result expected. In fact, the bandwidth is too much limited but I'm looking for bandwidth guarantees. What is the key to have bandwidth guarantees ? Thanks, Arnaud

No one?

UP !

Or you have UPnP enabled and he's transferring data through rules opened by UPnP which wouldn't get limits applied.

hi dreamslacker, i use 2.1-BETA AMD64 latest snapshot. i follow your config example, but the limiter only work on LAN interface. i try to add limiter rule in WAN tab, but it won't work also. do you have any suggestion? btw, i use squid proxy in transparant mode. [image: FW-RULES-FLOAT-03-EDIT.png] [image: FW-RULES-FLOAT-03-EDIT.png_thumb] [image: FW-RULES-LAN-02-EDIT.png_thumb] [image: FW-RULES-LAN-02-EDIT.png]

Anyone?

Thanks for your reply. I got this idea from Kerio Control that does just what i said but kerio control is very expensive and you get free trial for 30 days only.

Other than the sticky above on this particular forum Id be clueless. But I will add that Ive had great success with the qos that is part of the Siproxd package.  You have to enable it but works very well here. Good Luck!

The answer sadly is 'it depends'.  DS3 lines (I'm taking a shot in the dark that is what you have) are pretty stable and have good SLAs.  Assuming you are going to an ethernet private line or other service of similar caliber, you can likely run up to the high 90s percent wise (97-99) asuming you have a good /stable carrier. The short answer is as long as your limits / QoS rules 'kick-in' before the carrier's your all set.

have you researched the formal commercial support? https://portal.pfsense.org/index.php/support-subscription

Update and more info… I'm running: 2.0.1-RELEASE (i386) built on Mon Dec 12 19:00:03 EST 2011 FreeBSD 8.1-RELEASE-p6... I found that a different rule was stepping on the one above and placing it in the default queue.   (I feel a little more sane now).   Here's where I'm getting tripped up.   if I remove all floating rules and ensure that no other rules have a queue action and add a default rule for to prioritize ACK traffic things start to fall apart. Here's a test I performed trying to understand how 'quick' performs on non-final rules (Queue only, not pass, block, reject, etc.) Test 1: Default rules before specific 'work' rules. In this test all work 'outbound' traffic is placed in the default rule.     pfctl -sr | grep queue     match quick on vr0 all label "USER_RULE: Default Queue - Prioritize ACK" queue(q_Default_3, q_ACK_6)     match quick on vr1 all label "USER_RULE: Default Queue - Prioritize ACK" queue(q_Default_3, q_ACK_6)     match quick on vr2 all label "USER_RULE: Default Queue - Prioritize ACK" queue(q_Default_3, q_ACK_6)     match in quick on vr1 inet from any to 192.168.1.0/24 label "USER_RULE: QoS Work (inbound)" queue q_Work_5     match in quick on vr2 inet from 192.168.1.0/24 to any label "USER_RULE: QoS Work(outbound)" queue q_Work_5     pfctl -k 192.168.0.0/16     killed 49 states from 1 sources and 0 destinations     re-establish tunnels on appliance and watch pftop Test 2: Default rules after specific 'work' rules. In this test all work 'outbound' traffic is placed in the default rule.     pfctl -sr | grep queue     match in quick on vr1 inet from any to 192.168.1.0/24 label "USER_RULE: QoS Work (inbound)" queue q_Work_5     match in quick on vr2 inet from 192.168.1.0/24 to any label "USER_RULE: QoS Work(outbound)" queue q_Work_5     match quick on vr0 all label "USER_RULE: Default Queue - Prioritize ACK" queue(q_Default_3, q_ACK_6)     match quick on vr1 all label "USER_RULE: Default Queue - Prioritize ACK" queue(q_Default_3, q_ACK_6)     match quick on vr2 all label "USER_RULE: Default Queue - Prioritize ACK" queue(q_Default_3, q_ACK_6)     pfctl -k 192.168.0.0/16     killed 49 states from 1 sources and 0 destinations     re-establish tunnels on appliance and watch pftop Test 3: No Default Rules. In this test all work traffic is placed in the correct q_Work_5 queue.     pfctl -sr | grep queue     match in quick on vr1 inet from any to 192.168.1.0/24 label "USER_RULE: QoS Work (inbound)" queue q_Work_5     match in quick on vr2 inet from 192.168.1.0/24 to any label "USER_RULE: QoS Work(outbound)" queue q_Work_5     pfctl -k 192.168.0.0/16     killed 49 states from 1 sources and 0 destinations     re-establish tunnels on appliance and watch pftop I guess I'm confused at how 'queue' type rules work when there are multiple matches in the ruleset.  Can someone provide any clarity. Thanks!

Do you have a specific rule that puts the various IMAP ports into a different queue?  p2pcatchall will match everything that isn't specifically matched. Josh

Thankyou ermal, dreamslacker & Metu69salemi. Yes i'm on v 2.1 . I saw the path now. I will walk as per your direction. I'm sure i will reach the destination. many thanks Kalu