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-dThis 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] -/qLowFor 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 -
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 allIt 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?
-
-
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!
-
-
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.
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'.
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.
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.
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] -/qLowFor 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] -/qLowCreated 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.
-
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.
-
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.
-
-
-
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!".
-
-
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.