Why can’t a provider identify one customer from some public IP addresses?¶
A provider may confirm that a public IP address belongs to its network but still be unable to identify one customer from the information supplied. A common reason is carrier-grade NAT (CGNAT): many customers can share one public IPv4 address at the same time.
The important distinction
“This IP belongs to our network” is not the same as “these connection details identify one customer session.” A shared public address may need an exact time, public source port and protocol before the provider can separate users.
What CGNAT changes¶
With ordinary home NAT, several devices may share the public address allocated to one customer connection.
CGNAT adds another sharing layer inside the provider network:
| Customer/session | Shared public IP | Public source port | Protocol |
|---|---|---|---|
| A | 198.51.100.84 | 51543 | TCP |
| B | 198.51.100.84 | 60218 | TCP |
| C | 198.51.100.84 | 41702 | UDP |
An external platform could therefore record the same public IP for activity from different customers.
A failed provider match¶
An investigator sends:
source_ip=198.51.100.84
time=2026-07-24T20:41:16Z
The provider responds in substance:
The address was in use on our mobile network at the stated time, but it was shared. The supplied information does not distinguish one translation or customer session.
That is not necessarily the end of the line. The next question is:
Did the original service record the translated public source port and protocol for that same event?
Recover from the original evidence¶
The investigator returns to the source organisation and obtains the fuller event:
event_id=FRM-482771
time=2026-07-24T20:41:16.482Z
source_ip=198.51.100.84
source_port=51543
protocol=TCP
The corrected request now contains the fields the provider may need to identify the relevant translation or session.
See what a source port is and when you need it and use the mobile/CGNAT request checklist.
If the provider cannot make a match, check these first¶
- Was the public source port omitted from the first return?
- Were seconds or milliseconds removed from the timestamp?
- Is the time zone or UTC offset clear?
- Did the IP, port, protocol and time all come from the same event?
- Was the correct public-facing source port supplied rather than a destination or private port?
- Does the provider still retain the relevant translation records?
What if the source system never recorded the port?
Then that limitation matters. Do not manufacture precision by guessing or combining fields from another event.
Ask the source whether fuller connection logging, another event-level identifier or another relevant record exists. Ask the provider whether its own records support another matching route. The answer is provider- and evidence-dependent.
What a successful match still means¶
A successful translation match may identify a network session, SIM, subscriber account or service record. It does not automatically identify:
- a particular handset;
- the person holding or using the handset;
- a hotspot-connected device; or
- the person responsible for the activity.
Continue with what an ISP or provider result actually establishes.
Failed request → sensible recovery¶
| What happened | Wrong reaction | Better next step |
|---|---|---|
| Shared IP cannot be matched | Assume attribution is impossible | Return to the original event and check for missing fields |
| Timestamp was rounded | Invent greater precision | Obtain the source system’s retained timestamp |
| Source port absent | Substitute destination port | Ask whether the public-facing source port was recorded |
| Provider records unavailable | Keep resending the same request | Record the limitation and identify other proportionate evidence routes |
Operational takeaway¶
CGNAT does not make an IP address useless. It changes the question from “Who had this IP?” to “Which translated connection used this shared public IP for this exact event?”
