Documentation

Appearance

How does Dataplicity work behind NAT, firewalls, and cellular networks? ​

Dataplicity is designed for devices that live on customer, industrial, branch, or mobile networks where inbound connectivity is awkward or unavailable. The device establishes the Dataplicity connection outbound. You do not normally need to expose SSH, add an inbound firewall rule, obtain a public IP address, or configure customer-side port forwarding for routine Dataplicity access.

That is a major difference from building remote support around direct inbound SSH or an application port.

What the network needs to allow ​

A device still needs working outbound network access to the Dataplicity service. The exact endpoints and ports are part of the supported network contract and should be taken from the current firewall requirements, not copied into a long-lived local allow-list from this page.

Before production rollout, test the real deployment network:

  1. DNS resolution works.
  2. The device clock is sufficiently correct for TLS.
  3. Required outbound destinations are reachable.
  4. Proxies, TLS inspection, captive portals, and carrier policy do not break the connection.
  5. The connection survives a device reboot and network interruption.

For fleets using private APNs, tightly controlled enterprise firewalls, or industrial egress allow-lists, treat the firewall requirements as an explicit installation dependency.

What Dataplicity does not require ​

For normal operation, the Dataplicity model does not depend on:

  • a public IPv4 address on the device;
  • inbound SSH from the Internet;
  • router port forwarding;
  • a site-to-site VPN you manage;
  • customer administrators opening an arbitrary high port range;
  • the device being on the same LAN as the engineer using it.

This is why the same operational model works across ordinary broadband, customer LANs, carrier-grade NAT, and many cellular deployments.

What NAT and firewall traversal does not solve ​

Outbound connectivity is not the same thing as guaranteed application connectivity.

Dataplicity cannot make an unavailable network available. If a modem has no signal, the ISP is down, DNS is broken, the device clock prevents TLS, or the customer blocks the required outbound path, the cloud cannot reach through that failure.

Design devices to continue their local product function without a live cloud session. Use offline behaviour as an architecture input rather than treating Internet connectivity as a safety or control dependency.

Cellular networks ​

Cellular is a common fit because inbound addressing is frequently constrained by carrier NAT or private addressing. The outbound Dataplicity connection avoids the need to solve inbound reachability separately for every SIM or carrier.

The usual cellular engineering concerns still apply:

  • signal quality and antenna placement;
  • modem recovery;
  • carrier/APN policy;
  • data allowance;
  • DNS reliability;
  • roaming behaviour;
  • long outages and intermittent links.

Dataplicity reduces the remote-access networking problem. It does not replace cellular network engineering.

Corporate proxies and TLS inspection ​

Do not assume every enterprise proxy or TLS interception product is transparent to a device agent. Validate the supported path on the actual customer network. If a site requires authenticated proxy configuration or a tightly controlled allow-list, include that in deployment qualification before shipping units.

Compare this with a VPN ​

A VPN can be the right answer when the goal is to create general IP reachability between networks or machines. Dataplicity solves a different operational problem: securely connect deployed Linux devices to a managed fleet/support service without requiring you to design and operate the customer-network routing model yourself.

If all you need is arbitrary private-network connectivity, a VPN-oriented tool may be simpler. If the requirement includes device inventory, remote support, fleet operations, product definition, customer tenancy, and customer-facing software, network reachability is only one part of the system.

Production checklist ​

Before approving a network type:

  • install on representative hardware;
  • test through the actual firewall/APN/proxy policy;
  • reboot the device;
  • interrupt the network and confirm reconnection;
  • verify the product continues safely while disconnected;
  • document the required outbound policy for customer IT;
  • include DNS and clock checks in remote diagnostics.