What Is NAT/Firewall Traversal?

Back to Blog

Why Remote Sites Are Hidden

To conserve scarce public IP addresses, cellular carriers put most data SIMs behind carrier-grade NAT (CGNAT). The gateway gets a private address; the carrier translates its outbound traffic to a shared public address on the way out. This works perfectly for connections the device starts, but there is no fixed public IP or open port for anyone on the outside to connect back in on. Corporate and site firewalls add the same barrier by design: they permit outbound connections but drop unsolicited inbound ones.

The result is that a head end cannot simply dial into a field device by IP. Any architecture that assumes the SCADA server initiates connections to sites will fail on a typical cellular fleet. This single fact drives much of how remote telemetry is designed.

How Telemetry Gets Through

The cleanest approach is to flip the direction: let the device start the connection. Because NAT and firewalls allow outbound sessions and keep them open for return traffic, an outbound-only connection from the gateway to the cloud - polling out, an MQTT session, or an HTTPS tunnel - passes through cleanly with no port forwarding. This is the dominant pattern in cellular SCADA precisely because it sidesteps NAT entirely.

Where two-way or inbound access is genuinely needed, options include a VPN (the gateway dials into a concentrator and becomes reachable on a private network), a private APN that gives fleet devices routable addresses, or a rendezvous server both sides connect out to. Each avoids exposing the site directly to the internet. A cloud-native SCADA like Merobix is designed around outbound, device-initiated connectivity, so it reads sites behind CGNAT without inbound holes punched in any firewall.

How to Confirm You Are Behind CGNAT

Before designing around NAT, confirm it is actually in play. Compare two addresses: the WAN address the gateway's own status page reports, and the public address the outside world sees when the gateway makes an outbound request. If they differ, translation is happening upstream. The carrier-assigned address itself is often the giveaway: the shared address space reserved for carrier-grade NAT is 100.64.0.0/10, so a gateway holding an address in that block is behind CGNAT by definition, and the familiar private ranges - 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 - indicate NAT of some flavor as well.

The distinction matters because the remedies differ. NAT at your own site router is under your control: you can add forwarding rules or firewall exceptions. NAT in the carrier network is not - no configuration on equipment you administer can open an inbound path through it, and the realistic options narrow to a device-initiated architecture, a fixed public address from the carrier, or a private APN.

Keeping the Outbound Path Alive

An outbound-only connection solves reachability, but NAT adds a quiet maintenance burden: the translation entry that lets return traffic reach the gateway is temporary state in the carrier's equipment, discarded after a period of inactivity. A session that goes idle - a slow-polling site, a nighttime lull - can find its mapping gone, after which packets from the cloud side simply vanish. The connection looks established to both endpoints while delivering nothing, which is among the more confusing failure modes to troubleshoot remotely.

The standard countermeasure is periodic keepalive traffic frequent enough to refresh the mapping before the carrier expires it. The right interval is carrier- and plan-specific, so it is tuned empirically: too long and sessions silently die, too short and the keepalives themselves eat the data budget on a metered SIM. Setting the MQTT keepalive for a cellular link is the canonical version of this exercise, and the same reasoning transfers to TCP keepalives and protocol-level test frames.

Choosing a Traversal Approach

Approach	How it works	Fits best when
Device-initiated outbound	Gateway connects out to the platform; NAT never sees an inbound attempt	Monitoring and telemetry fleets; the default choice
VPN to a concentrator	Gateway dials out into a private overlay network and becomes addressable inside it	Routine inbound engineering access to devices is required
Private APN	Carrier places the fleet's SIMs on a private network routed to the operator	Larger fleets standardizing on one carrier arrangement
Fixed public IP SIM	Carrier assigns a routable public address to the SIM	Isolated sites that truly need direct reachability, paired with strict firewalling

The approaches compose. A common production pattern is outbound-only telemetry across the whole fleet plus an on-demand VPN for occasional configuration sessions. The cost and security tradeoffs between the carrier-side options are covered in more depth in private APN versus public cellular; the short version is that anything granting inbound reachability also expands the attack surface and needs firewall policy to match, and that decision belongs with whoever owns network security for the fleet.

Troubleshooting a Site You Cannot Reach

1. Confirm the gateway is actually online: does the carrier's management portal show an active data session, and is outbound traffic from the site arriving anywhere?
2. Establish which direction is broken - a site that reports data but rejects inbound connections is a NAT symptom, while a fully silent site is a power or connectivity problem.
3. Check the address the gateway holds against the CGNAT and private ranges to establish whether inbound was ever possible.
4. If the design depends on a VPN or private APN, verify the tunnel or APN session is up before blaming the device.
5. Only then open a carrier ticket, with the session logs and addresses already collected - carrier support moves faster with evidence attached.

The recurring theme is that NAT failures masquerade as device failures. A field technician dispatched to power-cycle a perfectly healthy gateway is the classic cost of skipping the second step.

Frequently Asked Questions