CGNAT on mobile networks: why an outbound proxy does not open an inbound port
In mobile networks, many subscribers can share one public IPv4 address through carrier-grade NAT. An outbound connection creates temporary address-and-port state, but it does not turn the device into a publicly reachable server. Purchased HTTP or SOCKS5 access is intended for outbound client requests unless the service explicitly offers an inbound feature.
Key points in one minute
- A subscriber does not administer carrier-grade NAT directly; an explicit mapping can be requested through PCP or another mechanism only when the carrier provides it.
- A public IP can be shared, while connections are also distinguished by ports and time.
- Outbound NAT state does not create a permanent inbound port mapping.
- A proxy port belongs to the access service, not to an exposed mobile device.
- SOCKS5 BIND is a separate protocol capability that requires explicit service support.
- Without a carrier-supported explicit mapping, an inbound workload needs a separate product or tunnel that publishes the service.
Why carriers use CGNAT
There are not enough public IPv4 addresses to give every device a unique one. CGNAT translates internal addresses from many subscribers into a shared external pool and keeps a table of active mappings. A destination sees the translated public address and port, not the mobile device's internal address.
Outbound and inbound are different tasks
When a device sends first, NAT can create a mapping for replies in that session. An unsolicited inbound connection has no matching state, so the NAT does not know which internal device should receive it and usually drops it. The subscriber does not reconfigure the carrier-grade NAT directly, although the carrier can provide PCP or another explicit mapping mechanism. Without such a mechanism, persistent inbound access needs a managed tunnel or another published endpoint.
Why a proxy port is not port forwarding
The Host and port in the portal belong to the proxy service that accepts an authenticated client connection. The service then creates an outbound connection over the mobile channel. A third party connecting to that port does not reach the mobile device and does not publish your local web server.
The SOCKS5 standard also defines BIND for a negotiated inbound connection through the SOCKS server. However, SOCKS5 credentials alone do not prove that the client, proxy service, and plan implement or allow BIND. An ordinary issued port remains a proxy access port unless the service separately documents an inbound capability.
A shared IP is not one identity
One public address is often insufficient for event analysis: transport protocol, external port, and precise time matter for network correlation. Activity from a public mobile IP therefore cannot automatically be attributed to one subscriber. The user should not treat a shared address as a permanent identity for the connection either.
Choose the right tool
HTTP or SOCKS5 works for outbound requests from a browser, API client, or test tool when the application supports it. Receiving webhooks, publishing a server, remote device access, or peer-to-peer workloads requires a service that explicitly provides an inbound endpoint and documents authentication. Do not try to turn an ordinary proxy port into that endpoint through scanning or arbitrary settings.
Practical checklist
- 1Classify the task as outbound or inbound.
- 2Do not confuse a proxy port with a mobile-device port.
- 3For shared-IP analysis, retain port, protocol, and time.
- 4Do not assume a mobile IPv4 address is permanent.
- 5Use an explicit inbound endpoint for webhooks or servers.
- 6Verify the separate service's authentication and publication rules.
Sources and documentation
This material is based on primary, official, and technical sources. The article is an original summary written for this knowledge base.