Ephemeral Port Range Calculator

If you’ve read this far, chances are you’ve experienced it. Right when you’re ready to share your screen during that video call. Bang. Can’t get into that game lobby? Ping’s perfect but the lobby don’t load.

The typical response is “your router, your ISP” but it’s actualy a bit quieter than that: temporary port exhaustion. Networking’s broken, but the cable’s still plugged in and hardware’s still humming along. You just don’t have any more ports left to route your outbound traffic through to the internet.

Understanding Temporary Port Exhaustion

It’s a simple enough idea that can be misapplied. You want an identifier for each individual conversation with outside world for each device. A combination of a remote server and a local IP and port form the session. Because you have one public IP address behind your NAT firewall, the gateway has to provides a different temporary source port for each connection.

To think about this in terms of hotels, imagine these ports as hotel room. As long as there are no other guest using the hotel, everything is cool. But when the hotel is full, new guests arriving at the door gets turned away, even though building is perfectly fine.

That’s why I’ve included the calculator above which will run the math for you. Understanding what those inputs mean, however, helps you know if your home lab is being greedy or actualy starving.

The first thing most folks look at is the count of total ports available: Windows remains firmly in the IANA standard block of 16k ports and Linux typically has ~28k ports available. Sounds like plenty? Think about what moddern apps do. If you have a web browser running with 20 tabs open, each tab might be keeping dozens of active connections alive. These can include streams, media, background updates, and telemetry. Throw on a couple of Kubernetes pods or some CI/CD runners doing lots of short lived HTTP requests and your demands jumps vertically.

What’s key here is recognizing that your available ports aren’t a static pool. It’s a race where your application are creating connections as quickly as it can and the firewall is cleaning up dead bodies. Your strongest tool here is the hold time. The firewall maintains the state of connection for X amount of time (after the app disconnects) should some straggler packets roll in. A short-lived UDP like a DNS query ties up a port for five minutes if your UDP idle timeout is five minutes. This wastes five minutes of capacity that could of used by an actual human instead.

Adjusting the churn rate against the hold time here in the tool makes it obvious what happens. Long timeouts and high churn rates = bad combo. Make those protocols without long timeouts shorter and you’ll immediately release hundreds of mapping.

Another typical remedy to this problem is to add more public egress IPs. Each additional IP effectively multiplies your available port pool. But there are downsides here too: You need to update your firewalls which gets more complex. And some services may block IP changes because they’re designed to only support a single IP, which means your session will be broken when you rotate over to another IP. This is a blunt instrument that will get the job done, but doesn’t really solve the basic inefficiency of how your network manage state.

That’s laid out in the reference table on the page which compares various gateway profiles. For example, a typical consumer router might have a small state table that fill up long before the port range does. On the other hand, a conntrack gateway running on Linux can handle tens of thousands of entries provided you configure the hash buckets correctly. The port range isn’t everything. Just as important is hardware ceiling. Sure you can have sixty thousand open ports, but if your firewall can only track fifty thousand concurrent states, you’ll still hit the wall no matter how you do the math.

And then there’s the whole flow management thing, not port-counting per se, which is really what prevents NAT exhaustion. If you keep things under three quarters, it’ll be OK (remember to leave headroom for bursts). Have your apps pool connections and reuse them; don’t open new ones all the time. Make your timeouts aggressive on temporary stuff.

As long as you think of temporary ports as a limited commodity that needs to be carefully tended, and not as an unlimited free-for-all resource, your network will stop dropping random packets. It’s the hotel metaphor again. You don’t want more rooms, you want current guests to check out quicker.