The problem every cellular device has
Nearly every mobile network puts devices behind carrier grade NAT. Thousands of SIMs share one public address, the carrier rewrites every packet on the way out, and anything arriving from the outside is dropped because the carrier has no idea who it's for.
Outbound works perfectly, which is why nobody notices until they need to reach a device. Then port forwarding doesn't exist, dynamic DNS resolves to an address that isn't yours, and the router you can see in your dashboard is unreachable.
If your team already runs Tailscale, the obvious answer is to install Tailscale on the router. It works on hardware that supports it, but it's an agent and a key on every device, it uses the router's CPU, and it doesn't help with the sensor, PLC or camera behind the router that can't run anything.
We wanted the SIMs on the tailnet without touching the devices at all.
What we built
SIMSY runs its own mobile core, so a SIMSY SIM doesn't sit behind a carrier's shared NAT. It lands in a VSlice, a private network that belongs to the customer, with a routing policy the customer controls. From there, SIMSY builds a WireGuard tunnel to a server the customer owns.
On that server, one open source container called tailguard terminates the WireGuard side, joins the tailnet as a tagged node, and advertises the SIM range as a subnet route. Every SIM then has an address any tailnet device can reach.
SIMSY builds the tunnel
Create a WireGuard integration in the SIMSY portal pointing at your server. SIMSY's core dials in. Your server can be a small cloud instance or a Pi in the comms cabinet.
One container joins the tailnet
Tailguard takes a standard wg0.conf and a Tailscale auth key. It registers as a tagged node and advertises the SIM range. Ten lines of compose.
You set the policy
Two rules in the SIMSY routing policy decide whether SIMs can reach the tailnet and whether the tailnet can reach the SIMs. Nothing changes on the device or in Tailscale.
What it looks like from a laptop
The bridge appears in the Tailscale machine list like any other node. The SIMs don't, because they aren't running Tailscale, but their addresses route through the bridge and respond like anything else on the network.
$ tailscale status 100.123.46.35 macbook-pro alex@ macOS 100.105.236.77 simsy-bridge tagged linux $ tailscale ping 10.140.0.20 pong from simsy-bridge via 16.61.94.31:41641 in 18ms $ ping -c 3 10.140.0.20 64 bytes from 10.140.0.20: ttl=60 time=75.1 ms 64 bytes from 10.140.0.20: ttl=60 time=77.4 ms 64 bytes from 10.140.0.20: ttl=60 time=74.9 ms ok $ ssh [email protected] RUT241 login over cellular, through the tailnet
The 75 ms is the cellular radio, not the tunnel. The Tailscale path is direct, 18 ms, and the SIMSY core adds a couple of milliseconds. From the router's side, it can reach every tailnet device the same way, and the tailnet device sees the router's real SIMSY address.
Reachability is a routing rule, not an accident
This is the part that's SIMSY's alone. On a normal SIM, whether a device is reachable is decided by the carrier's NAT and you have no say. On SIMSY it's two lines in the routing policy.
SIMs can reach the tailnet. Devices push telemetry to your cloud, talk to your MQTT broker, pull updates from your build server.
Whether the tailnet can reach the SIMs. Block it and you have uplink only: devices can talk out, nothing can talk in. Flip it when you need to get to a device.
That toggle is the one we'll show in the video. A fleet running uplink only, an engineer needs to SSH to a router, one rule changes in the portal, the SSH session opens, the rule goes back. No firewall on the device, no VPN client, no change in Tailscale.
Versus Tailscale on the router
| Agent on the device | SIMSY bridge | |
|---|---|---|
| Install per device | Yes | No |
| Router has to run Tailscale | Yes | Any router, any vendor |
| Devices behind the router | Need the router as a subnet router too | Already covered by the SIM range |
| Keys to manage | One per device | One per bridge |
| Uplink only control | Firewall rules on every device | One rule in SIMSY |
| Segregating fleets | Tags per device | One bridge per VSlice, tagged |
| CPU cost on the device | Yes | None |
The one gotcha
What's next
Names. Split DNS from the bridge gives every SIM a hostname today, so ssh rut241.sims.simsy works from any tailnet device. Further out, we're looking at registering one lightweight node per SIM so devices show up in the Tailscale app by name, with their own tags and ACLs, generated straight from the SIM list in the SIMSY portal.
The full walkthrough videos and the step by step guide, including the compose file and the wg0.conf, are on the way. Tailguard is by Juho Vähä-Herttua and is worth a star if this saved you a private APN.
Try it with a Launch SIM
Everything in this post runs on a standard SIMSY account. Get a SIM, create a VSlice, and follow the guide.