qBittorrent official forums

My first post here. I have been having a problem for days where I can download files to my heart's content from my favourite site, but I am not able to seed back. I am on the latest version, qBittorrent v4.6.5 (64-bit), using Windows 11.

Yesterday I installed this same version on another laptop in the house, this one on Windows 10. I was able to download and seed, but after an hour or so the same problem showed up on the second computer, the No Direct Connection message. Again, I can download but not seed.

Both computers are using Avast Secureline VPN.

Any ideas?

To be able to seed, you must not be a passive peer. Unfortunately VPNs will make you passive.
What can you do?
- Use a provider that supports port fowarding. PIA supports it, I think Windscribe supports it, etc.
- Use a seedbox so you "buffer". Basically you rent a box (sometimes just for 1 month) and just upload a bigger amount from there so your ratio is "good" for years to come. Yes, this is kind of playing the system but what can you do. I understand the struggle.

Peter wrote:
> To be able to seed, you must not be a passive peer. Unfortunately VPNs will
> make you passive.

Thanks for the reply. Can I use port forwarding to get around the vpn?

geomonster wrote:
> Peter wrote:
> > To be able to seed, you must not be a passive peer. Unfortunately VPNs will
> > make you passive.
>
> Thanks for the reply. Can I use port forwarding to get around the vpn?

The VPN has to support port forwarding. The ones I mentioned do support it. You have to configure this port forward on the VPN providers webpage or in the client (it varies by provider) and then set the same port in qBittorrent. And you are active. Just have to make sure you pick a provider that has support.

It's never been the case that you *need* to accept incoming connections to seed, in the past it was just that you could only connect to peers that do. These days hole-punching allows peers behind NAT to connect without either having port-forwarding. I think if you see "No Direct Connection" it means that you have neither forwarding nor hole-punching - I've not seen this warning and I don't have port forwarding. Try going to checkmynat.com, via Avast, and check your type. IIRC "Symmetric NAT" is the one that breaks hole-punching.

It can be problematic to seed if you don't have very fast uploads, because downloading peers seek out the fastest sources. Private torrents tend to be very heavily over-seeded, and even a lot of public torrents are. You may have to put-in a lot of time or go down the seed-box route.

Thanks for the replies to both of you. At this point, torrenting seems more trouble than it's worth. I might as well just subscribe to the channels. It's a lot easier now than when I originally started down the torrent trail.

Do you actually care about seeding? Not being able to seed is only a problem if you use private torrents and need to maintain share ratio; otherwise, if a torrent has long-term over-seeding, there's little point in adding to it. If you are struggling with private torrents you could just switch to public torrents.

bob2306 wrote:
> Do you actually care about seeding? Not being able to seed is only a
> problem if you use private torrents and need to maintain share ratio;
> otherwise, if a torrent has long-term over-seeding, there's little point in
> adding to it. If you are struggling with private torrents you could just
> switch to public torrents.

The only site I frequent requires you to maintain a share ratio. I now have subscriptions for F1, MotoGP and World SBK so I can watch them anytime I want. Perhaps the torrent issue was a blessing in disguise for me. But I do appreciate your advice.

geomonster wrote:
> My first post here. I have been having a problem for days where I can
> download files to my heart's content from my favourite site, but I am not
> able to seed back. I am on the latest version, qBittorrent v4.6.5 (64-bit),
> using Windows 11.
>
> Yesterday I installed this same version on another laptop in the house,
> this one on Windows 10. I was able to download and seed, but after an hour
> or so the same problem showed up on the second computer, the No Direct
> Connection message. Again, I can download but not seed.
>
> Both computers are using Avast Secureline VPN.
>
> Any ideas?


It's possible that you're able to seed just fine. The flame icon means that you haven't had any direct (inbound) connections yet. It isn't always indicative of a network configuration issue. I also see it at times on my end but eventually it'll disappear once I get a peer that's able to make a direct connection to my machine. My VPN service provider doesn't explicitly support port forwarding so sometimes this can take a while. It requires a mutual peer to function as a relay in order to coordinate connection setup with the target peer. See: https://www.bittorrent.org/beps/bep_0055.html

That aside, you've said that sometimes you are able to accept direct connections behind your VPN. This means that your NAT type likely isn't the culprit then. Unless you're dealing with a hybrid NAT (a combination of Symmetric/Port Restricted Cone), which could explain what you're experiencing, but they're rarely deployed. Most VPN providers will use either Restricted Cone or a Port Restricted Cone setup. Occasionally they'll use Symmetric, like ProtonVPN does by default, but it infamously breaks hole punching. Fortunately the latter provider allows you to change your NAT type to 'moderate' (Port Restricted Cone) as a workaround.

As Bob already pointed out you don't necessarily need to explicitly port forward to seed. Hole punching already does the port mapping for you, only implicitly, and behind-the-scenes. Just make sure that you've enabled both TCP & μTP (UDP) protocols in your qBittorrent settings. If μTP is disabled then it won't work. Hole punching is a general networking concept designed for NAT firewall traversal. It works everywhere regardless of the platform or device. So, any differences between your two laptops is irrelevant. Another thing to keep in mind is that a VPN provider's NAT firewall configuration may differ across servers. It isn't guaranteed that they all share the same network configuration. You might find that you can accept direct connections when connected to certain servers, or when using certain VPN protocols, but not on others.

I was facing the same, But now everything is good.

LilTroy wrote:
It requires a mutual peer to function as a relay in order to coordinate
> connection setup with the target peer.

One thing I've been wondering about this is whether that mutual peer is always an ordinary peer in the swarm, or whether it can be a DHT node. I suspect it can be as hole punching seems to be working far too well on small swarms for it to be limited to swarm peers.

bob2306 wrote:
> LilTroy wrote:
> It requires a mutual peer to function as a relay in order to coordinate
> > connection setup with the target peer.
>
> One thing I've been wondering about this is whether that mutual peer is always an
> ordinary peer in the swarm, or whether it can be a DHT node. I suspect it can be as
> hole punching seems to be working far too well on small swarms for it to be limited
> to swarm peers.

Yes, it will use any mutual (“rendezvous”) peer available provided that it isn't behind NAT. See Arvid's post on it here → https://narkive.com/HqyhMO7B.8 Once it facilitates connection setup between the initiating & target endpoints it isn't needed anymore. It effectively acts like a lightweight STUN server. LibTorrent's hole punch implementation works very well but its NAT traversal could be made even more robust. At present it relies on UDP which can be problematic because some highly restrictive corporate networks block it. Additional support for TCP-based hole punching would fix this. Another improvement would be to add TURN, or an equivalent, as a fallback method for when P2P connectivity between peers isn't possible. It'll transparently proxy the entire connection between both endpoints. The rationale behind it being that some connectivity, even if it's indirect, is better than none at all.

LilTroy wrote:
> bob2306 wrote:

> > One thing I've been wondering about this is whether that mutual peer is always
> an ordinary peer in the swarm, or whether it can be a DHT node.
>
> Yes, it will use any mutual (“rendezvous”) peer available provided that it isn't
> behind NAT. See Arvid's post on it here → https://narkive.com/HqyhMO7B.8

That link only refers to peers in the swarm and DHT peers are typically not in the swarm.
In fact he explicitly writes:

"Perhaps the most important consequence of this is that you can't have a
swarm with all NATed peers."

The advantage of using DHT peers is that that statement wouldn't be true.

bob2306 wrote:
> LilTroy wrote:
> > bob2306 wrote:
>
> > > One thing I've been wondering about this is whether that mutual peer is
> always
> > an ordinary peer in the swarm, or whether it can be a DHT node.
> >
> > Yes, it will use any mutual (“rendezvous”) peer available provided that it isn't
> > behind NAT. See Arvid's post on it here → https://narkive.com/HqyhMO7B.8
>
> That link only refers to peers in the swarm and DHT peers are typically not in the
> swarm.
> In fact he explicitly writes:
>
> "Perhaps the most important consequence of this is that you can't
> have a
> swarm with all NATed peers."
>
> The advantage of using DHT peers is that that statement wouldn't be true.

He never mentioned that the type of peer matters so I'm assuming that he's using a loose definition of "swarm" and including DHT peers in it. In that case, as he said, if you have such a swarm with all NATed peers then it prevents others from connecting to use them as an introducer to other peers (which is when hole punching comes in). Otherwise you get the chicken & egg problem. Even if DHT peers are treated separately then they can't be behind NAT themselves.

LilTroy wrote:

> He never mentioned that the type of peer matters so I'm assuming that he's using a
> loose definition of "swarm" and including DHT peers in it. In that case, as
> he said, if you have such a swarm with all NATed peers then it prevents others from
> connecting to use them as an introducer to other peers (which is when hole punching
> comes in). Otherwise you get the chicken & egg problem. Even if DHT peers are
> treated separately then they can't be behind NAT themselves.

I doubt it because in that case DHT wouldn't work either, which I've never seen happen.
I think he'd have mentioned it if it were possible. Also he says that it's an extension to PEX,
and PEX isn't used when connecting to DHT nodes.