ANSWERED Very poor torrent performance

[Indigo35 4]

Hello,

 

I'm using Transmission on OS X and have noticed the past few days that my torrent performance is very poor.

 

I have a port forwarded and all of my settings are correct. 

 

I am having drop-outs on my torrent service. It will download just fine for many minutes and then all the torrent transfers stop moving.

I've tried switching servers, but this did not help.

 

Does anyone have any ideas?

 

Thank you!

 

 

[dd79 15]

It could be serval reasons:

 

- You could be using a WLAN with a poor signal

- Other people in your hosehould could be using alot of bandwidth.

- The server(s) could be overloaded.

[mgc6288 0]

I've been having the same issue.  I'd log on and after a few minutes my AirVPN connection disconnects.  Thankfully I have my firewall set to block uTorrent if it does, but it appears that I need to babysit this connection.  

 

I'm wired, not wireless, the only one on my connection, and I'm selecting those with less than 30% from different regions.  

 

Do you think ISPs have caught onto the game of VPNs and dropping them?  They may not "know" what is going on but just killing them all just in case...  It work fine a few months ago and last month and now this month the same issue.  Rather frustrating...

[j1smith 0]

I also have an issue about lost connection while downloading with Transmission if I use UDP 443. If I use TCP 443, it is fine. I suspect my ISP disconnects me it it sees massive traffic on UDP 443.

[Staff 9751]

I also have an issue about lost connection while downloading with Transmission if I use UDP 443. If I use TCP 443, it is fine. I suspect my ISP disconnects me it it sees massive traffic on UDP 443.

 

Hello!

 

It can't be ruled out. Anyway we have seen this very same behavior on Windows systems running Kaspersky, ZoneAlarm... can you please try to disable any packet filtering tool and check whether the problem remains or not (over UDP), if you run Windows? Also, it's worth to check for (and disable for testing purposes) firewall/packet filtering-inspection tools on the router as well.

 

Kind regards

[j1smith 0]

 

I also have an issue about lost connection while downloading with Transmission if I use UDP 443. If I use TCP 443, it is fine. I suspect my ISP disconnects me it it sees massive traffic on UDP 443.

 

Hello!

 

It can't be ruled out. Anyway we have seen this very same behavior on Windows systems running Kaspersky, ZoneAlarm... can you please try to disable any packet filtering tool and check whether the problem remains or not (over UDP), if you run Windows? Also, it's worth to check for (and disable for testing purposes) firewall/packet filtering-inspection tools on the router as well.

 

Kind regards

It is very interesting what you say here. I run Linux, but I do use a firewall to drop all traffic that tries to go around the VPN connection. I'll try to turn it off to see what happens.

[j1smith 0]

 

I also have an issue about lost connection while downloading with Transmission if I use UDP 443. If I use TCP 443, it is fine. I suspect my ISP disconnects me it it sees massive traffic on UDP 443.

 

Hello!

 

It can't be ruled out. Anyway we have seen this very same behavior on Windows systems running Kaspersky, ZoneAlarm... can you please try to disable any packet filtering tool and check whether the problem remains or not (over UDP), if you run Windows? Also, it's worth to check for (and disable for testing purposes) firewall/packet filtering-inspection tools on the router as well.

 

Kind regards

 

So it turns out that you are correct. If I turn off the firewall, I don't get disconnected. Now how is that possible? Something must be trying to go out outside of the VPN tunnel, and when it can't, my connection dies. Is that a correct assessment? (I said "disconnects" previously, but it still seems to be connected from the operating system, just all traffic stops.)

[Staff 9751]

Hello!

 

Actually it looks like some firewall "security event" triggered by "too much" UDP traffic. We think it has nothing to do with leaks.

 

Kind regards

[j1smith 0]

Actually it looks like some firewall "security event" triggered by "too much" UDP traffic. We think it has nothing to do with leaks.

 

That sounds very unlikely. I use ufw on Linux with 2 extremely simple rules. Allow out anything on tun0 and allow in from anywhere to port xxxxx on tun0 (where port xxxxx is the one I open and forward to use in Transmission). Otherwise all packets are dropped. That's all. I can post my exact rules if you'd like.

 

Now it is also interesting (and this seems to happen with TCP as well) that sometimes I establish the VPN connection, and things work fine, but once I turn on my firewall, the connection dies. Then I turn off the firewall (connection still dead), disconnect VPN, reconnect VPN, turn on firewall, and then it works. Once it works with a TCP connection, it seems to be stable. If I don't turn on the firewall, it always seems to be stable, regardless of TCP or UDP.

 

Do you have any ideas what might cause this? (Sorry for hijacking the thread.)

[Staff 9751]

 

Actually it looks like some firewall "security event" triggered by "too much" UDP traffic. We think it has nothing to do with leaks.

 

That sounds very unlikely. I use ufw on Linux with 2 extremely simple rules. Allow out anything on tun0 and allow in from anywhere to port xxxxx on tun0 (where port xxxxx is the one I open and forward to use in Transmission). Otherwise all packets are dropped. That's all. I can post my exact rules if you'd like.

 

Hello!

 

The problem is here (or at least part of the problem). You should allow anything to tun0 on all ports, because you can't foresee which source port will be used by any application (remember that tun0 is the virtual interface used by OpenVPN, where packets are still/already unencrypted). So in several circumstances you actually block everything except incoming connections to Transmission from the Internet. But tun0 must also communicate with eth+ or wlan+. According to the exact rule definition, it might even block communications between eth+ (or wlan+) and tun0, causing a total tunnel disruption, and that would also explain the apparently erratic behavior you observe.

 

There is one more thing to check, i.e. if there are packet inspection tools on the router which could trigger a traffic block in case of elevated UDP traffic, but this is most probably not the case, because the ultimate proof is that when you disable ufw everything works fine.

 

Kind regards

[j1smith 0]

I've just tried to allow everything on tun0 (regardless of port), and my connection still died. Here are my rules:

 

Anywhere on tun0           ALLOW       Anywhere

Anywhere (v6) on tun0      ALLOW       Anywhere (v6)

 

Anywhere                   ALLOW OUT   Anywhere on tun0

Anywhere (v6)              ALLOW OUT   Anywhere (v6) on tun0

 

Default is "Deny" for both incoming and outgoing. Right now I'm testing a torrent without the firewall and it seems to be working for now.

[j1smith 0]

OK, wait, now it's been working for a while. Maybe the previous was a random disconnect? OK, I keep experimenting with these settings.

[j1smith 0]

Things are a bit chaotic and they seem to get worse. The firewall may have impeded on my connection, or it may have been a red herring. Today I can only connect on UDP (ant TCP attempt is getting timed out), but firewall or no firewall, the connection dies as soon as I start Transmission... It seems to be working fine until that point; then Transmission starts, it connects to a bunch of peers, but before it could start up or downloading, the connection is dead.

[j1smith 0]

OK, I figured it out. It's my router's firewall. It's heuristics sometimes thinks I'm being attacked (DoS) and it shuts down the connection. Thank you so much for the staff member for pointing out this possibility. I'm not sure I would have ever figured it out without that.

 

That said, my original ufw settings were probably wrong, too. So it was likely two independent problems, both causing intermittent issues. That made it especially hard to figure it out.