In most cases rsync would look like ssh traffic, so if you shape/filter ssh it should catch rsync.

Rsync also supports a –bwlimit=KBPS parameter so you can have the NAS box limit its own backup if you set, say --bwlimit=80 then it would go no higher than 80KByte/s (not that's Bytes, not bits.)

I get the same thing and I was curious what this was. I never tested to see if it actually blocked this traffic so I don't even know if I did it right.

Just so you know, set it up with anything, say 10% and then edit the queue once the wizards creates the queues for you. If you are still using the shaper, then having to separate limits could put you over your bandwidth.

If you turn shaping off, does it continue to be an issue?

Can you make a call on both phones at the same time to different numbers and hold the call?

I really thing this is an issue with one of the providers of the phones, not a firewall issue.

Run the multi lan traffic shaping wizard. Answer the questions accordingly and notice it asks about p2p traffic and how you would like to prioritize it.

@rbblue8:

Hey,

Thanks for the response!  :-)

Do you see a noticeable difference when you make a call while downloading?

If you cap both your upload and download to just below your providers true limit, I found it sounds as good as if there was no one downloading at all. Just a couple of minor hickups but I was just calling my cell phone and leaving a message to hear the difference. I very rarely saturate my line so for this I did remove my sabnzbd's cap on usenet while downloading to do. So give it a shot, I think you'll be happy with it.

Million Thanks cmb, you're life saver :) been working on this issue for a week and cant find any info on internet about this.

HFSC doesn't actually have any sense of priority, that is just a GUI mistake.  So one queue doesn't really have any more priority than any other, except if a queue is marked as realtime, but that was designed for low latency stuff like voip, things that are not necessarily high bandwidth, they just need low latency.

The other problem is that bittorrent traffic is so ill-manered, it is hard to control.  Since bittorrent traffic is usually made up of hundreds/thousands of separate longer lasting and short lasting flows/sessions it doesn't react quickly to packet drops, which is the only way that a pfsense router can try to shape the incoming traffic, by dropping packets that have already made it to you, to try to get the sender to back off.  TCP/IP is supposed to back off it's transmit rate when packet loss is detected, but that doesn't work so well when there are 100 different connections that need to back off, and it doesn't happen instantly.

Web traffic on the other hand is made up of numerous short lived connections.  So when you view a web page there is a flurry of activity grabbing the different elements, and then it is done (internet video is obviously not like this of course).  So when you try to view a web page PFSense will try to slow down the bittorrent traffic, but it takes longer to slow it down than it takes for the web page to load.

Add into this the bufferbloat problem with most consumer grade network equipment, which just makes it worse since the tcp/ip backoff takes even longer with there are multiple seconds of packets buffered.

My suggestion is to just limit your torrent bandwidth to %40-%50 percent of your total bandwidth.  Game of thrones.. I mean your legal linux ISO's will still download in a reasonable amount of time, and other traffic will remain responsive.  Plus your ISP won't hate you as much (you should also consider not torrenting during prime time 6pm-midnight, which your ISP will again appreciate.)

You could also try the priority queuing shaping method, that actually does use priority, but it still won't be perfect.  Oh and one other person reported that making the p2p queue really huge, like 2000-3000 packets helped control bittorrent better… but I don't remember if that can be done from the GUI.

There aught to be a FAQ on this.

Oh and as far as I know, I think I know what I'm talking about, but I'm always happy to be corrected.
Josh

The network card also needs to be pushed into static arp mode,

pfSense can setup static ARP in the GUI in the DHCP settings, but I believe that requires you use the DHCP server on pfSense… if another box is your DHCP server, I don't know that it would work from the GUI.

Honestly don't know. I have never used the limiter. My guess would be to setup the limits and on your firewall rule use the in/out setting. I tried once, but it didn't work and I was not in the mood to learn it. So I just used traffic shaping.

That is in the traffic shaping rules and not the limiter. I have not utilized the limiter yet.

Be careful when classifying the ports for Steam.  The gameplay uses UDP ports, the downloader uses TCP.

You are likely to want to prioritize the gameplay and not the patching/ download ports, so don't match both TCP and UDP when setting up your rules.

I've used pfSense in a Cybercafe production environment before due to the traffic shaping capabilities (keep gamers infinitely happy while other users are happily streaming videos and chatting with loved ones back home) so it definitely would do what you need.

The main problem you are going to face is the actual rules configuration and the queues setup.