Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Traffic shapper for P2P not working

    Scheduled Pinned Locked Moved Traffic Shaping
    24 Posts 5 Posters 3.9k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • DerelictD
      Derelict LAYER 8 Netgate
      last edited by

      I've found the best way to stop bittorrent from clobbering my connection is to just set the limiters built into Transmission.

      Chattanooga, Tennessee, USA
      A comprehensive network diagram is worth 10,000 words and 15 conference calls.
      DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
      Do Not Chat For Help! NO_WAN_EGRESS(TM)

      1 Reply Last reply Reply Quote 0
      • N
        Nullity
        last edited by

        @Derelict:

        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…

        ;)

        Please correct any obvious misinformation in my posts.
        -Not a professional; an arrogant ignoramous.

        1 Reply Last reply Reply Quote 0
        • J
          jdietrch
          last edited by

          @Derelict:

          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 $IFACE

          2. 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 -> WAN

          4. 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.

          1.png
          1.png_thumb
          2.png
          2.png_thumb
          3.png
          3.png_thumb

          1 Reply Last reply Reply Quote 0
          • H
            Harvy66
            last edited by

            What are you trying to do with the traffic shaping? Reduce bandwidth, stabilize ping, something else?

            1 Reply Last reply Reply Quote 0
            • N
              Nullity
              last edited by

              @jdietrch:

              @Derelict:

              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 $IFACE

              2. 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 -> WAN

              4. 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.

              Please correct any obvious misinformation in my posts.
              -Not a professional; an arrogant ignoramous.

              1 Reply Last reply Reply Quote 0
              • A
                Abhishek
                last edited by

                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

                2.3-RC (amd64)
                built on Mon Apr 04 17:09:32 CDT 2016
                FreeBSD 10.3-RELEASE
                Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz

                darkstat 3.1.2_1
                Lightsquid 3.0.3_1
                mailreport 3.0_1
                pfBlockerNG 2.0.9_1  
                RRD_Summary 1.3.1_2
                snort 3.2.9.1_9  
                squid 0.4.16_1  
                squidGuard 1.14_1
                syslog-ng 1.1.2_2

                1 Reply Last reply Reply Quote 0
                • DerelictD
                  Derelict LAYER 8 Netgate
                  last edited by

                  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.

                  Chattanooga, Tennessee, USA
                  A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                  DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                  Do Not Chat For Help! NO_WAN_EGRESS(TM)

                  1 Reply Last reply Reply Quote 0
                  • N
                    Nullity
                    last edited by

                    @Abhishek:

                    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.

                    Please correct any obvious misinformation in my posts.
                    -Not a professional; an arrogant ignoramous.

                    1 Reply Last reply Reply Quote 0
                    • J
                      jdietrch
                      last edited by

                      @Nullity:

                      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.

                      1 Reply Last reply Reply Quote 0
                      • H
                        Harvy66
                        last edited by

                        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.

                        1 Reply Last reply Reply Quote 0
                        • A
                          Abhishek
                          last edited by

                          control bandwidth getting used by p2p applications

                          2.3-RC (amd64)
                          built on Mon Apr 04 17:09:32 CDT 2016
                          FreeBSD 10.3-RELEASE
                          Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz

                          darkstat 3.1.2_1
                          Lightsquid 3.0.3_1
                          mailreport 3.0_1
                          pfBlockerNG 2.0.9_1  
                          RRD_Summary 1.3.1_2
                          snort 3.2.9.1_9  
                          squid 0.4.16_1  
                          squidGuard 1.14_1
                          syslog-ng 1.1.2_2

                          1 Reply Last reply Reply Quote 0
                          • H
                            Harvy66
                            last edited by

                            @Abhishek:

                            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.

                            1 Reply Last reply Reply Quote 0
                            • A
                              Abhishek
                              last edited by

                              @Harvy66:

                              @Abhishek:

                              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.

                              not facing any latency issue

                              2.3-RC (amd64)
                              built on Mon Apr 04 17:09:32 CDT 2016
                              FreeBSD 10.3-RELEASE
                              Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz

                              darkstat 3.1.2_1
                              Lightsquid 3.0.3_1
                              mailreport 3.0_1
                              pfBlockerNG 2.0.9_1  
                              RRD_Summary 1.3.1_2
                              snort 3.2.9.1_9  
                              squid 0.4.16_1  
                              squidGuard 1.14_1
                              syslog-ng 1.1.2_2

                              1 Reply Last reply Reply Quote 0
                              • First post
                                Last post
                              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.