i am searching now to see if its possible to link pf statically… the ordering needs to be PF before ipfw ? ipfw can be linked statically quite easily... edit: ok, dumb me :P pf can be linked statically... im downloading pfsense developers edition and i will give it a try... pf statically and ipfw as a module, lets see if this solves the problem... edit2: while searching for this bug i found that theres not a lot of people trying to fix this bug, at least thats what i saw on the pf-freebsd list...

per IP, up pfsense 1,2

Hola wn. I have a similar connection 4096KBps Down/512KBps Up and the best number so far is 3968 for qlanRoot , and 496 for qwanRoot This is about 96.875% of connectioon speed  ie. 4096x0.96875=3968. I,m using TERRA NETWORKS CHILE S.A. also make sure you have values similar to these for the Traffic Shaper 34 %    Bandwidth qwanacks   5 %    Bandwidth qlanacks –----------------------------------- Wait for someone with real knowledge to answer your question though. Use this URL for your SPEED TESTS http://www.speedtest.net/index.php

No, unfortunately it is not possible.

Hi, I've been scouring the net for this specific problem, specifically that Remote Desktop (RDP) will saturate over a WAN connection when viewing highly graphical content, e.g. ppt files, graphically intense web pages, active content etc. I was thinking about this, and realized that the only reason packet shaping works with downloads is because packets are dropped until the machine you are downloading from gets the hint to stop sending packets. Correct? So, considering that in this situation you have one server with many RDP sessions, if you attempt to limit RDP downloads per session on the client side with packet shaping, this may not actually do anything because everything we want to limit is coming from the same IP. As far as the server goes, it will try and transfer X RDP packets, the server side internet connection will throttle packets (including printer stuff etc) down globally to match whatever the client is receiving, but most of what is transferred will still be whatever is hogging the queue. I suspect that the optimal solution to this problem would be to stick the packet shaping box between the RDP server and that server's internet connection. That way you can truly limit where the bottlenecks are - packets sent from the server to the various WAN terminals. It would also be cheaper, since you'd only need one shaping box. After all, most of the upload at the WAN ends are just keyboard presses, mouse clicks and pointer positions over RDP, which should be fairly minimal and constant info. Will try it and see how we go.

Been exploring pfsense more (and tearing my hair out over captive portal, ill post about that later). It would appear that traffic shaping rules by schedule are not in pfsense so ill go and write some shell scripts instead. Consider this topic closed.

UPNP does not recognize anything. it just reports what the UPNP client say's what he is called.

Well I figured it out on my own. I found out the port that my company's VPN uses for UDP NAT traversal (10001) and added it to the shaper config. Dont' forget to make sure your rules are in the right order! Sorry for bugging everyone.

So the problem is the same as multiwan option using pfsense itself? How is the Bounty system, how i send the money? regards Alfredo

instead of blocking it, try specify a small amount like 5kb and see if that helps. The idea been, that P2P wont fall back onto using http or another port.

There is a bounty started for it, that is all I know.