Ports, NAT and being firewalled
A BitTorrent client that reports its connection status as firewalled is telling you one specific thing: no incoming connections are reaching it.
The client still works. It still reaches out to trackers, the DHT and peers, and it still downloads. What it cannot do is accept a connection that somebody else starts, so it only ever trades with the peers it found and dialed itself, and to the rest of the swarm it does not appear to exist.
What NAT does to an incoming connection
NAT, network address translation, is the reason the firewalled status is the normal state rather than an unusual one. Your home router holds one public address and hands out private addresses to every device behind it. When your client opens a connection outward, the router notes which internal machine made the request and sends the reply back to it. When a stranger sends a packet inward, unprompted, the router has no such note, no way to guess which of the devices it was meant for, and drops it. That is not a security setting anybody chose. It is what address translation has to do to work.
So a BitTorrent transfer under NAT runs entirely on connections your client started. That is enough to download from any peer who is reachable, which is why a firewalled client is not a broken one. It becomes a real limit when a swarm is small, because two firewalled peers usually cannot reach each other, and on a thin torrent much of the swarm is firewalled. An extension implemented in libtorrent lets a peer connected to both introduce them to each other, which does not always work.
The listening port, and which number to use
The listening port is the single number your client tells other peers to reach it on, and it is what a forwarding rule points at. Any port above 1024 that nothing else on the machine is using will work. Ports below 1024 are reserved for system services and on Linux and macOS require elevated privileges, so no client uses them by default.
The original BitTorrent convention used a small block beginning at 6881, and that block is still registered for the protocol, which is precisely the argument against choosing it: it is the best known range and the easiest to treat differently anywhere along the path. Most clients now pick a high numbered port at random the first time they run and keep it. In qBittorrent the number sits in the connection section of the preferences, with a button to randomize it, and it must match the forwarding rule exactly, on both the internal and external side.
Port forwarding against opening a port in the firewall
Port forwarding and opening a port are two different operations on two different devices, and a client can need both. Forwarding is a routing instruction on the router. Opening is a permission on the computer.
- Port forwarding, on the router
- A rule that says traffic arriving on this port from the internet goes to this private address inside the network. It solves the NAT problem, because it gives the router the note it was missing.
- Opening a port, in the firewall
- A rule on the computer itself that permits a program to receive traffic on that port. Windows Defender Firewall asks about this the first time a client runs, and qBittorrent adds its own rule when installed with that option ticked. On Linux the same job belongs to whatever firewall the distribution ships.
Forwarding without the local rule sends traffic to a machine that then refuses it. The local rule without forwarding permits traffic that never arrives. Neither one is a speed control: both simply restore the ability to be contacted, and what that is worth depends on the swarm.
What UPnP and NAT-PMP actually change
UPnP and NAT-PMP let the client ask the router to create the forwarding rule itself, so nothing has to be typed in by hand. The client sends the request at startup, the router creates a temporary rule for the listening port, and the status changes from firewalled to connected within a minute or two. Both are on by default in most clients and supported by most consumer routers.
What they change is who writes the rule, not what the rule does. A manual forward and a UPnP forward produce identical results. UPnP fails quietly in three ordinary situations: the router has it switched off, which many do by default now; there are two routers in series, so the client negotiates with the inner one while the outer one still drops everything; or the address the router hands your machine changes, leaving a rule pointing at a device that has moved. A fixed local address, set as a reservation in the router, prevents the third.
Setting up a forward, in order
- Find the listening port in the client's connection settings and write it down.
- Reserve a fixed private address for the machine in the router, usually under DHCP reservations, so the rule keeps pointing at the right device.
- Add a forwarding rule in the router for that port number, TCP and UDP, to that private address.
- Allow the client through the local firewall on the same port, if it was not allowed at install time.
- Restart the client and read the connection status, which should change from firewalled to connected once a peer has reached it.
Firewalled, offline and connected mean three different things
| Status | What the client is telling you | What to check first |
|---|---|---|
| Connected | The client has reached peers and has been reached by at least one incoming connection | Nothing |
| Firewalled | Outgoing connections work, no incoming connection has arrived | The forwarding rule, the local firewall, and whether the port in the rule still matches the client |
| Offline | The client has reached nothing at all, no tracker, no DHT, no peer | The machine's own network connection, then whether a proxy or a tunnel is configured and down |
| Stalled, on one torrent | The client is connected and waiting, and that torrent has nobody sending | The swarm for that torrent, not the port |
The distinction matters because the three have nothing in common. Offline is a network fault on your side. Firewalled is a reachability limit that a working transfer can live with. Stalled is a property of one swarm and no port setting affects it.
When forwarding cannot fix it
Forwarding cannot fix a connection where the public address is not yours to forward. Carrier grade NAT, in which the provider translates addresses for many customers behind one shared public address, is common on mobile networks and on some fixed lines, and no rule in the home router can create an inbound path through it. Neither can a rule help on a network you do not administer, such as an office or a campus. In those cases the client stays firewalled permanently, and transfers still run using outgoing connections only.
A VPN or proxy service sits in the same category. Routing peer traffic through such a service replaces the address peers see with the provider's, and unless that provider deliberately offers a forwarded port, incoming connections stop reaching you and the client reports firewalled from then on. That is a factual consequence of the routing, not a fault, and Is it safe? sets out what the service does and does not change.
Being reachable is worth most to a seeder, since a peer that nobody can contact is one that can only give to the peers it happens to have dialed. How a transfer works explains where in the exchange an incoming connection is used, and The swarm explains why a small seeder count makes reachability count for more.