BitTorrent Killed Our Whole Home Network: Turns Out Our IPv4 Was Behind ISP CGNAT

[!TIP] Audience: People who tinker with their home network and have seen BitTorrent take down the whole house without finding out why. Goal: Use captured live data to show how connection limits on an ISP’s internal IPv4 address can choke your entire home network, and how to block the flood right on your router. Problem → Fix:

• Rebooting the router wipes the logs, making it impossible to find the root cause → Write logs to disk, record a health snapshot every minute, and automatically capture the live state when the internet drops
• BitTorrent fires off a massive burst of dead connections and uses up the ISP’s connection quota → Rate-limit new IPv4 connections from the BitTorrent machine on the router, while leaving IPv6 unlimited
• Lowering connection limits in the BitTorrent client still fails to stop connection bursts → Actively reject excess requests at the router’s outbound interface so they never leave the house

I tinker with my home network and servers in my spare time, and whenever something breaks, I team up with AI to track it down. Today’s story is pretty embarrassing. Every time I started a BitTorrent download, our entire home lost internet. I fell into the same trap twice and guessed completely wrong at first. In the end, the culprit wasn’t any device inside our house. The IPv4 address my router got from PPPoE was actually an ISP internal address, and BitTorrent was blowing through our connection quota in seconds.

Starting BitTorrent Kills the Network, and Rebooting the Router Was a Red Herring

This happened on October 10 and October 24. Both days, our home network hit the exact same weird issue: shortly after I started a BitTorrent download, the entire house lost internet. The most baffling part was that even after I completely shut down the BitTorrent client, the network wouldn’t come back. Nobody in the house could get online. The only thing that worked was rebooting the router—as soon as it came back up, the internet was fine again.

If you run into a problem that “fixes itself after a router reboot,” your first instinct is probably the exact same as mine back then: this stupid router crashed again, probably out of CPU/RAM or because BitTorrent blew up its connection tracking table.

Yet twice I failed to pin down the cause, because I made a rookie mistake—by default, the router only kept its logs in RAM. Every time the internet died, I reached over and rebooted the router just to get us back online quickly. That reboot wiped the in-memory logs clean—every error and state record was gone.

On the night of October 10, the first time it happened, I did run a packet capture. What I saw was bizarre: 471 connection requests went out, and only 2 replies came back, while ping was still working fine at the exact same time. Back then I couldn’t figure out what that meant. The internet worked after a reboot, so I just let it slide—until I tripped over the exact same thing again on the night of October 24.

Save the Evidence First, Then Break the Network on Purpose

After the second outage on the night of October 24, I decided to stop guessing—and definitely stop rebooting the router and destroying the evidence. I talked it over with AI, and for step one that night, we changed nothing about the network itself and focused purely on preserving evidence:

First, I changed the router’s logging to write directly to disk, so the records would survive even if I was forced to reboot later. Next, I added a cron job to log a one-line network health snapshot every minute, recording the current connection count, whether domestic and foreign websites were reachable, and whether ping and DNS were working. Finally, I set up an automated script that would immediately capture the live network state and save it to disk the moment it detected an outage.

Once the evidence trap was set, at 21:17 that same night, I fired up BitTorrent on purpose and resumed 22 torrents all at once to watch how the network actually died.

It happened fast. Within 10 seconds of resuming the torrents, the machine running BitTorrent spawned 1552 outbound connections, and 1454 of them got no reply at all. A minute or two later, that machine’s outbound connections climbed past 2400, with 90% of them unanswered; at that point, peak outbound connections across the whole house hit 2792.

By 21:21, the familiar symptoms arrived right on cue: no device in the house could open any website, domestic or foreign. Three key findings stood out in the live data captured by the script:

1. All web pages were dead, but ping and DNS were still working normally.
2. During the 5-second capture window, 478 connection requests went out and 0 came back.
3. The stat that proved me completely wrong: the router’s own connection table was only 6% full, with 0 table insertion failures and 0 dropped packets.

Seeing those numbers, I knew I had blamed the router for nothing. The router was doing just fine—its connection table was practically empty and it hadn’t dropped a single packet. The problem had to be somewhere outside our front door.

At 21:21:38, I manually stopped all the torrents. This time I didn’t touch the router’s power cord; I just stared at the monitor. About 20 seconds after I stopped the torrents, the whole-home network came back to life on its own.

Root Cause: A 100.64 Internal Address and Connection Quotas

Once I laid all the evidence out together, the root cause became clear.

I took a closer look at the IPv4 address my router got from PPPoE, and saw it started with 100.64. Anyone who knows a bit of networking will recognize that block right away: it’s not a real public IP, but an ISP internal address (commonly known as Carrier-Grade NAT, or CGNAT).

That means many households are actually sharing the ISP’s public outbound IPs, and each household has a cap on how many concurrent connections it can hold.

Looking back at what happened during those few minutes at 21:17: as soon as the BitTorrent client started, it fired off over two thousand connection requests in a minute or two, and the vast majority of peers in those torrents were long dead. Even though they couldn’t connect, every single request sent out still took up one connection slot on the ISP’s equipment until it timed out and got reclaimed. Within a minute or two, those 2000+ unanswered dead connections completely maxed out our household’s quota at the ISP. Once the quota was full, whenever any other device at home tried to open a web page and establish a new connection, the ISP simply refused to let it through.

Put this root cause up against the three weird symptoms from earlier, and everything makes sense:

• Why didn’t the network recover right after stopping BitTorrent? All those unanswered connections that had already gone out had to wait to time out on the ISP’s side before their quota slots were freed. In the 21:21:38 test, it took about 20 seconds for them to clear out.
• Why did rebooting the router fix it immediately? Rebooting triggers a fresh PPPoE dial-up, and the ISP assigns a new internal IPv4 address with a clean quota (I checked, and the address after a reboot really did change).
• Why couldn’t web pages load while ping and DNS still worked? What got blocked were new TCP connections.

As for the exact connection cap the ISP sets per household, I didn’t run a separate test to pin down the number—all I know is that when our whole-home connections hit 2792 that night, the internet died.

Fixing It on the Router: Stopping Dead Connections Before They Leave Home

With the root cause clear, the plan was straightforward: stop the BitTorrent machine from blasting out new IPv4 connections in a short burst.

My first idea for an easy fix was to go straight into the BitTorrent client’s settings and turn down the connection rate. I tried it, and it didn’t hold the flood back at all—when I resumed those 22 torrents after lowering the setting, it still fired off around 1500 connection requests within 10 seconds (roughly 150 per second). Counting on the BitTorrent client to behave itself wasn’t going to work.

Since the software couldn’t keep its hands to itself, I had to tie it down on the router. I added rate-limiting rules on the router specifically for new IPv4 connections coming from the BitTorrent machine:

• TCP: At most 5 new connections per second (with a burst allowance of 20). Excess attempts aren’t silently dropped; instead, the router immediately replies with a “reject” back to the BitTorrent machine, so the client knows right away that the connection failed and won’t sit around waiting or retrying over and over.
• UDP: At most 10 new connections per second (with a burst allowance of 40), and anything over the limit is dropped.

That way, excess connection requests get stopped right at our own router. They never leave the house, so they never eat into our quota at the ISP. Also, the IPv6 address assigned to our home is a real public address and isn’t subject to this CGNAT quota, so the rules leave IPv6 completely unlimited.

At 22:06 that night, once the rules were live, I started all 22 torrents again to put it to the test:

Over those 5 minutes, the router rejected 855 new TCP connections and dropped 5943 new UDP connections.

With that many connections blocked, can BitTorrent still download? During those 5 minutes, download speeds ran between 1.5 and 5.7 MB/s, and upload sat around 2.4 MB/s. I didn’t record the speeds before adding the rate limit, so I can’t say how much they dropped. However, connection stats showed that 3/4 of BitTorrent’s connections were running over IPv6—the reason it could still download fine with IPv4 clamped down was public IPv6 carrying the load.

Follow-up Observations and Unanswered Questions

In the week after the fix, across October 25 and October 26, I left BitTorrent running at home for about 35 hours total (with the rate-limiting rules on the whole time), and the whole-home outage never happened again. That said, I haven’t run BitTorrent much since October 29, so whether it stays rock-solid over even longer continuous runs is still untested.

Also, since the router is now logging a health snapshot every minute, I should be upfront about a minor hiccup that showed up in the logs: during that week, the monitor caught 8 failed probes to domestic websites. Each one lasted only a single minute before recovering on its own, and BitTorrent wasn’t even running at the time. I haven’t looked into what caused those 8 brief blips yet.

After going through all this, my biggest takeaway comes down to one rule: next time the home network acts up, keep my hands off the router’s reboot button. The moment you reboot, the crime scene and all the evidence are gone; letting the machine capture the live state first beats everything else.