A VPN (Virtual Private Network) creates an encrypted tunnel between two endpoints. For IoT, the typical use is to give a cellular device a secure path back to your servers or your corporate network, as if the device were plugged into your office, even though it's actually connected over a public mobile network on the other side of the world.
This article covers what an IoT VPN is, when it adds value, and what Simbase supports. For setup, see the per-protocol guides under Private Networks.
What an IoT VPN does
A VPN tunnel between a cellular device and a remote endpoint gives you:
Encryption in transit. Traffic inside the tunnel is unreadable to anyone in the network path.
Authentication. Both ends prove their identity before the tunnel comes up. Devices without valid credentials can't establish the tunnel.
Logical network membership. Once the tunnel is up, the device looks like it's on the remote network. It can reach internal resources by their internal addresses.
Routing control. You decide which traffic goes through the tunnel and which goes direct to the internet.
A VPN doesn't replace TLS for application-level encryption. It's a transport layer below it. Most IoT designs use TLS regardless, and a VPN is added on top when there's a specific reason to.
When a VPN is worth it for IoT
A VPN adds operational complexity and CPU load on the device. Pick it when one of these applies:
You need to expose internal services to devices. Devices need to reach a database, AD/LDAP, an internal MQTT broker, or another resource that lives inside your corporate network. A VPN brings the device onto that network.
Compliance requires encrypted transport beyond TLS. Some regulated industries (healthcare, government, defence) require all traffic between sensitive endpoints to traverse an encrypted tunnel, regardless of application-level encryption.
You're bridging into a customer or partner network. Many B2B IoT deployments terminate the SIM's traffic into the customer's VPN, so the customer's IT team controls the routing and policy.
You're consolidating to one publishing endpoint. A central VPN endpoint can be useful when many devices need to reach a single internal service that you don't want to expose publicly.
You want a fixed source IP for the device's traffic. A VPN concentrator can present all device traffic with one source IP, making allowlisting easier on partner systems.
When a VPN is not the right answer
You only need encryption. TLS handles this for HTTPS, MQTTS, and any other modern application protocol.
The device only talks to public APIs. A VPN adds nothing.
You need inbound reachability for a single device. A Public IP is simpler than a VPN.
You're trying to mask the device's location. Cellular operators always know where the device is, and a VPN doesn't change that.
What Simbase supports
Simbase supports two site-to-site VPN protocols, configured at the network gateway level:
| Protocol | Best for | Setup guide |
|---|---|---|
IPsec | Production deployments needing remote access and bidirectional communication | |
WireGuard | Occasional access to devices, prototyping, and smaller deployments |
IPsec
WireGuard
Both are configured once at the Simbase end. Your fleet's traffic routes through the tunnel without any per-device configuration, which is operationally much simpler than provisioning a VPN client on every device.
Use IPsec when devices need to be reachable from your network on an ongoing basis, when traffic flows in both directions, or when you're integrating with VPN appliances your IT team already runs (Cisco ASA, Palo Alto, Fortinet, and similar). It's the standard choice for production.
Use WireGuard when you need to reach devices occasionally rather than continuously, for maintenance, diagnostics, or pulling logs. It's quicker to stand up and easier to troubleshoot, which also makes it a good fit for prototyping.
VPN on the device vs VPN at the network
There are two different ways to put devices "on a VPN":
| Approach | What | When |
|---|---|---|
Network-level (Simbase site-to-site) | The Simbase gateway terminates the VPN to your network. Devices send traffic normally; routing happens upstream. | Most IoT fleets. Simpler ops, no per-device cert management, works with any device. |
Device-level (client on device) | Each device runs its own VPN client (OpenVPN, WireGuard, and so on). | When devices need to reach networks Simbase isn't tunnelled to, when individual device authentication matters, or when you can't use Simbase's site-to-site. |
Network-level (Simbase site-to-site)
Device-level (client on device)
Common questions
Not for confidentiality alone, TLS already protects the data in transit. Add a VPN when you need to bridge networks, satisfy a specific compliance requirement, or route all device traffic through one source IP.
No. Simbase terminates the tunnel at the network gateway, so devices send traffic normally and routing happens upstream. You'd only run a client on the device itself if you need to reach a network Simbase isn't tunnelled to, or if each device needs its own identity.
IPsec for production deployments where devices need ongoing remote access and bidirectional communication, particularly if your IT team already runs IPsec appliances. WireGuard for occasional access, maintenance, diagnostics, or prototyping.
Some. Encryption adds per-packet overhead and routing through a tunnel adds latency compared with going direct to the internet. For most IoT traffic patterns the impact is negligible, but it's worth accounting for on high-throughput or latency-sensitive deployments.
Related
Private Networks, WireGuard setup
Private Networks, IPsec setup
Public IPs, for inbound reachability without a VPN
APN (private APN), for an even tighter network integration
© 2026 Simbase Connect. All rights reserved.