Remote Access to Industrial Devices via ZeroTier & Teltonika RUT955

One of the more interesting networking challenges I tackled at work was setting up secure remote access to an industrial measurement device deployed in the field. The goal was simple: be able to open a remote access application on my laptop, type in the device's IP address, and connect — no matter where I was. The execution, however, required navigating several layers of networking, routing, and firewall configuration.

The Problem

We had an industrial device installed at a remote site, connected to a Teltonika RUT955 industrial router via LAN. The RUT955 was running on mobile/SIM data — no fixed broadband, no public static IP. I needed to access the device from my laptop as if I were sitting right next to it on the local network.

The challenge was clear: the target device sat behind a cellular NAT with no direct inbound connectivity, and it had no ability to run VPN software itself. Everything had to be routed through the RUT955.

The Network Architecture

I designed a solution using three key components:

• ZeroTier — a peer-to-peer software-defined network (SDN) that creates a virtual Layer 2 ethernet network over the internet
• Teltonika RUT955 — an industrial 4G router acting as the bridge between the ZeroTier virtual network and the local LAN
• Remote Access Software — the application used to remotely manage and interact with the target device

The final network topology looked like this:

The laptop and the RUT955 both joined the same ZeroTier network, creating a direct encrypted tunnel between them over the internet — even through the cellular NAT. The target device, which couldn't run ZeroTier, remained on the RUT955's local LAN.

The Core Logic: How Traffic Flows

Understanding the packet flow is essential to understanding why each configuration decision was made. Here's exactly what happens when I type the target device's IP into the remote access application on my laptop:

1. Laptop checks its routing table. It sees a managed route that says: "To reach the LAN subnet, send traffic via the RUT955's ZeroTier IP." This route was pushed by ZeroTier Central and accepted by the laptop's ZeroTier client because allowManaged was enabled.
2. Laptop encapsulates the packet and sends it through the ZeroTier virtual interface to the RUT955's ZeroTier IP.
3. RUT955 receives the packet on its ZeroTier interface. Because ip_forward is enabled and the firewall allows forwarding from the zerotier zone to the lan zone, the RUT955 forwards the packet to its LAN interface.
4. The packet arrives at the target device. The device processes the request and sends a response back to its default gateway — which is the RUT955.
5. RUT955 routes the response back through the ZeroTier tunnel to my laptop. Because masquerading is enabled on the ZeroTier zone, the return path works seamlessly.

This entire round trip happens in roughly 40–50ms over a 4G cellular connection — fast enough for real-time device management.

The Challenges I Faced

1. ZeroTier Managed Routes Not Being Accepted

This was the biggest issue and took the longest to diagnose. I had correctly configured the managed route in ZeroTier Central. The firewall on the RUT955 was properly configured with zone forwarding from zerotier → lan. IP forwarding was enabled. Everything looked correct on paper.

The problem turned out to be on the ZeroTier client running on the RUT955. By default, the ZeroTier daemon was running with allowManaged and allowGlobal set to false. This meant the RUT955's ZeroTier client was silently ignoring the managed routes pushed from ZeroTier Central. The device was connected to the ZeroTier network and could communicate with other ZeroTier members, but it refused to act as a gateway for LAN traffic.

The fix required SSH access to the RUT955 to configure the ZeroTier client directly:

zerotier-cli set [network-id] allowManaged=1
zerotier-cli set [network-id] allowGlobal=1

This is not configurable through ZeroTier Central — it's a local client-side setting that determines whether the device trusts and applies routes from the network controller.

2. ZeroTier Service Port Conflict

While troubleshooting, the ZeroTier CLI kept returning "connection refused." Checking the system logs revealed the issue:

daemon.err zerotier-one: fatal error: cannot bind to local control interface port 9994

A duplicate ZeroTier process was holding the control port. The fix involved killing all ZeroTier processes, ensuring port 9994 was free, and performing a clean restart of the service. This is a common issue on embedded devices where the init system may not cleanly handle service restarts.

3. The Target Device Cannot Run ZeroTier

A simpler solution would have been to install ZeroTier directly on the target device, giving it its own ZeroTier IP. However, the device's firmware doesn't support third-party software installation. This constraint is what made the RUT955 gateway approach necessary — the router had to act as a bridge between two fundamentally different network layers.

4. Cellular NAT and No Public IP

The RUT955 connects to the internet via a SIM card on a mobile carrier. This means it sits behind carrier-grade NAT (CGNAT) with no public IP address. Traditional VPN solutions like port forwarding or setting up an OpenVPN server on the RUT955 wouldn't work because there's no way for inbound connections to reach it.

ZeroTier solves this elegantly through NAT traversal — both devices initiate outbound connections to ZeroTier's root servers, which then facilitate direct peer-to-peer connectivity through the NAT using UDP hole punching.

Configuration Decisions Explained

Why ZeroTier Over Traditional VPN?

I evaluated several options before choosing ZeroTier:

• OpenVPN / WireGuard on RUT955: The RUT955 supports both, but they require a server with a public IP. Since the RUT955 is behind cellular CGNAT, it can only act as a client. This would require maintaining a separate VPN server, adding cost and complexity.
• Teltonika RMS (Remote Management System): Teltonika's own cloud platform can provide remote access, but it's a paid subscription service and adds dependency on their infrastructure.
• ZeroTier: Free for up to 25 devices, works through NAT without a public IP, and provides Layer 2 connectivity — meaning the target device appears as if it's on the same local network as my laptop.

Why Masquerading on the ZeroTier Zone?

Masquerading (SNAT) on the RUT955's ZeroTier firewall zone ensures that when packets from my laptop reach the target device, the source address is translated to the RUT955's LAN IP. This is important because the target device doesn't know about the ZeroTier network — it only knows how to send packets to its default gateway. Without masquerading, the device would receive packets from my laptop's ZeroTier IP and wouldn't know how to route the response back.

Why Enable Both allowManaged and allowGlobal?

allowManaged tells the ZeroTier client to accept routes within the ZeroTier network's defined address space. allowGlobal extends this to routes that fall outside the standard ZeroTier-assigned range. Since the LAN subnet is separate from the ZeroTier network's subnet, enabling allowGlobal ensures the route is accepted and applied to the system routing table.

Final Result

After resolving all the configuration issues, the setup works reliably. From my laptop — anywhere in the world with an internet connection — I can open the remote access application, enter the target device's IP address, and connect directly as though I'm on the same local network. The connection runs over an encrypted ZeroTier tunnel through a 4G cellular link, with round-trip latency averaging around 45ms.

The entire solution uses free, open-source software (ZeroTier) running on hardware we already had deployed, with no ongoing subscription costs and no additional infrastructure to maintain.

Key Takeaways

• ZeroTier's managed routes require client-side opt-in. Configuring routes in ZeroTier Central isn't enough — each device must have allowManaged and allowGlobal enabled locally.
• The RUT955 makes an excellent ZeroTier gateway. Its support for ZeroTier, combined with flexible firewall zone configuration, makes it ideal for bridging virtual networks to local LANs.
• Layer 2 VPNs simplify remote access to legacy devices. When a device can't run VPN software, routing through a gateway is the cleanest solution — and ZeroTier's Layer 2 approach makes the target device appear truly local.
• Always check the logs. The "connection refused" error that led to discovering the port 9994 conflict would have been impossible to diagnose without logread.