P2P traffic ends up in P2P and WAN upstream queues
-
Guys have you read
http://wiki.pfsense.com/wikka.php?wakka=TrafficShapingGuide&show_comments=1#commentsi am only guessing but could your other uplaod data be ACK packets from the p2p data packets coming in and not p2p traffic going out?
That would explain why it takes a little while for the amount of data in the WAN upload to build up as well.
-
The port you specified for µTorrent to use, 19000, is for incoming connections only. From the µTorrent FAQ:
@µTorrent:
My firewall is reporting connections being made by µTorrent on a port besides the one I selected. What gives?
Only incoming connections use the port you selected in µTorrent. Outgoing connections use a random local port; this is simply the way TCP/IP functions. It's not a bug.
If you have a firewall, you must allow all outgoing traffic on TCP and UDP.
I use µTorrent as well and it is set to use port 50167. I also have traffic shaping rules to put any TCP & UDP traffic on ports 2000-63000 in my bulk queue (P2P), after my VoIP rules. When I check states, I see active outbound connections on ports <2000 (e.g. 1192, 1567). I can take those IP's and compare them to the Peer list in µTorrent and they match up. Since the port is outside my bulk traffic rule, they get placed in the default (wandef) queue.
Guys have you read
http://wiki.pfsense.com/wikka.php?wakka=TrafficShapingGuide&show_comments=1#commentsi am only guessing but could your other uplaod data be ACK packets from the p2p data packets coming in and not p2p traffic going out?
The wizard automatically creates a WAN & LAN ACK queue so that traffic doesn't go through the default queues.
-
The port you specified for µTorrent to use, 19000, is for incoming connections only. From the µTorrent FAQ:
@µTorrent:
My firewall is reporting connections being made by µTorrent on a port besides the one I selected. What gives?
Only incoming connections use the port you selected in µTorrent. Outgoing connections use a random local port; this is simply the way TCP/IP functions. It's not a bug.
If you have a firewall, you must allow all outgoing traffic on TCP and UDP.
I use µTorrent as well and it is set to use port 50167. I also have traffic shaping rules to put any TCP & UDP traffic on ports 2000-63000 in my bulk queue (P2P), after my VoIP rules. When I check states, I see active outbound connections on ports <2000 (e.g. 1192, 1567). I can take those IP's and compare them to the Peer list in µTorrent and they match up. Since the port is outside my bulk traffic rule, they get placed in the default (wandef) queue.
Guys have you read
http://wiki.pfsense.com/wikka.php?wakka=TrafficShapingGuide&show_comments=1#commentsi am only guessing but could your other uplaod data be ACK packets from the p2p data packets coming in and not p2p traffic going out?
The wizard automatically creates a WAN & LAN ACK queue so that traffic doesn't go through the default queues.
As I stated I have my upstream port forced as welll…
It's under advanced, "net.outgoing_port". There is no need to use a random range of ports for upstream.
I have verified my upstream src port via "netstat -an" and ethereal on my Winblows box. I also have same traffic shaping setup in other embeded firewalls and it works fine; no issues like this. There is only 2 ports being used for P2P;TCP 19000 inbound as DST port, and 19000 outbound as SRC port. I did this intentionally to make traffic shaping easy.
I also have traffic shaping rules to put any TCP & UDP traffic on ports 2000-63000 in my bulk queue (P2P)
Dude, that could easily screw up other traffic I have. That's waaaay to broad of a rule. And there is basically NO UDP traffic on bittorrent unless you use DHT. Otherwise DNS is all you will see. This is why I forced upstream SRC port; to avoid a big nasty rule like the one you showed that WILL hose other services.
My goal is ALL traffic but P2P is golden, P2P traffic should be considered pond scum. I have all sorts of other protocols running that need priority over P2P at any time.
thanks for the input; I'm going to screw with this again on Sunday.
-
I also have traffic shaping rules to put any TCP & UDP traffic on ports 2000-63000 in my bulk queue (P2P)
Dude, that could easily screw up other traffic I have. That's waaaay to broad of a rule. And there is basically NO UDP traffic on bittorrent unless you use DHT. Otherwise DNS is all you will see. This is why I forced upstream SRC port; to avoid a big nasty rule like the one you showed that WILL hose other services.
The UDP traffic rule isn't just for torrents. It's for any UDP traffic, except VoIP, that may occur. DNS is on port 53 so it is put into the WAN/LAN default queues.
I wasn't saying that you needed to set a rule like that. The highest port used on my network is PPTP traffic (port 1723). So far, it's been working fine but I'll have to adjust it if/when other people on the network start downloading via torrent.
Thanks for the info on forcing an outgoing port. I'll test that on my system, by setting the value and changing the bulk traffic rule, and see if it works the same as you are experiencing.
-
I also have traffic shaping rules to put any TCP & UDP traffic on ports 2000-63000 in my bulk queue (P2P)
Dude, that could easily screw up other traffic I have. That's waaaay to broad of a rule. And there is basically NO UDP traffic on bittorrent unless you use DHT. Otherwise DNS is all you will see. This is why I forced upstream SRC port; to avoid a big nasty rule like the one you showed that WILL hose other services.
The UDP traffic rule isn't just for torrents. It's for any UDP traffic, except VoIP, that may occur. DNS is on port 53 so it is put into the WAN/LAN default queues.
I wasn't saying that you needed to set a rule like that. The highest port used on my network is PPTP traffic (port 1723). So far, it's been working fine but I'll have to adjust it if/when other people on the network start downloading via torrent.
Thanks for the info on forcing an outgoing port. I'll test that on my system, by setting the value and changing the bulk traffic rule, and see if it works the same as you are experiencing.
Awesome! thanks!
-
So far, after changing my settings this morning, everything is running through the bulk queue. I'll keep checking it for the next couple of days.
What release are you running (1.0.1, snapshot, etc.)?
-
So far, after changing my settings this morning, everything is running through the bulk queue. I'll keep checking it for the next couple of days.
What release are you running (1.0.1, snapshot, etc.)?
1.0.1, thanks a ton for your time. I'll try it tomorrow when I have time myself. You have the same config? I.E one port used inbound and outbound?
-
1.0.1, thanks a ton for your time. I'll try it tomorrow when I have time myself. You have the same config? I.E one port used inbound and outbound?
Yep, one LAN and one WAN. I am not running the base 1.0.1 release, though. I am running the latest snapshot because I had a problem with traffic shaping on the base 1.0.1 (VoIP was cutting out).
So far, it's still working like it's supposed to do (all P2P traffic in bulk queue). Maybe you could try running the latest snapshot and see if that works for you.
-
1.0.1, thanks a ton for your time. I'll try it tomorrow when I have time myself. You have the same config? I.E one port used inbound and outbound?
Yep, one LAN and one WAN. I am not running the base 1.0.1 release, though. I am running the latest snapshot because I had a problem with traffic shaping on the base 1.0.1 (VoIP was cutting out).
So far, it's still working like it's supposed to do (all P2P traffic in bulk queue). Maybe you could try running the latest snapshot and see if that works for you.
Awesome, again thanks for your time!!! I'll try it tomorrow and post my results.
-
It's working on the snapshot release :) Just finishing up tweaking the rules now!
thanks again!
-
It's working on the snapshot release :) Just finishing up tweaking the rules now!
thanks again!
Glad it worked for you.