Fixed IP for Cellular IoT: How MSPs Can Access Devices Remotely

Remotely accessing a router, camera, kiosk or other device over cellular isn't always as straightforward as accessing equipment on a traditional internet connection. Many cellular connections use carrier-grade NAT (CGNAT), which means the device cannot be reached directly from the public internet by default.

Depending on the deployment, MSPs can solve this with a fixed public IP, private networking or a device-initiated VPN connection. This guide explains how each approach works, when to use it and what to consider before deploying remote access across client sites.

Why cellular devices can be difficult to reach remotely

Cellular connections commonly use carrier-grade NAT, or CGNAT.

With CGNAT, multiple cellular connections can share the same public IP address. The device itself receives a private address, while the cellular network translates its outbound traffic through a shared public address.

Because multiple connections share that public address, unsolicited inbound connections generally cannot be routed directly to an individual device behind CGNAT.

The device can initiate connections outbound, but direct inbound access requires another networking approach.

IP addresses can also change as cellular devices disconnect and reconnect. That creates another challenge when a firewall rule, allow list or remote-access configuration depends on a consistent address.

For an MSP, this can affect tasks such as:

• Remotely managing routers and gateways

• Accessing cameras, kiosks or controllers

• Connecting monitoring systems to remote equipment

• Creating firewall allow lists

• Establishing certain VPN configurations

There are several ways to solve the problem. The right one depends on what needs to communicate with the device, how many devices you're managing and how you want remote access secured.

Option 1: Fixed public IP

A fixed public IP gives a cellular connection a consistent public IP address rather than relying on a changing or shared address.

This gives MSPs a predictable endpoint for deployments that require inbound connectivity, IP allow listing or certain VPN configurations.

What a fixed IP enables

A fixed public IP can provide a consistent address for:

• IP allow lists

• VPN configurations

• Remote monitoring

• Controlled inbound connectivity

• Remote-access workflows

Depending on the router, firewall and device configuration, it can also support inbound connectivity to equipment behind the cellular router.

Benefits of a fixed public IP

Consistent addressing. The address does not change each time the cellular connection reconnects.

Straightforward integration. Existing systems that depend on a known source or destination IP can continue using IP-based rules.

No device-side tunnel required. The endpoint does not necessarily need to establish its own outbound VPN solely to maintain a reachable address.

Considerations

A fixed public IP makes the cellular endpoint consistently addressable from the internet. That means security controls are essential.

Firewall rules should restrict inbound traffic to only what the deployment requires, and remote administration should use encrypted protocols and appropriate authentication.

You should also confirm:

• Whether the provider supplies a public or private fixed IP

• How the IP is provisioned

• Whether inbound traffic is restricted

• Whether specific ports are blocked

• Whether inbound access can be restricted to approved source addresses

• How the fixed IP behaves across the networks available to the SIM

• What additional costs apply

A fixed public IP is useful when a deployment specifically requires a stable, internet-facing address.

A fixed IP provides reachability, not security.

Assigning a fixed public IP makes a cellular endpoint consistently addressable. It does not authenticate users or secure the device by itself. Use firewall rules, encrypted protocols, restricted source addresses and appropriate authentication controls alongside it.

Option 2: Private networking

Not every remotely managed device needs to be directly reachable from the public internet.

Private networking provides a controlled path between cellular devices and the systems that need to communicate with them without requiring those devices to be directly exposed to the public internet.

Depending on the provider and architecture, this can involve private addressing, APN configuration, VPN connectivity or other routing mechanisms.

Because providers use terms such as "private APN" and "private network" differently, ask for a network diagram that shows how traffic moves between the cellular device and your infrastructure.

What private networking enables

Private networking can allow remote devices and centralized systems to communicate using private connectivity rather than public internet-facing addresses.

This can be useful when:

• Many devices communicate with the same centralized infrastructure

• Devices should not be directly exposed to the public internet

• An MSP needs centralized control over routing and access

• The deployment has additional networking or security requirements

Benefits of private networking

Reduced public exposure. Devices do not need individual public IP addresses to communicate with authorized infrastructure.

Centralized architecture. Connectivity between devices and centralized systems can be managed as part of a broader network design.

Useful for larger deployments. A private network can provide a consistent architecture as the number of deployed devices grows.

Considerations

Private networking requires more planning than simply assigning a public IP.

Depending on the implementation, you may need to define:

• Private address ranges

• Routing

• Access controls

• How your infrastructure connects to the private network

• Which systems can communicate with deployed devices

• How the private connection will be monitored

The exact architecture varies by connectivity provider, so understand how the provider's private networking service works before designing around it.

Private networking is useful when devices need controlled connectivity to centralized infrastructure without requiring direct public internet exposure.

Option 3: Device-initiated VPN or secure tunnel

A third approach is to have the router or device initiate an encrypted connection to infrastructure controlled by the MSP, the client or a trusted service provider.

Because the device initiates the connection outbound, this approach can work behind CGNAT without requiring a fixed public IP.

Once the secure connection is established, authorized systems can communicate with the device through the tunnel.

Depending on the hardware and deployment, this could use technologies such as IPsec, OpenVPN or WireGuard, or a vendor's secure remote-management service.

Benefits of a device-initiated VPN

Works behind CGNAT. The device establishes the connection outbound, so direct inbound connectivity from the cellular network is not required.

Reduces direct internet exposure. The device does not need to accept unsolicited inbound connections from the public internet.

Can work across different connection types. The same approach may be used when a site moves between wired and cellular connectivity.

Can reduce dependence on IP addressing. Remote access does not have to depend on the cellular connection retaining a particular public IP.

Considerations

The router or device must support the chosen tunnel or remote-access method.

Your team also needs to consider:

• Who operates the VPN gateway or remote-access service

• How devices are provisioned

• How authentication is handled

• Whether tunnels reconnect automatically

• What happens when connectivity changes

• How tunnel availability is monitored

• What happens if the tunnel itself fails

For critical deployments, consider whether another access path is needed if the primary remote-access method becomes unavailable.

Which remote-access option should you choose?

Start with the requirement rather than the technology.

If the device only needs to send data outbound

Default cellular connectivity may be enough.

A device sending telemetry to a cloud application, for example, may not need inbound access at all.

If you need a consistent public address

Consider a fixed public IP.

This can be useful for IP allow lists, specific VPN configurations and deployments that require a predictable internet-facing endpoint.

If many devices need controlled access to centralized infrastructure

Consider private networking.

This can provide a more centralized architecture without requiring every deployed device to have a publicly reachable IP.

If the device can establish its own secure connection

A device-initiated VPN or secure tunnel may provide the remote access you need without requiring inbound connectivity through the cellular provider.

These approaches are not necessarily mutually exclusive. The right architecture may use different methods across different client deployments.

In general, a fixed public IP is useful when you need a consistent internet-facing address, private networking is useful when devices need controlled connectivity to centralized infrastructure, and a device-initiated VPN can provide remote access without requiring inbound connectivity through the cellular provider.

Security considerations for remote cellular access

Any time you make remote equipment accessible, security should be part of the architecture rather than an afterthought.

This is especially important when using a fixed public IP.

Restrict inbound access

Only allow the connections the deployment actually requires. Where possible, restrict inbound access to known source addresses and disable unnecessary WAN-facing services.

Use encrypted protocols

Use encrypted, authenticated protocols for remote management. Avoid exposing unencrypted administrative protocols directly to the public internet.

Replace default credentials

Use strong, unique credentials and disable default accounts where possible.

Require appropriate authentication

Use multi-factor authentication for management platforms and remote-access tools where supported.

Keep devices updated

Maintain a process for firmware and security updates and document versions across deployed equipment.

Monitor access

Log access attempts and configuration changes where the hardware and management tools allow it.

Monitor data usage

Unexpected increases in cellular traffic can indicate a configuration problem, unusual device behavior or potentially unauthorized activity.

Usage monitoring and limits can help identify changes early.

Remote access setup checklist

Use a consistent process when adding remote cellular access to a new device or client site.

Plan

• Identify which devices require remote access.

• Document why remote access is needed.

• Identify which systems need to initiate the connection.

• Determine whether a consistent public IP is required.

• Decide whether fixed IP, private networking or a device-initiated VPN best fits the requirement.

• Confirm that the hardware supports the chosen approach.

• Confirm the connectivity provider supports the required networking option.

Configure

• Provision the required fixed IP or private networking service.

• Configure routing and firewall rules.

• Restrict inbound traffic where possible.

• Disable unused services and administrative interfaces.

• Configure VPNs or secure tunnels for automatic reconnection where applicable.

• Set strong credentials and appropriate authentication controls.

Test

• Confirm authorized remote access works from outside the client site.

• Reboot the cellular device and verify that access returns without manual intervention.

• Test VPN or tunnel reconnection if applicable.

• If cellular is being used for failover, simulate a primary connection outage and confirm the remote-access method behaves as expected.

• Review data usage to understand the overhead created by monitoring, keepalives and remote management.

Document and monitor

• Record the device, SIM and remote-access method.

• Document IP addresses, network configurations and relevant access rules.

• Record why the selected architecture was chosen.

• Configure appropriate connectivity and usage alerts.

• Schedule recurring testing for critical deployments.

Set up remote access for your cellular deployments

Simbase gives MSPs multiple ways to build cellular connectivity around the networking requirements of their client deployments.

Add a fixed public IP when a device needs a consistent internet-facing address, or use private networking when devices need controlled connectivity to your infrastructure without direct public exposure.

Manage cellular connectivity through the Simbase platform and use the API to automate connectivity management as deployments grow.

Need help choosing the right setup?

Talk to an IoT expert from our team about the networking requirements for your deployment.