From TomatoUSB to pfSense
-
Hi all,
I've moved from TomatoUSB over to pfSense 2.3.1_1
One of the biggest reasons for the move is my old router (WRT54G-L) has lived for well beyond its technological age thanks to aftermarket support such as TomatoUSB. It just cannot cope with 40+ devices, p2p, etc etc.
I figured I could do the same with pfSense as its limitations would be hardware. The more i throw at it, the more powerful the "router" can be.
I understand that there isn't a foolproof method of shaping P2P, thus, giving priority to everything "common" (such as games, http(s), chat programs, etc) to the average computer user would be ideal. This is how TomatoUSB does it; prioritize what needs prioritizing, and leave the unimportant stuff as "bulk".
Now that I have pfSense up and running, I can't figure out how to replicate TomatoUSB into PF. What I had in Tomato worked great, just the NAT'ing and sorting rules are a bit slow. Hence the move to pfSense.
I've played with the wizard (CBQ, PRIQ, HFSC, and various combos), I've created my own queues, played with all settings.. set float rules…....to no avail.
Internet specs:
25/6 fiber line (speedtest.net shows a consistent 26894 kb/s, 6760 kb/s, 2ms respectively)
pfSense 2.3.1_1Please see attached and suggest on how to set it up?
![[toast] QoS_ Basic Settings.jpg](/public/imported_attachments/1/[toast] QoS_ Basic Settings.jpg)
![[toast] QoS_ Basic Settings.jpg_thumb](/public/imported_attachments/1/[toast] QoS_ Basic Settings.jpg_thumb)
![[toast] QoS_ Classification.jpg](/public/imported_attachments/1/[toast] QoS_ Classification.jpg)
![[toast] QoS_ Classification.jpg_thumb](/public/imported_attachments/1/[toast] QoS_ Classification.jpg_thumb) -
anyone?
-
What problem are you experiencing, exactly?
I think it is a bad idea to simply replicate the config you had with Tomato. Replicating the results is a much better goal and will likely require a much simpler config. (Your Tomato config seems wayyy too complex.)
-
What problem are you experiencing, exactly?
I think it is a bad idea to simply replicate the config you had with Tomato. Replicating the results is a much better goal and will likely require a much simpler config. (Your Tomato config seems wayyy too complex.)
Thanks for the reply.
How I had Tomato setup is that it will work for 1 user, or 250+ units in an apartment complex. It is almost a 1 rule-set that fit most administration needs.
Tomato uses a first rule match system. So, if you look at how my rules are set in Tomato from top down, it makes sense.The goal is to keep everyone happy with what they use…. at the expense of p2p. Since you cannot shape p2p directly, one can shape everything else to have priority over p2p.
To make it more simple:
Priority on VOIP, snappy HTTP(s), no lag gaming, no hassle video/audio streaming, quick downloads... and p2p takes the remainder unused bandwidth. -
What problem are you experiencing, exactly?
I think it is a bad idea to simply replicate the config you had with Tomato. Replicating the results is a much better goal and will likely require a much simpler config. (Your Tomato config seems wayyy too complex.)
Thanks for the reply.
How I had Tomato setup is that it will work for 1 user, or 250+ units in an apartment complex. It is almost a 1 rule-set that fit most administration needs.
Tomato uses a first rule match system. So, if you look at how my rules are set in Tomato from top down, it makes sense.The goal is to keep everyone happy with what they use…. at the expense of p2p. Since you cannot shape p2p directly, one can shape everything else to have priority over p2p.
To make it more simple:
Priority on VOIP, snappy HTTP(s), no lag gaming, no hassle video/audio streaming, quick downloads... and p2p takes the remainder unused bandwidth.Assuming that you understand how to deal with p2p upload & download (toastman's tutorial clearly explains this), then you only need to prioritize VOIP. You can find tutorials for this at the pfSense wiki, this forum, Google, etc.
The only thing that I see you might using that pfSense cannot do is allocate traffic differently depending on the amount of traffic a stream has transmitted/received. Example: After 10KBytes an HTTP stream is de-prioritized. Only Linux-based systems have that capability built-in.
This feature is less useful in the real world…Otherwise your needs (snappy HTTP(s), no lag gaming, etc) are too generic and seemingly encourage premature optimization, which is bad. If you allocate p2p downloads correctly and use CoDel on your uploads then all your needs should be met. No complex setup required.
-
Assuming that you understand how to deal with p2p upload & download (toastman's tutorial clearly explains this), then you only need to prioritize VOIP. You can find tutorials for this at the pfSense wiki, this forum, Google, etc.
The only thing that I see you might using that pfSense cannot do is allocate traffic differently depending on the amount of traffic a stream has transmitted/received. Example: After 10KBytes an HTTP stream is de-prioritized. Only Linux-based systems have that capability built-in.
This feature is less useful in the real world…Otherwise your needs (snappy HTTP(s), no lag gaming, etc) are too generic and seemingly encourage premature optimization, which is bad. If you allocate p2p downloads correctly and use CoDel on your uploads then all your needs should be met. No complex setup required.
Yes, I do understand how to deal with p2p uploads and downloads….. is not to apply a rule to it but prioritize known protocols. At least thats how I did it with tomato.
The other issue with my VOIP is that its an android app (Fongo) that I use on each phone (each phone has its own phone number). So its not a "proper" SIP or PBX, making it somewhat difficult to prioritize other than doing it thru ports.
I think i'm not understanding how to create the queues properly, what values to in which box.
Ultimately, I want to see the torrenting program, (uTorrent, BT, ed2k, etc ), speed drop when i start playing a 4K Youtube/Vimeo video, http download.
Is using CoDel a matter of a checkbox?
-
I've borrowed a queue setup from here: https://forum.pfsense.org/index.php?topic=79589.msg635074#msg635074. Courtesy of 1activegeek.
WAN - Bandwidth = 1Gb - qInternet - Bandwidth = 6570Kb / UL = 6570Kb / LS = 6570Kb -qHighest - LS = 15% -qACK - LS = 20% -qHigh - LS = 15% -qMedium - LS = 20% -qDefault - LS = 20% (default) -qLow - LS = 8% -qLowest - LS = 2% LAN - Bandwidth =1Gb - qInternet - Bandwidth = 26300Kb / UL = 26300Kb / LS = 26300Kb -qHighest - LS = 15% -qACK - LS = 20% -qHigh - LS = 15% -qMedium - LS = 20% -qDefault - LS = 20% -qLow - LS = 8% -qLowest - LS = 2% - qLink - Bandwidth = 972Mb / LS = 972Mb (default)
See attached for rules and queues
So far, I think i've replicated my old Tomato results fairly well…. start a few torrents, maxes out the line. Then start a 4k Youtube video, torrents slows to a crawl. VoIP works great, HTTP(s) works great.
My question: is it possible to have very little to zero drops in the queues?
-
Dropped packets are perfectly normal, especially with TCP.
-
Dropped packets are perfectly normal, especially with TCP.
I mean, it is normal NOT to see any being dropped?
Also, does any of my rules or queue looks anything weird / wrong / can be improved ??
-
-
Does my setup give any red flags? See anything wrong / wierd / can be improved?
Correct me if I misunderstood how this QoS works:
- Create how ever many/little queues you like to sort your traffic
- (WAN side) allocate bandwidth to each queues adding up to 100% of total line speed specified in the interface (which really is 95% of your actual line speed)
- (LAN side) allocate bandwidth to each queues adding up to 100% of total line speed specified in the interface (which is your NIC speed)
- create rules with known protocols and assign them to the queues.
- all unassigned traffic will default to a "default" queue.
is that summary correct?
-
Does my setup give any red flags? See anything wrong / wierd / can be improved?
Correct me if I misunderstood how this QoS works:
- Create how ever many/little queues you like to sort your traffic
- (WAN side) allocate bandwidth to each queues adding up to 100% of total line speed specified in the interface (which really is 95% of your actual line speed)
- (LAN side) allocate bandwidth to each queues adding up to 100% of total line speed specified in the interface (which is your NIC speed)
- create rules with known protocols and assign them to the queues.
- all unassigned traffic will default to a "default" queue.
is that summary correct?
That's close enough (I guess). Just try to keep your rules & queues simple. Taking the time to verify the functionality of each individual rule/queue is also important.