Jump to content
RESET Forums (homeservershow.com)

QoS and PfSense


Jason
 Share

Recommended Posts

Starting a new thread to troubleshoot in hopes that it may help others.  Per timekill's recommendation, I've re-configured my pfsense 2.1-release to use PRIQ traffic shaping instead of HFSC.  Of course I saved my HFSC config file as a backup.  My goal was to improve my Ooma voip voice quality as the Ooma device cannot be put into "bridge" mode if placed between a modem and router.  Placing the Ooma behind my pfsense router using HFSC Qos was a never ending challenge.

 

I've since:

 

1.) re-setup pfsense 2.1-release traffic shaping with 1-WAN and 1-LAN

2.) selected PRIQ method

3.) My cable service is 50 Mbit/s (downstream) and 5 Mbit/s (upstream)

4.) I noticed that unlike HFSC, the traffic shaping wizard for PRIQ includes:

 - WAN (I set this interface to 5 Mbit/s)

 - LAN (I set this to 1 Gbit/s) - my LAN is on a gigabit switch

     - the wizard auto creates a LAN > qLink child queue, but not a qInternet queue like HFSC mode did.  Nor do I have the option of setting a bandwidth limit for the qLink queue

5.) I've defined a static IP address (192.168.0.14) for my Ooma.  I've defined in my pfsense 'FLOATING' rules that all traffic for this static IP go to my qVoip queue

6.) Confirmed when using my Ooma, the pfsense qVoip queue now shows that traffic is being sent to this queue

7.) Have saturated my downstream with no noticeable loss of quality while making a phone call

8.) Left a voicemail to myself on another phone while internet bandwidth saturated and the voice quality (for another caller) was crystal clear w/o dropouts

 

Now -- I'm trying to route my Crashplan backup traffic to my qOthersLow queue, but no matter what I do, no traffic is being sent to this queue.  Instead it goes to my qDefault queue.

 

I've tried to:

1.) send all traffic to Crashplan's internet IP into qOthersLow without success.  Since it's backing up over HTTPS, it seems to send the traffic to qDefault (my HTTPS queue)

2.) Remove any floating rules for HTTPS traffic; still no luck

3.) This approach previously worked using HFSC on the same pfsense router so I cannot figure out why it isn't in PRIQ?

 

Often I saturate my upstream for cloud backup (Crashplan) and do not want to have schedule it only to occur at night if I can help it.  I have unlimited bandwidth in both directions; want to take advantage of it while it lasts.  I simply want to be able to saturate my upstream (5 Mbit/s) during business hours and have cloud backup sent to the lower qOthersLow queue and my ooma voip traffic sent to qVoip which it currently is.

 

Hope this makes sense?

Link to comment
Share on other sites

This was a problem for me as well. I came up with three solutions - one using a hammer, and one more scapel but less consistent, and one that should work but I wasn't able to confirm before moving on from CrashPlan

 

1. Hammer: Reducing 443 outgoing traffic priority. However, in order to not drop legitimate HTTPS traffic, I set the rule to only affect traffic of a certain (high) amount.

   Basically define Port 443 traffic as "file transfer" which is a low priority for any outbound data but set the size > 512kb.

 ---BTW CrashPlan traffic does NOT use just 4242, unles you are backing up internal to LAN only. I discovered this when I was doing port forwarding and QoS work. The upstram traffic to WAN uses 443.

 

2. Scalpel: Determine the CrashPlan IP range and apply it (I used a /24 since there was a fairly broad range) to your outgoing rule.

 

3. Under the network tab of CrashPlan, near the bottom is a setting for "TCP packet TOS." Setting the WAN level to LOW is *supposed* to mark the packets, but the marking they use is deprecated. However, if you set a custom DSCP decimal value you can use your own marking. The setting that was suggested is 56 (which is the decimal equivalent of QoS marking af13 - which will be relevant when you get to the pfSense part.) Then go to your pfSense rules and under advanced features sett the "Diffserv Code Point" to af13. AGain, I never tried this so can't vouch for it.

 

A possible fourth solution which looks viable is here: http://blog.paulgeorge.co.uk/2012/06/07/crashplan-upload-traffic-with-dscp-tos-and-qos-on-windows-7/ although it would only work on WIndows 7  and later MS OS's.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...