Product
Static public IP SIM: secure remote access to routers, IP cameras and PLCs
Dedicated public IP per SIM, with managed port forwarding and per-source allowlist. Reach the router, IP camera, PLC, or Linux gateway directly from your platform — no device-side VPN, no CGNAT, no need to open the customer's firewall. Rules are API-configurable, with full access audit logs.
Key features
Dedicated public IP per SIM
A public IPv4 permanently assigned to your SIM. It does not change between sessions or when the device re-attaches to a different carrier.
Managed port forwarding
Define which device ports to expose, on which external ports, and from which source IPs they can be reached.
Per-source allowlist
Only IPs you declare may connect. Everything else is dropped silently — no scan possible.
REST API for automation
Create, modify and remove rules from your own platform. Ideal for multi-tenant or large-scale deployments.
Access audit log
Every connection attempt is recorded: timestamp, source IP, port, result (allowed or blocked).
Works with any industrial router
No VPN client or special device-side config required. Validated with Teltonika, Robustel, MikroTik, Cradlepoint and most commercial 4G/5G routers.
Technical specifications
Use cases
- Remote access to industrial routers (Teltonika, Robustel, MikroTik, Cradlepoint)
- Remote management of IP cameras and NVRs (Hikvision, Dahua, Axis)
- Modbus TCP polling of PLCs in solar plants
- SSH maintenance of Linux gateways (Raspberry Pi, IOT2050)
- SNMP monitoring of distributed network equipment
- WAN backup with remote access to the failover router
- SCADA integration with OPC UA over public IP
- Multi-tenant management: each customer gets their SIM, IP, and rules
Routing model
Direct public IP vs. routed public IP vs. private IP via VPN
Not every SIM advertised with a "static IP" solves the same problem. Here is the technical difference:
| Feature | Direct public IP | Routed public IP | Private IP via VPN |
|---|---|---|---|
| How it works | The SIM receives a directly routable public IP. Anyone with the IP can reach the device if it exposes ports. | The SIM holds a private IP on the carrier network. A monitored gateway port-forwards from a dedicated public IP to the device, with a source-IP allowlist. | The SIM holds a private IP inside a private APN. The device opens (or receives) a VPN tunnel — IPsec, WireGuard or OpenVPN — into your infrastructure. |
| Who can reach the device? | Anyone who knows the IP. Defense: firewall on the device itself. | Only IPs in the gateway's allowlist. | Only hosts inside the VPN. |
| Added latency | None (direct access). | Minimal (one extra hop through the gateway, typically <5 ms within Europe). | Variable (5-30 ms depending on VPN concentrator location and overlap with the carrier's path). |
| Device-side configuration | The modem exposes ports. Static-IP-specific APN. | No special configuration on the modem — it benefits automatically from the gateway's port forwarding. | The modem or an upstream gateway must run a VPN client. More maintenance, larger bug surface. |
| Access auditability | Only what the device firewall logs (often nothing). | Central audit log at the gateway: who connected, when, on which port. | Logs at the VPN concentrator; depends on the implementation. |
| Typical use case | Devices in hostile networks where you do not want any intermediate transit (rare outside defense/finance). | Remote access to industrial router, IP camera, PLC, NVR, Linux gateway, managed switch. | When a corporate VPN already exists and the device must join the internal network. |
| Misconfiguration risk | High — the entire Internet can scan the device. | Low — the allowlist is the barrier; if configured correctly, only your IPs get through. | Low on the network, but high if the VPN is compromised (access to the whole internal network). |
| Availability at iot.cards | Yes (SIM with direct public IP). | Yes (SIM with routed public IP — recommended for most cases). | Yes (via private APN — see /products/private-apn). |
Use cases by protocol
Routed public IP is transparent to the device protocol. Examples by real-world use:
| Protocol | Typical devices |
|---|---|
| HTTP / HTTPS (ports 80, 443) | Web UI of Teltonika RUTX/RUT, MikroTik (Webfig), Cradlepoint, Robustel routers; IP camera dashboards. |
| RTSP (port 554) and ONVIF | Hikvision, Dahua, Axis IP cameras. Remote access to streams from a video-surveillance platform. |
| Modbus TCP (port 502) | Siemens S7, Schneider M340, Allen-Bradley Micro800 PLCs. Reading industrial variables remotely. |
| SSH (port 22) | Linux gateways (Raspberry Pi, IOT2050, BeagleBone), MikroTik routers via CLI. |
| SNMP (port 161) | Managed switches and routers, monitoring via Zabbix/PRTG/LibreNMS. |
| OPC UA (port 4840) | SCADA systems, integration with modern industrial platforms. |
Security model
The iot.cards monitored gateway applies an allowlist per SIM or per SIM group. Only the public IPs or CIDR ranges you declare may initiate connections to the device. Every access attempt is logged.
- •Source-IP allowlist, configurable per SIM or per group.
- •Per-port rules: you can allow HTTP but not SSH, for example.
- •Persistent audit log: timestamp, source IP, destination port, result (allowed / blocked).
- •IP rotation without swapping the SIM if a public IP is compromised.
REST API: manage rules dynamically
All port-forwarding and allowlist rules are manageable via REST API. Useful when you provision a new device from your own platform, or when a field technician needs temporary access from a new source IP.
Example: open HTTPS to the device from two CIDR ranges
POST /api/v1/sim/{iccid}/port-forwarding
{
"external_port": 8443,
"internal_port": 443,
"protocol": "tcp",
"allowlist": ["203.0.113.10/32", "198.51.100.0/24"]
}Ready to get started?
Start with a test kit, or tell us about your project.