A Teltonika RMS alternative: the 4G router keeps the link, the agent takes over access

What Teltonika does very well

The model, described at a high level: cellular routers and gateways (the RUT range and its siblings) installed on sites, a cloud platform (RMS) that manages the fleet — configuration, updates, monitoring —, and a remote-access service (RMS Connect) that opens sessions to the equipment behind the routers, often from the browser. The whole is coherent: the network hardware and its management come from the same vendor.

Two roles to separate: the Internet link and remote access

A 4G router provides two very different services when it is also given remote maintenance: it carries the site's packets (its trade), and it decides who gets in and to what (a security trade). Merging the two into the router + cloud pair has consequences worth weighing:

• Access is coupled to the network hardware. Remote-access rights live in the platform that manages the routers: changing routers, product lines or vendors also means moving your access model.
• Sessions go through the vendor’s cloud. Brokering — and carrying the session — are operated by the platform. Convenient, but access to your machines depends on an external service, and trust rests on it.
• Access happens service by service. You open a session to a declared device and service — fine for one-off troubleshooting, narrower than a real local network when vendor tools want to discover their equipment or push real-time flows.

The VIGIL-MESH approach: a private network over any link

VIGIL-MESH does not touch the Internet link: the agent installs on the site's machines — the supervision PC, the IPC, a Linux gateway, a Jetson — and brings them into your private network. Every machine only establishes outbound connections, on a single 443 UDP flow: behind a 4G router under CGNAT, that is exactly the traffic that passes with zero configuration. Sessions are encrypted end to end (QUIC/TLS 1.3, hybrid post-quantum key exchange); the path is direct peer-to-peer when NAT traversal succeeds, relayed by a structurally blind vigie otherwise.

123

1. 1The machine name, as it appears in the network inventory.
2. 2Its overlay address: this is what the terminal reaches, never a public address.
3. 3“Terminal” opens an SSH session encrypted end to end — the tab becomes a mesh node.

Qualitative comparison

This table compares the remote-access role of the two models, at a high level — not datasheets. The router's Internet-link role is not in question: it keeps it.

The duo that works: RUT router for 4G, agent for access

In the field, the combination is natural: the cellular router provides the site's Internet link — coverage, SIM failover, link monitoring through RMS if you wish — and the VIGIL-MESH agent, installed on the gateway or the machines behind it, builds the private network. The agent asks nothing of the router: no inbound port, no forwarding, no DMZ — only outbound 443 UDP traffic, which every cellular router passes by default.

The problemThe solution, step by step

A remote site — station, construction site, cabinet, delivered machine — is connected over 4G. You need to work on it remotely, regularly, with several people:

• The 4G link is under CGNAT: nothing can be exposed inbound, and that is fine.
• Remote access through the router's cloud works, but every session depends on an external service — and internal policy increasingly demands that nobody can technically see the sessions.
• Rights live at the router and platform level, not at the level of people and machines: hard to write “this contractor reaches only this PLC, on this port”.
• Business tools — supervision, vendor discovery, video or real-time UDP flows — want a network, not a per-service session.

For the full picture of the use case — machine fleets, contractors, network zones — see Industrial remote maintenance.

Frequently asked questions