P2P rules not catching traffic (Yes, I've searched)



  • I've searched this forum quite a bit about the issue I'm having and trying all the solutions to mixed, yet ultimately negative outcomes.

    As a QoS novice, I feel like I've read enough information to understand HFSC enough to use it, (and I am) yet can't find enough (corroborating) information about creating rules for it.

    I've got most rules working, except one: BitTorrent. I run Deluge on my SMB VM with dedicated LAN IP. Deluge is forced to ranges 63519-63529 down, 63530-63540 up. Netstat on the VM confirms these are the only ports being used. pfTop confirms the same.

    My objective is to give Deluge as much bandwidth as is not being used by anything else. Deluge should "fill the gap" between total, non-P2P throughput and available bandwidth.

    However, Status>Queues clearly shows Deluge is not being tossed into my 'Downloads' queue.

    I've tried the following:

    -Every single imaginable combination (LAN/WAN, in/out/any, source/dest, TCP/TCP+UDP, etc.) of simple port matching rule.
    -Creating an interface alias (eth0:0) with its own IP and binding Deluge to it. Deluge decides it'll only route outbound traffic through this IP, not inbound.
    -Creating a rule for the IP of the VM without specified ports, which is not only unacceptable due to it being my media server, but also didn't work.

    The BEST I've gotten was watching pfSense troll me by routing Deluge's traffic through the download queue when I fired it up, then start to slowly roll said traffic into the 'Default' queue a few minutes later, then roll back into the download queue and finally 'balance' the two out. As I'm typing this, my 20Mb/1.5Mb connection is maxed out by BitTorrent, with 10Mb in the Default queue and 10Mb in the Downloads queue. Note that this was only on the downloads side – I can't get it do go into the uploads side at all.

    Like I said, I've followed guides. All the guides. The standard seems to be a floating rule like this: (I'm more than happy to provide pics of my actual rules)

    qDownloads-d

    [Action] Match
    [Interface] LAN
    [Direction] any
    [TCP/IP] IPv4
    [Protocol] TCP
    [Destination Port] 63519-63540 (or 63519-63529)
    [Ack/Queue] qACK-d/qDownloads-d

    This works for everything else I'm using (ex. HTTP) except BitTorrent.

    My current downloading rule differs from this by specifying IPv4+IPv6 and protocol TCP/UDP. I just reset all states, rebooted both pfSense and the VM, and am currently at 4.4Mb in the Download queue and 16.6 Mb in the Default queue. Outbound queue still isn't working at all.

    I've been at this for days now. I NEED help. I see a lot of posts on here without replies and it worries me because I've searched and read all I can possibly find with little success.

    At the VERY LEAST I'd like a definitive answer to whether my above example is the correct way to make a port matching queue, including whether 'Floating' is the right place to put it or not. There are so many different ways I've seen people do this, even in the few guides that exist.

    Also, I'd like to suggest adding some verbosity to the Status>Queues page, namely the ability to see which connections (x.x.x.x:xxxx > x.x.x.x:xxxx) are being handled by which queues to better help us set our rules up.



  • I am using the same client! Good one! I have got shaping working, BUT - I am using tags to put traffic into queues because I think it makes the whole packet queueing much more intuitive/simple/fail safe.

    This is how I do it:
    Whereever there is a firewall rule to allow bittorrent traffic, tag the traffic (eg as "queue_low"). Do this for both incoming and outgoing rules (use the same tag in either direction). Have a low priority queue on both LAN and WAN interfaces (eg "qLow", use the same queue name on both).

    Have two floating rules to actually queue (the now tagged) BT traffic:

    For downstream:
    [Action] Match
    [Interface] LAN
    [Direction] out (we can only queue outgoing traffic)
    [TCP/IP] IPv4
    [Protocol] TCP/UDP (BT uses both, TCP and UDP)
    [Match by Tag] queue_low
    [Ack/Queue] -/qLow

    For upstream:
    [Action] Match
    [Interface] WAN
    [Direction] out (again, we can only queue outgoing traffic)
    [TCP/IP] IPv4
    [Protocol] TCP/UDP
    [Match by Tag] queue_low
    [Ack/Queue] -/qLow



  • @senser:

    This is how I do it:
    Whereever there is a firewall rule to allow bittorrent traffic, tag the traffic (eg as "queue_low"). Do this for both incoming and outgoing rules (use the same tag in either direction). Have a low priority queue on both LAN and WAN interfaces (eg "qLow", use the same queue name on both).

    Thank you for your reply, but this didn't work either. Steps I took:

    • Scrapped my old queue system and rules and started fresh with the wizard again

    • Simply changed the BitTorrent ports on the wizard-generated rules to the custom ports I have set in Deluge

    • This didn't work, so I went ahead and made LAN and WAN pass rules that tagged the packets as you described

    • Changed the wizard rules to 'any' in all fields, but match the tagged packets

    • No dice

    However, I dug around in pfTop and found this:

    
    51  P I     em1  udp  K    22  7558     1     from any port = bootps to any port
    52  P O     em1  udp  K     0     0     0     from any port = bootpc to any port
    53  B I     !em0            0     0     0     drop inet from 192.168.1.0/24 to a
    54  B I                     0     0     0     drop inet from 192.168.1.1/32 to a
    55  B I     em0             0     0     0     drop inet6 from fe80::20c:29ff:fed
    56  P I   Q em0  udp  K     0     0     0     inet from any port = bootpc to 255
    57  P I   Q em0  udp  K     0     0     0     inet from any port = bootpc to 192
    58  P O   Q em0  udp  K     0     0     0     inet from 192.168.1.1/32 port = bo
    59  P I     lo0       K     4   365     0     inet all  flags S/SA              
    60  P O     lo0       K     0     0     0     inet all  flags S/SA              
    61  P I     lo0       K     0     0     0     inet6 all  flags S/SA             
    62  P O     lo0       K     0     0     0     inet6 all  flags S/SA             
    63  P O               K  9885 1543K   148     inet all  flags S/SA allow-opts   
    64  P O               K     0     0     0     inet6 all  flags S/SA allow-opts  
    65  P O               K 21540   12M    53     route-to ... inet from 74.133
    66  P I   Q em0  tcp  K  9403 4172K    19     from any to (em0) port = https  fl
    67  P I   Q em0  tcp  K     0     0     0     from any to (em0) port = http  fla
    68  P I   Q em0  tcp  K     0     0     0     from any to (em0) port = ssh  flag
    69  P A                     0     0     0     all                               
    70  * A   Q em1             0     0     0     inet from  to any  queue
    71  * A   Q em0             0     0     0     inet from any to   queue
    72  * A     em1  tcp      482 24716     0     inet from any to any port 4660 >< 
    73  * A     em0  tcp      482 24716     0     inet from any to any port 4660 >< 
    74  * A     em1  tcp        0     0     0     inet from any to any port = 6346  
    75  * A     em0  tcp        0     0     0     inet from any to any port = 6346  
    76  * A     em1  udp        0     0     0     inet from any to any port = 6346  
    77  * A     em0  udp        0     0     0     inet from any to any port = 6346  
    78  * A     em1  tcp        0     0     0     inet from any to any port 5899 >< 
    79  * A     em0  tcp        0     0     0     inet from any to any port 5899 >< 
    80  * A     em1  tcp        0     0     0     inet from any to any port 7999 >< 
    81  * A     em0  tcp        0     0     0     inet from any to any port 7999 >< 
    82  * A     em1  tcp        9   476     0     inet from any to any port = http  
    83  * A     em0  tcp        8   416     0     inet from any to any port = http  
    84  * A     em1  tcp      113  5876     0     inet from any to any port = https 
    85  * A     em0  tcp      113  5876     0     inet from any to any port = https 
    86  * A     em1  icmp       1   157     0     inet all  queue qOthersHigh-w     
    87  * A     em0  icmp       0     0     0     inet all  queue qOthersHigh-L     
    88  P I   Q open      K     0     0     0     all  flags S/SA                   
    89  P I   Q em1  tcp  K     0     0     0     reply-to ... inet from any to any 
    90  P I   Q em1  udp  K   172 22622     3     reply-to ... inet from any to any 
    91  P I   Q em1  tcp  K     0     0     0     inet6 from any to any port 63519:6
    92  P I   Q em1  udp  K     0     0     0     inet6 from any to any port 63519:6
    93  P I   Q em1  tcp  K     0     0     0     reply-to ... inet from any to any 
    94  P I   Q em1  udp  K     0     0     0     reply-to ... inet from any to any 
    95  P I   Q em1  tcp  K   965 44036    24     reply-to ... inet from any to any 
    96  P I   Q em1  udp  K     0     0     0     reply-to ... inet from any to any 
    97  P I   Q em1  udp  K   367 30729    18     reply-to ... inet from any to any 
    98  P I   Q em1  tcp  K     0     0     0     reply-to ... inet from any to 192.
    99  P I   Q em1  udp  K     0     0     0     reply-to ... inet from any to 192.
     *  P I   Q em1  udp  K     0     0     0     reply-to ... inet from any to 192.
     *  P I   Q em0  tcp  K    10   600     0     inet from any to any port 63519:63
     *  P I   Q em0  udp  K     2   187     0     inet from any to any port 63519:63
     *  P I   Q em0  tcp  K     0     0     0     inet6 from any to any port 63519:6
     *  P I   Q em0  udp  K     0     0     0     inet6 from any to any port 63519:6
     *  P I   Q em0       K 22439   13M    65     inet from 192.168.1.0/24 to any  f
     *  P A                     0     0     0     all                               
     *  P A                     0     0     0     all                               
    

    It looks like other rules are scrambling away with Deluge's traffic and not giving the firewall a chance to toss it in a queue.

    Now, I know… I KNOW... The firewall always matches the last rule that applies... Unless 'quick' is set. But I digress...

    I've since tried turning the LAN and WAN rules from earlier into simple pass queue rules and moving them to the top (I've created about three other rules in there. It's rather blank.) since I remember floating rules come last. Still no dice.

    I'm guessing these are auto-generated rules that Deluge's traffic is being controlled by. I have no idea what they're for or even what they do or if they're even the culprit here.

    Anyone got any ideas?



  • @electricdoor:

    Thank you for your reply, but this didn't work either. Steps I took:

    • Scrapped my old queue system and rules and started fresh with the wizard again

    • Simply changed the BitTorrent ports on the wizard-generated rules to the custom ports I have set in Deluge

    • This didn't work, so I went ahead and made LAN and WAN pass rules that tagged the packets as you described

    • Changed the wizard rules to 'any' in all fields, but match the tagged packets

    • No dice

    Hmm, that isn't exactly what I was suggesting bro'. Try again!



  • @senser:

    Hmm, that isn't exactly what I was suggesting bro'. Try again!

    I don't understand what I didn't do. I found your original post on the topic before I started to make sure I knew what was going on. In your earlier post and in this guide you're pretty vague about creating the rules that tag traffic, and I can only assume it's because it's just obvious. I did what was obvious.

    @senser:

    Whereever there is a firewall rule to allow bittorrent traffic, tag the traffic (eg as "queue_low").

    I didn't have any rules to pass BT traffic, so I created one per interface (non-floating) that specified my BT ports (63519-63540) and tagged packets as 'deluge'.

    @senser:

    Do this for both incoming and outgoing rules (use the same tag in either direction).

    I'm assuming you're referring to exactly what I did, unless you're talking about making these floating rules.

    @senser:

    Have a low priority queue on both LAN and WAN interfaces (eg "qLow", use the same queue name on both).

    The wizard created those for me. No problems here.

    @senser:

    Have two floating rules to actually queue (the now tagged) BT traffic:

    For downstream:
    [Action] Match
    [Interface] LAN
    [Direction] out (we can only queue outgoing traffic)
    [TCP/IP] IPv4
    [Protocol] TCP/UDP (BT uses both, TCP and UDP)
    [Match by Tag] queue_low
    [Ack/Queue] -/qLow

    For upstream:
    [Action] Match
    [Interface] WAN
    [Direction] out (again, we can only queue outgoing traffic)
    [TCP/IP] IPv4
    [Protocol] TCP/UDP
    [Match by Tag] queue_low
    [Ack/Queue] -/qLow

    Created those exactly as you specified.

    What may be confusing is my including a failed attempt at scrapping and rebuilding things the standard way and then giving up and trying your method in the same list. I guess I should have clarified that I gave the way things are supposed to be done one last try before attempting your tagging method.

    Regardless, I don't understand why you're saying I did it wrong.

    I appreciate your help, really. I'm just frustrated with the attitude on these forums… So many intelligently-asked questions get no reply, "You're so wrong. Use the search," (which comically just leads to more of that same answer) or just plain "That's not what you should be doing" without any hints as to why a person is wrong. It's assumed that there's a wealth of information on every single feature of pfSense. There just isn't. At all. Some topics get covered ad nauseam, like how HFSC works, but simple (and intermediate-level) information that the home hobbyist needs (like me) gets no effort whatsoever.



  • @electricdoor:

    I didn't have any rules to pass BT traffic, so I created one per interface (non-floating) that specified my BT ports (63519-63540) and tagged packets as 'deluge'.

    It's not enough to just create the queues, you also need to "feed" them (via firewall rules).

    Attached you can find my relevant firewall rules for both LAN and WAN interfaces. "Ports_BT_miqu" is an alias for my BT port range (analog to your 63519-63540). BTW: I would choose a port range that is outside of the range of your OS's ephimeral port range, so that there is no chance that the OS uses these ports for other stuff.

    Anyway, the rules shown in the screenshot all just pass and tag the traffic ("queue_low" in my case).

    Also attached are my relevant floating rules. As you can see, I put everything into the high priority queue by default. Tagged traffic will go in the respective lower queue.

    Make sure to not tick the "Quick" option for the floating rules, or they don't work.








  • @senser:

    Attached you can find my relevant firewall rules for both LAN and WAN interfaces. "Ports_BT_miqu" is an alias for my BT port range (analog to your 63519-63540). BTW: I would choose a port range that is outside of the range of your OS's ephimeral port range, so that there is no chance that the OS uses these ports for other stuff.

    So… Here's the thing: I had things set up almost just like this before. I went ahead and followed your setup verbatim, minus the pfBlocker and PPPoE0 addresses. I'll list differences in a second, but it's magically working now. Deluge's traffic is finally being routed to the qP2P queue.

    Also, thanks for mentioning the ephemeral port range. Had to look it up, but I always assumed this range was more like 1xxx-65535 because I have a Google knowledge of networking. Now that I've read a bit I understand that assumption is preposterous. Switched to ports in the 213xx range.

    The way I had this set up:

    • The LAN/WAN rules were set to TCP|UDP protocol, so I only had one rule per interface (I have since split them as you have)

    • I did not specify source (LAN) or destination (WAN) IP, only ports (My VM's IP is now specified)

    • I had two queues for P2P: qP2P-L (LAN) and qP2P-w (WAN) due to my asymmetric line (I came up with a consolidation via Linkshare and now just have the qP2P)

    • As above, I had tags 'delugew' and 'delugel' (Consolidated these as well)

    • I tried the floating rules with 'quick' both off and on

    • I had the floating rules at the top of the list (They're now on bottom like yours)

    As a matter of education, which of these differences do you think fixed it?

    And thank you for your helpfulness. Dealing with novices is never very simple.



  • @electricdoor:

    • The LAN/WAN rules were set to TCP|UDP protocol, so I only had one rule per interface (I have since split them as you have)

    • I did not specify source (LAN) or destination (WAN) IP, only ports (My VM's IP is now specified)

    • I had two queues for P2P: qP2P-L (LAN) and qP2P-w (WAN) due to my asymmetric line (I came up with a consolidation via Linkshare and now just have the qP2P)

    • As above, I had tags 'delugew' and 'delugel' (Consolidated these as well)

    • I tried the floating rules with 'quick' both off and on

    • I had the floating rules at the top of the list (They're now on bottom like yours)

    As a matter of education, which of these differences do you think fixed it?

    1. I split them only to speed up internal decision making ("ruleset-optimization").
    2. Shouldn't matter, I have multiple hosts running deluge so I need to specify the hosts.
    3. This! Outgoing traffic that was put into queue X of the WAN interface will result in related incoming traffic being put into queue X of the LAN interface (if it exists) and vice versa. Thats why I told you to give queues the same name on both interfaces.
    4. Related to 3: you could (in a way) think of having only one queue (qP2P), as they work together if they share the name.
    5. Quick needs to be off. Easiest way to get no result (if set on). :)
    6. Shouldn't matter.

    I am glad it works for you now. When I say "Try again!" I don't mean to be mean or talking down from above, more like motivative as in "you can do it, nobody said it's going to be easy, keep at it, you'll get there, just try again!".



  • @senser:

    Outgoing traffic that was put into queue X of the WAN interface will result in related incoming traffic being put into queue X of the LAN interface (if it exists) and vice versa. Thats why I told you to give queues the same name on both interfaces.

    Ah, learned something new. Wish this was in the guides. I watched a YouTube video about setting things up for optimum bandwidth usage, and the guy split all the queues by suffixing them with U or D depending on interface. I see now that this isn't the best way to do it. I'll go ahead and fix all my other queues accordingly… lol

    Thanks again for everything.


Log in to reply