Network Address Translation (NAT) explained for IoT

Most internet-connected devices in the world don't have their own public IP address. They sit on a private network, share a single public IP, and rely on a router to translate between the two. That router is doing NAT: Network Address Translation. This article explains what NAT does, why it's everywhere, and what it means for your Simbase SIM.

What NAT does

A NAT gateway sits between a private network and the public internet. Its job is to rewrite IP addresses on packets so that:

  • Outbound traffic from a private device looks like it's coming from the gateway's public IP.

  • Return traffic from the internet to the gateway gets re-routed to the right private device.

A simplified walk-through:

  1. Your laptop (private IP 192.168.1.10) sends a request to a web server.

  2. The packet leaves your laptop with source 192.168.1.10 and destination 93.184.216.34 (the server).

  3. The router or NAT gateway intercepts the packet. It replaces the source with its own public IP (say 203.0.113.5), notes the mapping (192.168.1.10:55124) ↔ (203.0.113.5:62001) in its NAT table, and forwards.

  4. The server replies to 203.0.113.5:62001.

  5. The router looks up the NAT table, sees that maps to 192.168.1.10:55124, rewrites the destination, and forwards the response to your laptop.

Your laptop never knew it was behind NAT. The web server never knew there was a private network.

Why NAT exists

Three reasons:

  1. IPv4 conservation. There are about 4.3 billion IPv4 addresses but vastly more devices. NAT lets thousands of devices share one address.

  2. Inherent firewall. Devices behind NAT can't be reached from the internet directly. Packets sent to the gateway with no matching NAT table entry get dropped. This is a strong default security posture.

  3. Network independence. Each private network can use the same address space (192.168.x.x) without coordinating with anyone else.

NAT's downsides

  • Inbound connections are blocked by default. If something on the internet wants to talk to your device, it can't initiate the conversation. Workarounds exist (port forwarding, NAT traversal, hole-punching) but they're complex and unreliable.

  • Some protocols struggle. Anything that embeds IP addresses inside the application payload (older VoIP, FTP active mode, some VPN protocols) breaks under NAT unless the gateway has specific helpers.

  • Connection tracking has limits. Very-high-throughput devices can exhaust the NAT table on small gateways.

  • Logging is harder. From the internet's view, all your devices look like one IP, so attributing traffic to a specific device requires the NAT gateway's logs.

NAT and Simbase SIMs

By default, every Simbase SIM sits behind a NAT gateway at the Simbase mobile core. This means:

  • The SIM can initiate outbound connections to your APIs, MQTT brokers, web servers, anything on the internet.

  • The SIM cannot accept inbound connections. Your servers can't open a connection to the SIM directly.

  • The SIM gets a private IP that's not visible from the internet.

For typical IoT use cases (a device that polls a server or pushes data via MQTT or HTTP), this is exactly what you want. It's secure, it's simple, and it doesn't cost extra.

When NAT becomes a problem

NAT gets in your way when you need to reach the device from the outside:

  • Remote SSH into a router or gateway

  • Remote configuration UI on a deployed device

  • Server-initiated push to the device (for example, "wake up and report")

  • Hosting a service on the device (web server, RTSP camera feed)

  • Site-to-site VPN terminated on the device

For any of these, you need to bypass NAT for that SIM. Simbase does this by assigning a Public IP, which routes traffic through a dedicated gateway with a routable address.

See Public IPs for the steps.

NAT vs CGNAT

You may see CGNAT (Carrier-Grade NAT) in cellular network discussions. CGNAT is NAT done at the carrier level. Your operator NATs you behind their public IP before any of your traffic touches the internet. Most consumer mobile networks use CGNAT. From the device's perspective, it's identical to ordinary NAT.

SIMs without a Public IP are NATed at the Simbase gateway. The effect is the same as CGNAT on a consumer mobile network: a private IP on the device, a shared public address facing the internet, and no inbound connections.

Common questions

No. Port forwarding requires control over the NAT gateway. Simbase's NAT gateway is shared and isn't user-configurable. If you need inbound access on specific ports, assign a Public IP and use that gateway's firewall rules.

No. MQTT is a long-lived outbound connection. The client opens it, the broker holds it open, and messages flow in both directions over that one connection. NAT handles this fine.

No, they're isolated by the NAT gateway. They can communicate via a public server (or VPN) that both can reach outbound.

Indirectly. Simbase assigns IPs via DHCP at attach, so the SIM may get a different private IP each time. NAT handles this transparently for outbound connections. If you need a stable address, assign a Public IP for a routable static address, or use a private network for static addressing inside your own subnet.

Network Address Translation (NAT) explained for IoT