A device can be perfectly configured on its local network and still be unable to reach anything beyond it, because reaching the wider world depends on one more setting: the default gateway. The default gateway is the router address a device sends packets to when the destination is not on its own subnet. This guide explains what the default gateway does, why a PLC with a missing or wrong gateway can still ping its local neighbors yet never reach a cloud SCADA server, and how the gateway fits with the cellular router at a remote pad.
Default Gateway in a SCADA Network in one line: The default gateway is the IP address of the router a device uses to reach any destination that is not on its local subnet. When a device needs to send to an off-subnet address, it forwards the packet to its default gateway, which routes it onward. A device with no gateway, or the wrong one, can still communicate with other devices on its own subnet but cannot reach anything beyond it - so a PLC can ping local neighbors while being completely unable to reach a cloud SCADA server.
Every packet a device sends starts with a question the device answers using its subnet mask: is the destination on my local subnet or not? If the destination is local, the device delivers the packet directly on the local network and the gateway is not involved at all. If the destination is off-subnet - anywhere the network portion does not match - the device cannot deliver it directly and instead sends it to its default gateway, trusting that router to know how to forward it onward toward the destination.
The default gateway is therefore the device's exit from its local network. It is configured as a single IP address, and that address must itself be on the device's own subnet, because the device has to be able to reach the gateway directly to hand off traffic. A gateway address in a different subnet from the device is a contradiction the device cannot resolve - it would need the gateway to reach the gateway. This is a frequent misconfiguration: an address typed with the wrong subnet portion is unreachable and so the gateway is effectively absent even though a value is filled in.
Because the gateway handles everything not local, one wrong gateway setting breaks all external communication at once while leaving local communication untouched. This selective failure is what makes gateway problems confusing to diagnose. Local tests succeed, giving the impression the device is fine, while every attempt to reach something beyond the subnet fails silently - the packets are either sent to a gateway that cannot forward them or, with no gateway set, simply have nowhere to go the moment their destination is off-subnet.
The classic symptom of a gateway problem is a device that passes every local test but cannot reach anything remote. A PLC with a correct address and mask but a missing or wrong default gateway will happily ping other devices on its subnet - the SCADA gateway on the same network, a neighboring RTU, the local switch - because none of that traffic ever needs the gateway. Everything local works, so a quick check suggests the network is healthy.
The failure appears only when the PLC tries to reach an off-subnet destination, such as a cloud SCADA server across the internet. That traffic must go through the default gateway, and if the gateway is missing the PLC has no route off its subnet, while if the gateway is wrong the packets are handed to a router that cannot forward them or has no return path. Either way the connection to the cloud never completes, even though the PLC is powered, addressed, and passing local pings. The device looks fine and is unreachable at the same time.
This is why the default gateway should be one of the first settings checked when a field device connects locally but will not reach a remote host. It is easy to overlook precisely because local connectivity - the thing a tech naturally tests first - is entirely independent of the gateway. A device can be commissioned, its local links verified, and everyone can assume it is done, only for the data to never arrive at the cloud because the one setting governing off-subnet traffic was left blank or filled in wrong.
At a remote pad, the default gateway usually points at the on-site router that provides the path off the pad - very often a cellular router that carries the site's data over a mobile network. The PLCs, RTUs, and other field devices at the pad share a local subnet, and the cellular router sits on that same subnet with its own address. Each field device's default gateway is set to that router's address, so any traffic bound for the cloud SCADA is handed to the router, which then forwards it out over the cellular link. The gateway is, in effect, the field device's on-ramp to the wider network.
This makes the gateway setting the linchpin of remote connectivity. If a field device's default gateway does not match the cellular router's local address, that device's data can never leave the pad, no matter how healthy the cellular link itself is. The router can have a strong signal and a working connection, and the device can be talking fine to its neighbors, yet nothing reaches the cloud because the device is not pointing its off-subnet traffic at the router. The link and the gateway are two separate things that both have to be right.
For a cloud SCADA such as Merobix, the reliable pattern at a remote site is straightforward: every field device shares the pad's local subnet, the cellular or edge router sits on that subnet, and each device's default gateway is that router. With that in place, a device's data flows to the router and onward to Merobix. Because a wrong gateway fails silently for external traffic while local links keep working, confirming the gateway matches the router is part of commissioning any remote pad - it is the difference between a site whose devices are merely wired and a site whose devices actually reach the cloud.
Because local traffic never uses the default gateway, while off-subnet traffic depends on it entirely. A PLC with the wrong or missing gateway can still ping neighbors on its own subnet, so local tests pass, but any packet bound for an off-subnet destination like a cloud server has no valid route. The device looks healthy locally yet cannot reach anything beyond its subnet.
Yes. A device must be able to reach its gateway directly to hand off off-subnet traffic, so the gateway address has to fall within the device's local subnet. A gateway set to an address in a different subnet is unreachable, which makes it effectively absent even though a value is entered. This is a common misconfiguration that quietly blocks all external communication.
It is normally the local address of the cellular router itself. The field devices share the pad's subnet with the router, and each device's default gateway points at the router so their off-subnet traffic is forwarded out over the cellular link to the cloud. If the gateway does not match the router's address, the device's data cannot leave the pad even when the cellular link is working fine.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.