A SCADA host that expects to poll a remote gateway needs to be able to open a connection to it, but a gateway on a cellular link usually sits behind carrier-grade NAT with no public address of its own, so there is nowhere for an inbound poll to land. NAT traversal is the set of techniques that get around this, letting a central system reach a device that cannot be reached directly. This guide explains why carrier-grade NAT blocks inbound connections, and how outbound-initiated designs and reverse tunnels solve the no-public-IP problem for remote SCADA gateways on cellular links.
NAT traversal in one line: NAT traversal is how a central SCADA system communicates with a remote gateway that has no reachable public IP because it sits behind carrier-grade NAT. Since inbound connections to such a device fail, the standard solutions have the gateway initiate the connection outbound to the host, or maintain a reverse tunnel it opened itself, so data can flow both ways over a path the gateway established. This replaces the traditional model of the host polling inward.
On most cellular data connections the device does not get its own public IP address. Instead the carrier places many subscribers behind carrier-grade NAT, or CGNAT, which shares a pool of public addresses among many devices and translates their private addresses on the way out. This works fine for the device reaching out to the internet, because the NAT remembers each outbound connection and sends the replies back to the right device. But from the outside, the device has no address anyone can dial; there is simply no public IP that maps to that specific gateway for an unsolicited inbound connection.
This directly breaks the traditional SCADA polling model. Classically a central master would open connections outward to each remote terminal unit, poll it for data, and read the response, which assumes the master can reach the remote device at a known address. Behind CGNAT that assumption fails: the master's connection attempt has nowhere to go, because the NAT only forwards traffic that corresponds to a connection the device itself started. An inbound poll to a CGNAT-hidden gateway does not reach it, so a design that relies on the host reaching in simply will not work over such a link.
It is worth separating this from the general topic of getting through firewalls. A firewall might block inbound connections by policy, and there are ways to open or tunnel through it; CGNAT is a different obstacle, because the problem is not a policy decision to block but the absence of any address to reach in the first place. Even with no firewall rule in the way, a device behind CGNAT has no public IP for an inbound connection to target. That is the specific problem NAT traversal for cellular SCADA gateways has to solve.
The clean solution flips the direction of who connects to whom. Because CGNAT happily forwards traffic for connections the device started, the gateway is made to initiate the connection outbound to the central system rather than waiting to be polled. Once that outbound connection is open, it is bidirectional: the gateway sends its telemetry up it, and the central system sends commands and requests back down the same connection. Since the gateway opened it, the NAT keeps the path alive and forwards the replies correctly, so the host can effectively reach the gateway even though it could never have dialled it directly.
A reverse tunnel is the same idea made persistent and general. The gateway establishes and maintains a tunnel outbound to a known, reachable endpoint, and that tunnel then serves as a standing path through which the central system can reach the device at any time. It is called reverse because the connection is set up in the opposite direction from the eventual data request: the device that will be reached is the one that opens the tunnel, precisely because it is the only side that can, given that it is the one behind CGNAT. The endpoint the gateway connects out to must itself be reachable, which is why it typically lives in the cloud or a data centre with a real public address.
There are also hole-punching approaches, where two devices behind NAT coordinate through a helper to open matching outbound connections that meet in the middle, but for the SCADA case the pattern is usually simpler, because one side, the central system, is reachable. The essential move in all of these is the same: the unreachable device reaches out first, and everything else rides on the connection it established. Designing the system around the gateway initiating contact, rather than being contacted, is what makes reliable communication possible over CGNAT cellular links.
Cloud SCADA fits the outbound-initiated model naturally, and that is part of why it works so smoothly over cellular. The platform lives at a reachable cloud endpoint, and each remote gateway connects outward to it and keeps that connection up, sending telemetry and receiving commands over the path it opened. This sidesteps the CGNAT problem entirely, because nothing ever needs to reach inward to the gateway; the device's lack of a public IP is irrelevant when the device is always the one initiating contact. A fleet of gateways behind carrier-grade NAT connects to the platform without any of them needing to be individually addressable from outside.
This design also removes the operational burden that inbound-reach solutions carry. The traditional alternatives to CGNAT, arranging public or fixed IP addresses for each device, or opening inbound paths, are costly, fiddly, and expand the attack surface, because anything reachable from outside is something that can be probed and attacked. An outbound-initiated architecture needs none of that: the gateways expose no inbound surface at all, which is both simpler to run across many sites and inherently more secure, since there is nothing listening for unsolicited connections to be exploited.
For an operator running many remote sites into a platform such as Merobix, this means the no-public-IP reality of cellular connectivity is handled by the architecture rather than fought against. Gateways on ordinary CGNAT cellular links reach out to the platform and stay connected, and the operator does not have to procure special addressing or open inbound paths just to see their sites. The combination of outbound-initiated connections with tight egress controls, such as restricting where the gateway is even allowed to connect, gives a model that is both robust against the CGNAT problem and hard to attack, which is exactly what a fleet of exposed, hard-to-reach field devices needs.
Because a device behind carrier-grade NAT has no public IP address that an inbound connection can target; it shares a pool of addresses with many other devices and is only reachable for traffic that corresponds to a connection it started itself. A host trying to poll inward has nowhere to send its connection, so the traditional model of the master reaching out to each remote device fails over such a link. The device must initiate contact instead.
A reverse tunnel is a connection the remote gateway opens outward to a reachable endpoint and keeps alive, which then serves as a standing path the central system can use to reach the device at any time. It is called reverse because the device that will be reached is the one that establishes the connection, since it is the only side that can when it sits behind carrier-grade NAT. Data flows both ways over the path the gateway created.
Firewall traversal deals with getting past a policy decision to block traffic, whereas NAT traversal for cellular gateways deals with the absence of any public address to reach in the first place. A device behind carrier-grade NAT has no public IP for an inbound connection to target even if no firewall rule is blocking it. The fix is architectural: have the device initiate the connection outbound, so it never needs to be reachable from outside at all.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.