Traffic shapper for P2P not working
-
You are limiting it only to TCP. My P2P clients use a lot of UDP.
And why are you checking the source port? 500:65535 would essentially match ALL TCP traffic because client ports are a subset of 500:65535.
-
You are limiting it only to TCP. My P2P clients use a lot of UDP.
And why are you checking the source port? 500:65535 would essentially match ALL TCP traffic because client ports are a subset of 500:65535.
I find after Changing to tcp/udp even normal download are also being shaped
So how would you suggest changing to? -
If you want connections to NonESSPortNumbers to match that rule, change it from Source port to Destination port.
Note that bittorrent might use those ports too, thus bypassing your shaping.
-
The way I approach shaping is by default I put all traffic into the P2P queue, then white-list traffic that I know shouldn't be.
-
I've found the best way to stop bittorrent from clobbering my connection is to just set the limiters built into Transmission.
-
I've found the best way to stop bittorrent from clobbering my connection is to just set the limiters built into Transmission.
I wish I could admit defeat as easily as you…
;)
-
I've found the best way to stop bittorrent from clobbering my connection is to just set the limiters built into Transmission.
If that works for you, of course that's just fine. But there is a way to get it working in pfSense. This link was helpful to me: https://trac.transmissionbt.com/ticket/776#comment:52
Here's what I did:
1. Add an additional IP address to the network interface of the machine that is running Transmission. Here's the relevant lines from /etc/network/interfaces:
iface eth0 inet dhcp
up ip addr add 172.17.61.19/24 broadcast 172.17.61.255 dev $IFACE
down ip addr del 172.17.61.19/24 dev $IFACE2. Make Transmission use this IP address.
In transmission's settings.json modify these two settings:
"bind-address-ipv4": "172.17.61.19",
"rpc-bind-address": "172.17.61.19",3. Modify the existing port-forwarding firewall rules to point to the new IP address. There should be one to modify in each of these locations:
Firewall -> NAT -> Port Forward
Firewall -> Rules -> WAN4. Add two Floating firewall rules to match all traffic (TCP and UDP) to or from the new IP address and assign it to the P2P queue. One rule is for that IP as the source; the other is for that IP as the destination.
Make sure to restart transmission with the new settings, and clear all states in pfSense.
-
What are you trying to do with the traffic shaping? Reduce bandwidth, stabilize ping, something else?
-
I've found the best way to stop bittorrent from clobbering my connection is to just set the limiters built into Transmission.
If that works for you, of course that's just fine. But there is a way to get it working in pfSense. This link was helpful to me: https://trac.transmissionbt.com/ticket/776#comment:52
Here's what I did:
1. Add an additional IP address to the network interface of the machine that is running Transmission. Here's the relevant lines from /etc/network/interfaces:
iface eth0 inet dhcp
up ip addr add 172.17.61.19/24 broadcast 172.17.61.255 dev $IFACE
down ip addr del 172.17.61.19/24 dev $IFACE2. Make Transmission use this IP address.
In transmission's settings.json modify these two settings:
"bind-address-ipv4": "172.17.61.19",
"rpc-bind-address": "172.17.61.19",3. Modify the existing port-forwarding firewall rules to point to the new IP address. There should be one to modify in each of these locations:
Firewall -> NAT -> Port Forward
Firewall -> Rules -> WAN4. Add two Floating firewall rules to match all traffic (TCP and UDP) to or from the new IP address and assign it to the P2P queue. One rule is for that IP as the source; the other is for that IP as the destination.
Make sure to restart transmission with the new settings, and clear all states in pfSense.
Interesting. So that setup is capable of shaping all traffic originating from the torrent client, like even DNS lookups? Any other advantages?
I kinda do not see when this would be the best approach. Either trust the client to throttle, or assume the traffic is greedy.
-
i am planning to test tomorrow by creating Port Alias cointaing IANA unassigned port since my packet capture shows most ports used by torrent is unassigned by IANA, will post update tomorrow
-
Yeah, that's the same thing as a dedicated PC (or VM) that's just used for torrenting. If you can limit by IP address instead of trying to identify and limit what ports bittorrent is using it's a LOT easier.
You can even do the port forward as long as you remember to limit on that WAN rule too.
-
i am planning to test tomorrow by creating Port Alias cointaing IANA unassigned port since my packet capture shows most ports used by torrent is unassigned by IANA, will post update tomorrow
Clever. :)
Be sure your traffic is being assigned to the expected rules before working on the limiter.
-
Interesting. So that setup is capable of shaping all traffic originating from the torrent client, like even DNS lookups? Any other advantages?
I kinda do not see when this would be the best approach. Either trust the client to throttle, or assume the traffic is greedy.
Yes, I believe that it does match all traffic originating from the torrent client, because those two rules that I showed in the file 3.png attached to my previous post match all TCP and UDP traffic originating from or destined for the new IP address. Previously I had assigned the WAN port forward rule to the P2P queue, and that matched some traffic, but not all of it. I never got something that worked well with the port-based approach. Evidently connections are initiated by the transmission client from various source ports, and these are not matched by the WAN port forward rule. So the advantage to me of doing it this way is that it's simple and easy to match all P2P traffic.
My goal is to give the transmission client all the upload bandwidth it can use, with the provision that it yield very nearly all its upload bandwidth to anything and everything else on the network. To accomplish this I have just two queues under the WAN in my traffic shaping setup–qMain with 1950 Kbit/s and qP2P with 20 Kbit/s. All my other queues, including qDefault, are under qMain. Since queues can only borrow bandwidth from their siblings, this means that anything under qMain that wants to max out the upload bandwidth can push qP2P down to a minimum of 20Kbit/s. It's not that I don't trust the client to throttle. If I set the client to limit itself to a certain upload speed, it does. What I prefer, though, is for the pfSense traffic shaper to dynamically accomplish the throttling.
-
Back to the original question. Are you trying to stabilize your ping or reduce bandwidth? FairQ should be able to stabilize your ping and evenly distribute bandwidth, but won't lte you control the bandwidth. It should also "just work". Too bad we don't have fq_codel.
-
control bandwidth getting used by p2p applications
-
control bandwidth getting used by p2p applications
Just making sure because people tend to conflate bandwidth, latency, and fairness and assume everything is to be solved with bandwidth.
-
