Open source WAN acceleration doesn't exist in a stable, production-grade format, at least nothing comparable to what commercial (and pricey) WAN accelerators do. Though RDP isn't one of the benefits of having WAN acceleration, their primary benefit is with protocols like SMB that are by their design terrible over higher latency, and the magic WAN accelerators put in the middle works around the poor protocol design. Traffic Squeezer can do compression on compressible traffic, but RDP is not compressible. Compressing non-compressible traffic, like anything encrypted, actually makes it bigger. The best any WAN accelerator could do with RDP is muck with TCP window settings and related things that combat the usual issues with long fat pipes where it's hard to reach the capacity of the line without doing so. Nothing they do would help with RDP on slow connections. Changing RDP settings as people have suggested here is your best and really only option regardless of what devices you have on the network.

I built a test FW on 2.0 and applied the limiters to the lan interface and speed tests are showing the limited traffic speeds. Pretty easy once you put the right things in the right places!

Here is a good link talking about it
http://doc.pfsense.org/index.php/Traffic_Shaping_Guide#Limiter

Thanks for the pointer. Time to go update my FWs.

I asked because FAIRQ isn't listed in any of the 2.0 traffic shaping wizards, nor is it mentioned in the wiki pages. In both cases only HFSC/CBQ/PRIQ are listed. But you're right, FAIRQ is available in the traffic shaping settings.

Currently, a viable way to limit P2P traffic (which is mostly encrypted) would be to try to prioritize as many "known" services as practical (e.g. dns, http, smtp, pop, imap etc) and then just put all the rest (which would include P2P) in "bulk traffic" category with low bandwidth.

L7 might be used to identify & classify certain protocols that also encrypt their traffic, e.g. Skype (I posted about it in this sub-forum a few weeks ago).

Another way that I've considered would be to use pf's max-src-conn-* options to limit the total number of open connections for each IP, but pfsense currently puts the "offending" IPs into the <virusprot>table and thus blocks them altogether…

To clarify, I'd like to define an alias known_ports = "{ 22, 25, 53, 80, 443, etc }" and then add a fw rule

from LANnet
to any
port !known_ports
max-src-conn-rate 4/60

Since P2P connections tend to be numerous, short and bursty, with the only common parameter being the src-IP (the client running the P2P software), I would think it would throttle them down a bit.</virusprot>

Tomax,

could you share your shaper configuration? In other posts (http://forum.pfsense.org/index.php/topic,42003.0.html) I've said that same issue is happening to me and one member of the group told me is due to ping is catched by the default queue.

Hope this helps.

Thanks in advance

I would actually be interested insetting up something like this as well, but the scenario I have is with wired connections (1 WAN and 1 LAN as well).

I just want to ensure that nobody "strangles" the connection for everybody (eg.: downloading torrents and eating up the connection for everybody), but I don't want to limit users when it is not necessary.

The torrents were just an example, I want to ensure proper behavior with all types of traffic.

Best regards!

It doesn't work from WAN to LAN because the unit is in NAT mode.  You can't expect to ping from WAN to LAN without a port forward done for that purpose (and even then, to ping to that port on the WAN side).

If you ping from LAN to WAN and there is a response, it means that communication works both ways (obviously, the packets need to return through WAN to LAN in order for the ping to be successful).

@mamruoc:

First of all,

thank you for answering me.

Yes, I'm on pfSense 2.0

What you just told me is probably 100% correct and make sense for other people, but not for me.
I did not understand too much, nor have I found any good documentation, so I'm kinda lost… This way one of the reasons I went away from pfSense before, but now I really want to make it work.

Could you please be so kind to give me a bit more detailed explanation?

Thanks!

CBQ basically commits (guarantees) a certain bandwidth per queue and there is a priority setting.  When 2 or more queues have exceeded the commited bandwidth, priority is used to determine how much of the remaining bandwidth is allocated (borrowed) to each queue.

I have no idea how you want to shape your traffic but the most basic is just bandwidth for both VLAN subnets as a whole.

Let's assume VLAN1 has subnet 10.0.1.0/24 and VLAN2 has subnet 10.0.2.0/24.

Also assume that you create 2 queues for your shaper ->  qVLAN1 & qVlan2 (set this as default to keep the shaper happy).
Depending on your needs, set the commited bandwidth accordingly.  You might want to set say 400Kbps and 100Kbps respectively.  This leaves 4.5Mbps of bandwidth for borrowing.
Change the Priority of qVLAN1 to 4 and qVLAN2 to 1.  This approximates a 4:1 borrow ratio if I recall correctly.
Note that this needs to be done for both upload and download queue sets.

Any traffic heading out to WAN for these 2 subnets will have to go through the allow any any rule you'd need by default.
Under firewall rules, look in VLAN1 tab and find that rule.  Edit it and set it so that the traffic shaping queue is set to qVLAN1.  Ignore the Ack queue for now since that is beyond the current scope and you can change the rules and edit the queues later when you get the gist of the shaper.

Go to VLAN2 tab and do the same except that you set it to qVLAN2 for the shaper.

This settles your outbound traffic.

Now go to Floating rules.
Make a new rule on quick match.  Set the 'In' interface to WAN and any for protocol.
Set the Source to any and the destination to 10.0.1.0/24 subnet (VLAN1 subnet).
Set the queue to qVLAN1.
Repeat for VLAN2 by changing the destination subnet and queue respectively.

This settles the inbound traffic to each VLAN.

ok
I will test both on LAN, many forum users says that this works, but I still believe that it'd be better: upload on LAN and Download on WAN..

thanks

after my test I will post again the results I get

@Jason:

I don't see where I can apply a limiter to an entire interface, just the firewall rules.

Under floating rules, you can use the In on the specific interface to match traffic.

e.g.  In on LAN would imply traffic going from LAN to WAN (or another subnet) -> outbound traffic

Naturally, this applies to any other shaper rules you may have for specific protocols/ source/ destination masks.  In this case, you can still apply the In (if there are no other limiters applicable) or Out (if there is a per user limit already applied).

Check http://doc.pfsense.org/index.php/Traffic_Shaping_Guide#Using_Layer_7_with_a_bridging_firewall on enabling the bridge for shaping.

You will then use the floating rules on per interface (of the bridge) to enable shaping.

Hi Mete,

Is it possible to show how you have it setup with screen shot preferably. It would help others too.

Tks
Eric

Sorry about the earlier post as I was really bogged down by the traffic shaper. Reading thru the forum and took the advise to look at pftop and not the GUI was showing proper queues but still there are a few quirks to iron out like bandwidth allocation. Maybe I still need to manually do it all by hand till the devs sort it out in the wizard. All in all though I am still very happy that squid and havp are working smoothly. :)

Tks in advance
Eric

Thanks!

I'll try it right away!

I have that with daloRADIUS. Each user has 1GB free per month (it's a hostel) and they can buy additional data packs. It does require a manual reset of the free plans, though. I suppose a clever cron job could run that every 1st of the month.

Bear in mind that traffic accounting seems to be broken in pfSense 2.0-RELEASE. I'm seeing a big increase in traffic usage reports from RADIUS even though the ISP saw no difference on the monthly usage. It seems pfSense is incorrectly multiplying the real traffic used (sometimes by 6 times).

Pretty much the same as here: http://forum.pfsense.org/index.php/topic,39555.0.html

Ahhhh
I think I found out the issue that you're describing.  If you do not assign HTTP (or whatever) to a higher or lower priority queue, it is left to the default, which doesn't automagically assign ACKs, due to no rule being there.

If you want that behavior though, the easiest way I've found is to create a rule on the floating tab, with something along these lines:
Action:queue
protocol: any
source: any
destination: any
queue: qACK/qDefault

Then, move this rule to the very top of the floating tab before all other rules.  All traffic will then have access to the ACK queue by default, and it will allow other assignments to change the traffic to another queue is needed.

The bad news is that there will be an extra rule to process for each state.  Under light use, this won't be a problem, but when you get to heavy business rates, it could choke the CPU.

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