Can't Limit WAN - Googled, searched, tryed everything
-
so I did the shaper, gave qP2P least priority (1), HTTP(s) highest priority followed by DNS, watched the queues and everything seemed to work, I could see drops on the qP2P queue meaning that the shaper is actually working. However, I'm still getting hammered by P2P traffic, even the share bandwidth method using limiter as explained by foxale08 on a different post doesnt seem to work, the computer with bittorrent on is getting all the bandwidth! I tried using L7 but then and got same results, L7 even kills squid proxy?
-
so I did the shaper, gave qP2P least priority (1), HTTP(s) highest priority followed by DNS, watched the queues and everything seemed to work, I could see drops on the qP2P queue meaning that the shaper is actually working. However, I'm still getting hammered by P2P traffic, even the share bandwidth method using limiter as explained by foxale08 on a different post doesnt seem to work, the computer with bittorrent on is getting all the bandwidth! I tried using L7 but then and got same results, L7 even kills squid proxy?
Are you referring to uploads or downloads?
Upload traffic is the only traffic you have full control over.
Controlling downloads can be tricky, especially p2p. I have attempted a few methods but none of them worked as well as I wanted, so I have suspended anymore attempts until I have a better understanding.
FYI, layer-7 firewalling is useless if the application uses encryption.
My favorite QoS tutorial is http://www.linksysinfo.org/index.php?threads/qos-tutorial.68795/
-
That would be downloads…so I guess my shaper is working, will have to forget abt shaping P2P traffic for now.
I just wish pfsense had the "Share Bandwidth Evenly on LAN" check box like m0n0wall, I find it useful in taking care of P2P traffic. -
My favorite QoS tutorial is http://www.linksysinfo.org/index.php?threads/qos-tutorial.68795/
BTW thanks for the tutorial link, something tho'…it says that prioritizing ACK & Small Pct traffic actually also kind of prioritizes P2P traffic? does this only affect Tomato or is it general? do you think its true?
Here is a quote from the tutorial:
I used to set all small packets to get priority. That included ACKS - many people would recommend that this box is unchecked. If you do that, my thought was that you will delay traffic unnecesarily. However, there is a problem here which is not mentioned anywhere in Tomato FAQ's or Wikis. The "small packets" in the check boxes use the "Highest" class to prioritize them. So, if you check the ACK box, any ACK packets for e.g. P2P will move out of the P2P class into the "Highest" class. The data stream however will still be identified and correctly classed as P2P, and will still respond to limits. The problem may not be noticed if you have set up QOS for best latency by limiting outgoing P2P severely. But for most people, checking the box will slow down their QOS rules by giving an unfair advantage to P2P byeffectively giving P2P downloads a high priority. This is because most outgoing traffic for P2P is actually ACKS.
The moral of this is - if you run P2P on your network, and wish to limit it, uncheck the ACK box. If you want the best P2P speeds, check it.
-
My favorite QoS tutorial is http://www.linksysinfo.org/index.php?threads/qos-tutorial.68795/
BTW thanks for the tutorial link, something tho'…it says that prioritizing ACK & Small Pct traffic actually also kind of prioritizes P2P traffic? does this only affect Tomato or is it general? do you think its true?
Here is a quote from the tutorial:
I used to set all small packets to get priority. That included ACKS - many people would recommend that this box is unchecked. If you do that, my thought was that you will delay traffic unnecesarily. However, there is a problem here which is not mentioned anywhere in Tomato FAQ's or Wikis. The "small packets" in the check boxes use the "Highest" class to prioritize them. So, if you check the ACK box, any ACK packets for e.g. P2P will move out of the P2P class into the "Highest" class. The data stream however will still be identified and correctly classed as P2P, and will still respond to limits. The problem may not be noticed if you have set up QOS for best latency by limiting outgoing P2P severely. But for most people, checking the box will slow down their QOS rules by giving an unfair advantage to P2P byeffectively giving P2P downloads a high priority. This is because most outgoing traffic for P2P is actually ACKS.
The moral of this is - if you run P2P on your network, and wish to limit it, uncheck the ACK box. If you want the best P2P speeds, check it.
He is right.
If you prioritize all ACK packets, then P2P ACK packets will be included. I believe Tomato has a generic "prioritize all small/ACK packets" check-box.
Instead of prioritizing all ACK packets, you could prioritize only non-P2P ACKs. You can even rate-limit the P2P-ACKs (egress) to keep the download speed somewhat controlled, but this method lacks precise predictability.
-
My favorite QoS tutorial is http://www.linksysinfo.org/index.php?threads/qos-tutorial.68795/
BTW thanks for the tutorial link, something tho'…it says that prioritizing ACK & Small Pct traffic actually also kind of prioritizes P2P traffic? does this only affect Tomato or is it general? do you think its true?
Here is a quote from the tutorial:
I used to set all small packets to get priority. That included ACKS - many people would recommend that this box is unchecked. If you do that, my thought was that you will delay traffic unnecesarily. However, there is a problem here which is not mentioned anywhere in Tomato FAQ's or Wikis. The "small packets" in the check boxes use the "Highest" class to prioritize them. So, if you check the ACK box, any ACK packets for e.g. P2P will move out of the P2P class into the "Highest" class. The data stream however will still be identified and correctly classed as P2P, and will still respond to limits. The problem may not be noticed if you have set up QOS for best latency by limiting outgoing P2P severely. But for most people, checking the box will slow down their QOS rules by giving an unfair advantage to P2P byeffectively giving P2P downloads a high priority. This is because most outgoing traffic for P2P is actually ACKS.
The moral of this is - if you run P2P on your network, and wish to limit it, uncheck the ACK box. If you want the best P2P speeds, check it.
He is right.
If you prioritize all ACK packets, then P2P ACK packets will be included. I believe Tomato has a generic "prioritize all small/ACK packets" check-box.
Instead of prioritizing all ACK packets, you could prioritize only non-P2P ACKs. You can even rate-limit the P2P-ACKs (egress) to keep the download speed somewhat controlled, but this method lacks precise predictability.
Now this gets tricky & confusing for me…how do I even tell non-P2P ACKs?
-
My favorite QoS tutorial is http://www.linksysinfo.org/index.php?threads/qos-tutorial.68795/
BTW thanks for the tutorial link, something tho'…it says that prioritizing ACK & Small Pct traffic actually also kind of prioritizes P2P traffic? does this only affect Tomato or is it general? do you think its true?
Here is a quote from the tutorial:
I used to set all small packets to get priority. That included ACKS - many people would recommend that this box is unchecked. If you do that, my thought was that you will delay traffic unnecesarily. However, there is a problem here which is not mentioned anywhere in Tomato FAQ's or Wikis. The "small packets" in the check boxes use the "Highest" class to prioritize them. So, if you check the ACK box, any ACK packets for e.g. P2P will move out of the P2P class into the "Highest" class. The data stream however will still be identified and correctly classed as P2P, and will still respond to limits. The problem may not be noticed if you have set up QOS for best latency by limiting outgoing P2P severely. But for most people, checking the box will slow down their QOS rules by giving an unfair advantage to P2P byeffectively giving P2P downloads a high priority. This is because most outgoing traffic for P2P is actually ACKS.
The moral of this is - if you run P2P on your network, and wish to limit it, uncheck the ACK box. If you want the best P2P speeds, check it.
He is right.
If you prioritize all ACK packets, then P2P ACK packets will be included. I believe Tomato has a generic "prioritize all small/ACK packets" check-box.
Instead of prioritizing all ACK packets, you could prioritize only non-P2P ACKs. You can even rate-limit the P2P-ACKs (egress) to keep the download speed somewhat controlled, but this method lacks precise predictability.
Now this gets tricky & confusing for me…how do I even tell non-P2P ACKs?
Depends what your environment is.
Maybe all ports except 80, 443, 21, etc, will be classified as P2P.
Or maybe all your P2P clients use the default 6881 port, so you classify only that port as P2P.Lots of options.
-
Ok…I get it now.
-
Just posted new question about this same thing here.
https://forum.pfsense.org/index.php?topic=91299.0WAN side traffic shaping died after upgrade.
-
Shaping downloads as worked decently well for me, but not nearly as well as upload. Upload is a 1Gb link going into a 100Mb link, so going over 100Mb is not an issue because the shaper will buffer the data and not affect the other queues. The problem with download is it's a 100Mb link going into a 1Gb link, so I need to make sure my download never goes above 100Mb because it will buffer upstream instead of in my traffic shaper.
For the most part this just means I can't use a tight 98% of my link speed for download, it needs to be a bit looser, like 95%, which wastes more bandwidth. One issue that I have found out is because PFSense is stateful, when the WAN interface see duplicate TCP packets, it just drops the packet and sends a dup-ack. Since this Dup packet never makes it to the LAN interface, the LAN thinks there is less than 100Mb coming in, so it doesn't cause the other traffic to back-off. This is not an "issue" with PFSense, but an issue with bad-actors.