You have a gateway on a cellular SIM at a remote well, but you cannot reach it from the office - it has no public address you can connect to. That is NAT at work, and getting past it is NAT traversal. This guide explains why remote sites are hidden behind NAT and firewalls and how telemetry reaches them anyway.
NAT/Firewall Traversal in one line: NAT/firewall traversal is the set of techniques used to establish a connection to a device that sits behind Network Address Translation or a firewall, which by default blocks unsolicited inbound connections - a common obstacle because most cellular SCADA sites have no public, reachable IP address.
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.
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.
Because carriers place most data SIMs behind carrier-grade NAT, the gateway has no public, reachable IP or open inbound port. Firewalls block unsolicited inbound connections too. You reach it via a device-initiated outbound connection, a VPN, or a private APN.
Have the field device start the connection. Outbound-only links - polling out, MQTT, or an HTTPS tunnel to the cloud - pass through NAT and firewalls without any port forwarding, which is why they dominate cellular telemetry.
Not for monitoring. An outbound, device-initiated connection reaches the cloud without a VPN. A VPN or private APN is needed only when you require inbound access to the device itself, such as remote configuration from the head end.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.