New Traffic Shaper - What works correctly or makes sense?
-
is it possible to pay and get some questions answered?
is so then i can pay to get the above 2 questions answered in my earlier post, just need to get my doubts cleared related to the source and destination under each rule. -
Better yet, someone give an example of the exact steps from scratch on how to setup traffic shaping for an outgoing http + ack packet. And I'm sure we can learn from here.
-
an example would be great
-
The first screenshot is of a rule on my floating interface. You can't see it, but the Ackqueue/Queue is qACK/qOthersHigh, which were created by the wizard.
The second shot is during the download phase of speedtest.net.
The third is during the upload phase of speedtest.net.
The fourth is immediately following the speedtest. You can see traffic in the low priority queue from torrents, which I have ever seeding.
In this case I'm doing speedtest.net from a host on the LAN interface. I think you would see the same thing if I did it from a host on the WISP interface, which is a second LAN, but I haven't confirmed that.
I think if you had traffic coming in the WAN to a LAN host listening on port 80, this rule might match that as well, although I'm not sure how it would queue it, as I have queues only on the WAN as a result of the shaper wizard.
-
Here's a picture of the rule that selects all except voip traffic from a LAN host "mule" and queues it to the lowest priority.
I found selecting on source IP a little trickier, and it required additional settings, as you can see in the screenshot. I had to select LAN as the interface, direction in, or it wouldn't queue the packets.
This rule is also on the Floating interface, and I'm not sure how this is different from just making a rule on the LAN interface, although I haven't tried that.
You'll also notice that I have !link2voip as destination to avoid demoting voip packets which also come from mule. Normally I would have just put another rule ahead of this one to preemptively classify voip packets, but there is a shaper bug that places rules with a selected interface ahead of rules with no selected interface. For reasons I can't explain, the next rule has no selected interface and therefore I cannot place it ahead of this one, hence the need to exclude packets destined to my SIP provider.
Hope this helps.
-
SNA, your sketch makes sense to me. I especially like the last setting for not shaping traffic that is router inter-LAN. I'm not even sure how to do that presently, but I would like to for the sake of having a host with squid caching on the LAN, and clients on another subnet having limited download speed, except when pulling from said cache.
-
The first screenshot is of a rule on my floating interface. You can't see it, but the Ackqueue/Queue is qACK/qOthersHigh, which were created by the wizard.
The second shot is during the download phase of speedtest.net.
The third is during the upload phase of speedtest.net.
The fourth is immediately following the speedtest. You can see traffic in the low priority queue from torrents, which I have ever seeding.
In this case I'm doing speedtest.net from a host on the LAN interface. I think you would see the same thing if I did it from a host on the WISP interface, which is a second LAN, but I haven't confirmed that.
I think if you had traffic coming in the WAN to a LAN host listening on port 80, this rule might match that as well, although I'm not sure how it would queue it, as I have queues only on the WAN as a result of the shaper wizard.
having queues for WAN means ur shaping ur uplaods only, u need to have queues for LAN also if u need to shape on downloads even
-
Here's a picture of the rule that selects all except voip traffic from a LAN host "mule" and queues it to the lowest priority.
I found selecting on source IP a little trickier, and it required additional settings, as you can see in the screenshot. I had to select LAN as the interface, direction in, or it wouldn't queue the packets.
This rule is also on the Floating interface, and I'm not sure how this is different from just making a rule on the LAN interface, although I haven't tried that.
You'll also notice that I have !link2voip as destination to avoid demoting voip packets which also come from mule. Normally I would have just put another rule ahead of this one to preemptively classify voip packets, but there is a shaper bug that places rules with a selected interface ahead of rules with no selected interface. For reasons I can't explain, the next rule has no selected interface and therefore I cannot place it ahead of this one, hence the need to exclude packets destined to my SIP provider.
Hope this helps.
the rule u mentioned, basically ur trying to put the mule client traffic to the lowest priority queue for uplaods, meaning from lan client to WAN, if this rule works then i also have one rule under floating tab, no idea how but it does the exact same stuff
apply the action - unticked
interfaces - don't select any
direction - out
source - *
port - *
destination - mule
port - *
queue - to ur lowest priority queue -
if u want to put client traffic in proper queues and ackqueues based on destination port or protocol on WAN side, thats pretty easy, just create rules under floating tab.
src - *
dest port - 80above for all uploads or all traffic from client to web server on WAN and just flip the src and dest port for all downloads from web server to LAN client, this is straight forward.
the part where i get totally lost is when u need to have rules where WAN side port or ip would be * and LAN side a LAN client. this is where things gets messy and weird rules seem to match, for eg: if u were to put all LAN client upload to a p2p queue then u would need rules under floating tab as in such a scenario, states r created so rule needs to be in direction out but y src ip and port as * and dest ip as LAN client?
-
As someone that is somewhat knowledgeable, but by no means a networking expert, I can agree with SNA about the wizard.
I know a bit about networking and how to set up queues and such, enough to do really well in 1.2.3. But the wizard in 2.0 is plain confusing, and over-complex. While many people that use pfSense are extremely well-versed in networking and such, there are also many that are not. When I first downloaded pfSense, I was really new, and read an article on how to put an old machine of mine to use ("Armor Your Palace" article). Since then I've come a long way and learned quite a bit.
The difference between the wizards is extreme enough that when seeing the one for 2.0, I just looked at it for a few minutes. Also there should not be more than one wizard. It should be one wizard that is able to deal with the different combinations. I would think (I'm not a coder so I'm guessing) that one wizard with SNA's idea would reduce coding (1 wizard instead of many), and IMHO would be much more intuitive and functional.