Run your own tunnels across a SIMSY network.
Plenty of teams already have a way of connecting things and would rather not change it. You do not have to. SIMSY carries whatever tunnelling you already run, and gives you a private place to terminate it inside our mobile core.
Tunnels that terminate inside your network.
A tunnel is only as private as the two ends holding it up. On the public internet, both ends have to sit on public addresses and defend themselves against everything the internet throws at them. SIMSY changes what one of those ends looks like.
No client or agent installed on your devices, just native IP addressing. Devices reach your tunnel endpoint through the SIMSY mobile core, and the endpoint listens on our private network, so it never needs a public address.
Private breakout
Your SIMs never sit on the public internet. Traffic reaches the tunnel endpoint you have chosen through our core, not through anything scannable from outside.
No device agent
The tunnel runs between our core and your infrastructure, not on every device. Locked-down firmware, embedded modules and legacy PLCs are reached without touching them.
No public entry point
The gateway or headend does not have to sit on a public address to be reachable. It listens on our private network, where the only things that can reach it are your own SIMs.
What that changes. The tunnel is still yours. The protocol, the keys, the policy and the tooling are all the ones you already run. What we take off the table is the public exposure, the per-device install and the addressing headaches that usually come with rolling any of this out to a cellular estate.
Keep the VPN you already run.
If you already operate a corporate VPN, IPSec, OpenVPN or something else that predates the current wave, SIMSY carries it. Your devices dial the gateway you already have, and they do it from a network you control rather than from the public internet.
Reach the same gateway
Point the SIMs at the address of the VPN concentrator you already run. Traffic gets there through our private breakout, so the gateway does not need to be reachable from the wider internet just to accept a device.
Fewer things to defend
Because the concentrator no longer needs a public address, the surface area exposed to opportunistic scanning shrinks. You still run the VPN. You just stop advertising it to everyone.
WireGuard runs with addressing you chose.
WireGuard is small, fast and well-behaved on cellular hardware. What usually makes it awkward is the address side of things: NAT traversal, the peer at either end needing to know how to reach the other, and the addressing arithmetic to keep every deployment separate. On SIMSY those problems collapse, because the network the SIMs sit on is one you defined.
Your addressing
SIMs come up on IP ranges you pick, so the WireGuard config on either end refers to addresses that make sense inside your estate rather than whatever the network hands out.
No NAT gymnastics
The headend can live on a private address inside your network. SIMs reach it directly across our core, so there is nothing to punch through and no relay to depend on.
Every SIM is a node on your tailnet.
Tailscale has solved policy, identity and mesh. What it has not solved is cellular. Their own documentation admits the workarounds: a subnet router at every site, overlapping CIDRs between customer deployments, and a client to install on every device that has room for one. SIMSY closes each of those gaps because we operate the mobile core the SIMs attach to.
Add your SIMs to your tailnet. No client on the device, no subnet router at every site, and no local IP clashes because the addressing is ours to assign.
Nothing on the device
The SIM is the tailnet participant. Locked-down firmware, embedded modules and hardware without room for another binary become fully addressable without anything being installed on them.
No subnet router bottleneck
One node per site is what makes Tailscale awkward on cellular. Remove the subnet router pattern and the mesh stays a mesh, all the way down to the device.
No local IP clashes
We assign the addressing, so ranges cannot collide between customer deployments. The problem 4via6 was built to solve does not occur here.
One policy file
Tags, grants and policy tests apply to your SIMs the same way they apply to everything else on your tailnet. Same syntax, same review process, one place to change.
Ready for agents
If a SIM can be a tailnet node, a machine in the field gets the same identity, policy and audit treatment as an agent running in a container. The network becomes the identity layer for both.
Works with what you have
BYO tailnet, BYO tags, BYO grants. Bring Headscale if you self-host. We plug your SIMs in as nodes and step out of the way.
Instead of four products, two things.
A connected estate normally costs you SIMs from one supplier, a connectivity platform to administer them, a remote access tool to reach them, and a device management console on top. Four products, four bills, four consoles.
| Usually | With SIMSY and Tailscale |
|---|---|
| A SIM from a connectivity provider | A SIM |
| A connectivity management platform to administer the fleet | The SIM is a node on your tailnet, so it is administered where everything else is |
| A remote access tool or VPN to reach the devices | The mesh is the access |
| A device management console on top | Your existing tooling, pointed at nodes on your own network |
Try it with the tunnelling you already run.
Get a SIM, add it to whatever mesh, VPN or WireGuard tunnel you already operate, and reach the device the way you would reach anything else on your own network.