How do you find the subscriber behind a public IP and port?

You take the external address and port, fix them to an exact moment, find the translation that was live then, and follow the internal address it points at to an account. Four stages. Each one narrows the field, each one can fail without saying so, and the last one is where a wrong answer stops looking wrong.

Where does the walk start, and what must be settled first?

It starts before any searching, with three checks that decide whether the rest is worth attempting. Skip them and you can spend a day producing a result that was never going to mean anything.

First, the traffic has to be yours. External addresses get reassigned between networks, and blocks are leased and returned, so an address that routes to you today may have belonged to somebody else during the period in question. Registry history settles that in a minute.

Second, the period has to fall inside what you still hold. If it does not, the walk is over before it began, and the sooner that is established the better for everyone involved.

Third, the clocks have to agree. Every value you were given carries an offset, whether it was stated or not, and every record you will search carries its own. Converting once, at the start, and writing down the converted value is the single cheapest habit in this whole exercise.

With those settled, the walk itself is four stages.

1. Confirm the external address was in your hands during that period, and that records exist for it.
2. Find the translation that held that external address and port at that instant, which yields an internal address.
3. Resolve the internal address to an account by asking which subscriber held it at that same instant.
4. Write the result out with the steps still attached, so it can be checked by somebody who was not there.

How do you get from a shared external address to a single internal address?

By searching on all three values together rather than any one of them. The external address narrows the field to everybody translated through it, the port narrows that to one mapping, and the moment decides which of the mappings on that port is the right one.

Take a request naming 192.0.2.144, port 41772, at 21:14:07 on a Tuesday. Searching the records for that combination returns one translation.

The field has gone from a few hundred households to one internal address, and it took one search. That is the entire value of holding the port alongside the address, and it is why the request contains a port at all.

Searching on the external address by itself is not a shorter route to the same place. It returns every translation that ran through that address during the period, which on a busy evening is thousands of rows covering hundreds of households, with nothing to choose between them. The port is what turns that list into a single row, and the moment is what confirms the row is the right one.

Two things about that result deserve suspicion before you move on. If more than one translation comes back for the same port at the same instant, something is wrong with either the clock or the assumption that one device was doing the translating. If none come back, widen the moment by a minute before concluding anything, because a record written when a connection opens and a moment noted at the far end are rarely the same second.

How does an internal address become an account?

By asking a second, separate question of a second, separate record: which subscriber held 100.64.12.9 at 21:14:07 that evening. The NAT record cannot answer this, and it was never able to.

Where subscriber sessions end on the translating device, the answer is often already sitting in the line you just found, in the field that names the interface. Where they end elsewhere, the internal address must be resolved against session history, and putting a subscriber name against a translation covers that stage on its own.

What matters here is that this is a stage and not a formality. It has its own failure, and the failure is quiet: matching against whoever holds that internal address now, rather than then, returns a real customer with a real account and no indication that the answer belongs to somebody else.

One check belongs here and is easy to skip. Internal addresses go to your own equipment as well as to customers, so a trace can land on a management interface, a hotspot gateway or a range kept for testing. When the address resolves to something you own rather than somebody you bill, what you are looking at is traffic that started inside your own network, which is a different conversation and much better recognised before the reply goes out than after.

Finish the stage by taking the account through to a billing record, because an account identifier is not yet a person. What comes out is a name, an address for service, and the shape of the connection, which is what was being asked for in the first place.

What goes wrong at each stage without announcing itself?

Every failure in this walk produces output. That is what makes it dangerous. Nothing throws an error, nothing comes back empty, and the result looks the same whether it is right or not.

Where a trace goes wrong quietly, and what the output looks like when it does

Stage	The quiet failure	What you get back
Before searching	The offset was assumed rather than converted	A tidy result from an hour that nobody asked about
Matching the translation	A second device also translates and was not searched	Nothing, read as proof that the traffic was not yours
Matching the translation	The port was reissued to another mapping seconds later	Two candidates, and whichever one is picked looks final
Resolving the account	The match ran against the current holder of the address	A named customer who was somewhere else entirely
Writing it up	Only the name was kept, not the steps	An answer that cannot be defended six months later

The pattern across all five is the same. Not one of them shows up in the result, and every one of them shows up in the working, which is the whole argument for keeping the working.

What makes this take days instead of minutes?

Not the search. The search is a lookup against three values and finishes in the time it takes to type them. Everything slow about a trace happens before and after it.

Before it, the time goes on finding things. Which device was translating that evening, whether it still exists, where its output went, whether anybody kept it, and who has the credentials. On a network where nobody has done this in two years, that alone fills an afternoon and involves people who were doing something else.

After it, the time goes on doubt. Somebody asks whether the offset was right, so it gets checked again. Somebody points out there was a second router, so the search is repeated. Each round is short and there are usually four of them, spread across two days, because the people involved have other work.

A second request about the same incident is common, and it tends to arrive weeks later with different wording. Where the working from the first trace was kept, answering it is a filing exercise. Where it was not, the walk runs again from the beginning, including the slow parts, and the two results then have to be reconciled with each other before either can be sent anywhere.

The way out of both is preparation rather than speed. One place holding the records, one description of which device covers which part of the network, and one written procedure that a second person can follow. Networks with those three answer in minutes and are mildly surprised that anybody finds it difficult.