Private vs Public IP for Cellular IoT

What is a private IP address?

A private IP address exists only within a defined network boundary. It is not routed on the public internet, which means no external host can initiate a connection to a device that holds one. The address ranges for private IP space are defined in RFC 1918 and cover three blocks:

• 10.0.0.0 – 10.255.255.255 (10.0.0.0/8) – commonly used by carriers for CGNAT pools
• 172.16.0.0 – 172.31.255.255 (172.16.0.0/12)
• 192.168.0.0 – 192.168.255.255 (192.168.0.0/16) – used on LAN segments behind routers

When a cellular router or IoT device connects to a mobile network and receives an address in one of these ranges, it sits behind the carrier’s Network Address Translation (NAT) layer. The carrier handles the translation between the device’s private address and a shared public IP used for outbound traffic. From the outside internet, the device is invisible.

This invisibility to the internet is the primary security advantage of the private IP model. There is no publicly routable address for a threat actor to discover, scan, or probe. The carrier NAT layer acts as an implicit stateless firewall for inbound traffic.

What is a public IP address?

A public IP address is a globally unique, internet-routable address assigned to a device. Any host on the internet can send packets directly to it. For a cellular IoT device, this means the router or modem’s WAN interface is directly reachable from anywhere in the world – which is both the feature and the risk.

Public IPs for cellular devices come in two forms. A dynamic public IP is assigned from the carrier’s pool each time the device connects – it will change between sessions. A static public IP is fixed and persistent, usually obtained as an add-on from the SIM provider, often at additional cost.

How cellular IoT SIMs get their IP

When a cellular IoT device connects to the network, it authenticates through an Access Point Name (APN). The APN is the gateway configuration that tells the carrier’s core network how to route traffic for that connection. The APN determines, among other things, whether the device receives a private or public IP address.

The default shared APN provided by most UK mobile operators assigns private IP addresses from a CGNAT pool. This is fine for devices that only need outbound connectivity – sending telemetry to a cloud endpoint, for example. The device can initiate connections to external servers; it just cannot be reached from outside without additional configuration.

To obtain a public IP, a subscriber typically needs to either request a static IP add-on through their SIM provider, or provision SIMs on a private APN with static addressing configured by the carrier. Standard consumer SIMs almost never provide public IPs.

The APN and IP assignment chain

The path from SIM card to IP address runs: SIM authenticates to the carrier core – the GGSN or P-GW assigns an IP from the APN’s configured pool – that address is either a private address (if using shared or CGNAT APN) or a routable public address (if using a public IP APN or private APN with static addressing).

On a private APN, the carrier can assign static private IPs from a dedicated pool that routes only within your organisation’s network segment. Traffic never touches the public internet unless you explicitly route it there. This is covered in more detail in the private APN section below.

Static vs dynamic – the other axis

The private/public distinction is only one dimension. The other is whether the IP is static (fixed) or dynamic (changes between sessions or at intervals). The combination of these two axes gives four possible configurations, each suited to different use cases.

Dynamic IPs introduce a practical problem for remote access: you cannot connect to a device if its address has changed since you last noted it. This is why many deployments that rely on public dynamic IPs use Dynamic DNS (DDNS) services – the device updates a hostname record whenever its IP changes, so the hostname always resolves to the current address. This works but adds a dependency and a small latency overhead on reconnection.

For most industrial IoT use cases, the preferred path is private static (via private APN) or private dynamic with a VPN. The VPN approach is described in detail below.

Remote access without a public IP

The most common objection to private IP addressing is access: “how do I get into my device if it is not directly reachable?” This is a solved problem. Several approaches are well-established in industrial IoT, each with different trade-offs.

Outbound-initiated tunnels

The fundamental principle behind most private IP remote access solutions is that the IoT device, sitting behind NAT, initiates an outbound connection to a server. Because the device initiates the connection, it passes through the NAT layer without issue. The server – which has a public IP – then serves as a relay or rendezvous point through which the remote engineer can reach the device.

DDNS with public dynamic IP

If the device has a public dynamic IP, a Dynamic DNS service (such as DuckDNS, No-IP, or a provider’s built-in DDNS) can map a consistent hostname to the changing address. The device updates the DNS record when its IP changes. Remote access then uses the hostname rather than a specific IP. This approach works but creates a brief connectivity gap during IP transitions and relies on a third-party DDNS service remaining available. Many industrial routers include built-in DDNS client support.

Vendor cloud management platforms

Several router manufacturers offer their own cloud management platforms that handle the connectivity relay problem. These platforms require the router to maintain an outbound connection to the vendor’s cloud, through which remote access tunnels are established. They remove the need to manage VPN infrastructure yourself, though they introduce a dependency on the vendor’s cloud availability and may have per-device subscription costs. This category of tooling works regardless of whether the device holds a private or public IP.

VPN options compared: OpenVPN, WireGuard, ZeroTier

For IoT deployments relying on private IPs, a VPN is the standard mechanism for enabling remote access. The three protocols used most widely in industrial cellular deployments each have different strengths. The right choice depends on your infrastructure, fleet size, and whether you have CGNAT to contend with.

The CGNAT problem

Standard VPN configurations assume that at least one end of the tunnel has a routable public IP. If both ends sit behind NAT – which is increasingly common as operators roll out CGNAT – a traditional VPN setup breaks. You need either a relay server with a public IP acting as the concentrator, or a protocol that handles NAT traversal automatically.

OpenVPN

OpenVPN is the most widely supported VPN protocol in cellular router firmware. It operates over TCP or UDP, uses TLS for authentication and encryption, and has been battle-tested in industrial deployments for well over a decade. The trade-offs are its comparatively large codebase, higher CPU overhead than newer protocols, and the requirement for a public IP on the server side. Most cellular routers support OpenVPN natively. Configuration is manual but well-documented.

WireGuard

WireGuard is a modern VPN protocol built into the Linux kernel. Its codebase is roughly 4,000 lines versus OpenVPN’s 100,000+, making it substantially easier to audit and maintain. It uses ChaCha20 encryption and Curve25519 key exchange. Performance is significantly better than OpenVPN, with lower latency and better throughput on constrained cellular connections. The limitation for IoT: WireGuard requires at least one peer to have a static, routable IP for the initial handshake. Behind CGNAT on both ends, it will not establish a connection without a relay or a workaround such as a public VPS acting as a concentrator. An increasing number of industrial routers now include WireGuard support in firmware.

ZeroTier

ZeroTier creates a virtual Layer 2 network across internet-connected devices, handling NAT traversal automatically using UDP hole-punching and relay fallback. This makes it particularly useful for IoT deployments where devices sit behind CGNAT – no public IP is required on the device side. ZeroTier’s root servers facilitate peer discovery; once a direct connection is established, traffic goes peer-to-peer. If direct connection fails, traffic routes through ZeroTier’s relay infrastructure. The free tier supports up to 25 devices; larger fleets require a paid subscription or self-hosted controller.

Private APN – the enterprise option

A private APN is a dedicated gateway configuration provisioned by the mobile operator specifically for your organisation. Instead of routing your devices through the shared public internet infrastructure, traffic is routed directly into your private network – typically via a dedicated IP transit connection, MPLS link, or IPsec tunnel between the carrier and your data centre or cloud VPC.

The key properties of a private APN deployment are that devices receive static private IP addresses from a pool you control, all traffic is routed into your infrastructure without transiting the public internet, and access can be restricted to that private network segment entirely. This provides the strongest isolation possible over cellular.

Private APNs are typically provisioned through enterprise SIM arrangements with operators or specialist IoT SIM providers. The setup involves coordination with the carrier to establish the dedicated routing, and usually requires a minimum device commitment. The cost per SIM is generally higher than a standard IoT tariff, but the reduction in VPN infrastructure complexity and security overhead can justify the investment at scale.

Security posture comparison

The security implications of each approach are often misunderstood. Private IP is not automatically secure – and public IP is not automatically a liability. What matters is the combination of addressing, access controls, and the security of the device itself.

Private IP with CGNAT

The NAT layer provides implicit inbound blocking. No unsolicited connection can reach the device from the internet. This is not a firewall – it is a side-effect of NAT that happens to provide an identical result to inbound blocking. The risk shifts to the device’s outbound connections: if the device is compromised, it can still initiate connections to external infrastructure. Malware and botnet activity from IoT devices routinely operates through this mechanism.

Public static IP

The device is directly reachable. Security depends entirely on what is listening on that address. A cellular router with a properly configured firewall, strong credentials, restricted management port access, and current firmware can be secure on a public IP. The attack surface is real but manageable. The danger lies in default configurations – factory-default passwords, management interfaces exposed on WAN, unnecessary services running.

VPN over private IP

This is the preferred architecture for most industrial deployments. The device has no inbound exposure. Access is mediated through an authenticated, encrypted tunnel. The attack surface is limited to the VPN endpoint itself and the device’s outbound connectivity. If the VPN endpoint is well-hardened and the device firmware is kept current, this configuration is difficult to attack from the internet.

Private APN

The strongest isolation. Device traffic never enters the public internet. Attack vectors are limited to the cellular network itself and the internal network segment. The threat model shifts from external internet attackers to insider threats and compromised devices within the same APN segment. Appropriate for high-security deployments.

Decision framework: which to choose

The right answer depends on three variables: what the device needs to do, how you need to access it, and what your security and compliance requirements are.

If devices only send data outbound

Devices that push telemetry to a cloud platform, MQTT broker, or HTTP endpoint have no need for inbound reachability. Private dynamic IP is appropriate, lowest cost, and simplest to provision. No additional setup required.

If you need occasional remote access to a small fleet

Private IP with WireGuard or OpenVPN provides secure, manageable remote access without the cost of static public IPs. Set up a small VPS or cloud instance as the VPN concentrator, configure the router firmware client, and you have persistent remote access without exposing any device to the internet. For very small deployments or temporary access needs, ZeroTier removes the need to manage server infrastructure.

If you need remote access and are behind CGNAT with no server

ZeroTier or a vendor cloud management platform. Both handle the NAT traversal automatically.

If your backend requires inbound connections to specific devices

This is the primary legitimate use case for static public IPs – for example, a SCADA server that polls devices by IP, or an application that requires a fixed known address for each endpoint. Consider whether the same result can be achieved with a private APN and static private IPs before committing to public addressing.

If you operate a large fleet with compliance requirements

Private APN with static private IPs. The additional cost is typically justified by the reduction in attack surface and the elimination of VPN infrastructure complexity.

If you need IP whitelisting on a third-party platform

Some cloud platforms or APIs restrict inbound connections to a whitelist of known IPs. This is a common requirement in finance, healthcare, and utilities integrations. Static public IP is the most direct solution. Alternatively, route outbound traffic through a proxy or egress node with a fixed public IP – this achieves the same result without exposing the device’s own address.

Full comparison table