Ping Reboot on Private IP SIM Cards: What You Need to Know

Ping reboot is one of the most important reliability features on any cellular router. It works by periodically pinging a remote IP address to confirm the data connection is alive — and if the ping fails a set number of times, the router automatically reboots itself to re-establish connectivity.

It’s a simple, elegant failsafe. But it relies on one critical assumption: that there’s a reachable IP address to ping.

For routers on private APN / private IP SIM deployments — which are increasingly common in professional IoT — that assumption breaks down completely. And if you don’t understand why, you could end up with a router that either never reboots when it should, or reboots in an endless loop when it shouldn’t.

This guide explains how private IP SIM deployments work, why they create a ping reboot challenge, and exactly how to solve it.

---

The Critical Warning: Do Not Enable Ping Reboot Using Default Settings

Before we go any further, here’s the single most important point in this entire article:

If your router is using a private IP SIM card, do not simply enable ping reboot and leave the default settings in place.

The default ping reboot configuration on most cellular routers — including Teltonika, Cradlepoint, Digi, and others — is pre-configured to ping a public IP address like 8.8.8.8 (Google DNS) or 1.1.1.1 (Cloudflare DNS). This makes perfect sense for routers with normal internet-connected SIMs, because these addresses are always reachable and highly reliable.

But on a private IP SIM — where the device has no route to the public internet — those addresses are unreachable by design. The router will ping, get no response, ping again, get no response, and after the configured number of failures, conclude the connection is broken and reboot itself. When it comes back up, exactly the same thing happens. And again. And again.

The result is a router trapped in an endless reboot loop — not because anything is wrong with the connection, but because the ping reboot feature is trying to reach an address that the network architecture deliberately prevents it from reaching.

This is not a subtle misconfiguration. It will take the device completely offline. If you’re deploying a fleet of routers and push the same default ping reboot configuration across all of them, you will take your entire fleet offline simultaneously. Every device will be cycling through reboot after reboot, unavailable for the applications they’re supposed to be serving, and in many cases requiring a physical site visit to each location to correct the configuration.

The fix is not to disable ping reboot — it’s too valuable a reliability tool for that. The fix is to configure it correctly for a private network environment, which means pointing it at an IP address that actually exists within your closed network and will respond to ICMP ping. We’ll cover exactly how to do this below.

---

What Is a Private IP IoT SIM Deployment?

In a standard mobile broadband setup, when a SIM card registers on the cellular network and establishes a data session, the device is assigned a public IP address (or more commonly now, a CGNAT address) and gains access to the open internet. Traffic flows from the device, through the mobile operator’s core network, out through their internet gateway, and onto the public internet.

A private IP deployment works differently. Instead of routing traffic out to the public internet, the mobile operator keeps the traffic entirely within a closed network. The SIM card is assigned a private IP address — typically from the 10.x.x.x or 172.16.x.x ranges — and traffic is routed through a private APN (Access Point Name) directly into the customer’s own infrastructure via a VPN, MPLS link, or private interconnect.

Think of it as a sealed tunnel: the SIM connects to the mobile network, the mobile network connects to your corporate network, and at no point does the traffic ever touch the public internet.

How the Architecture Typically Works

1. The SIM authenticates on the cellular network as normal (attaching to a base station, authenticating on the core network).
2. A PDP context / PDN connection is established using a private APN configured specifically for that customer or deployment.
3. The device is assigned a private IP from a pool managed by the operator or MVNO.
4. Traffic is routed through the mobile core directly into the customer’s network via an IPsec VPN, private interconnect, or MPLS circuit — bypassing the internet entirely.
5. The device can communicate with other endpoints on the same private network (other SIM-equipped devices, head-end servers, SCADA systems, etc.) but cannot reach the public internet.

This is sometimes referred to as a closed network, private APN, or walled garden deployment. IoT connectivity providers such as Wireless Logic, Eseye, Pangea, and others all offer variants of this architecture.

---

Why Private IP SIMs Are So Popular in IoT

Private IP deployments have become the default for serious IoT and M2M projects, and for good reason. The security benefits are significant — particularly in sectors like energy, utilities, water, building management, and industrial automation where the devices being connected are part of critical infrastructure.

No Internet Exposure

The most fundamental benefit is that devices on a private APN are simply not visible from the public internet. There is no public IP address to scan, no port to probe, and no route from the internet to the device. This eliminates an entire category of attack vectors — port scanning, brute force attacks on management interfaces, exploitation of firmware vulnerabilities — because the device is unreachable from the outside world.

For a SCADA controller managing a water treatment works, or a BMS controller in a commercial building, or a power monitoring unit at an electrical substation, this is not a theoretical concern. These are real assets that are genuinely targeted, and removing them from the internet entirely is a major security win.

Reduced Attack Surface

Even if a cellular router has strong security features — firewalls, password policies, encrypted management — every internet-facing device is a potential target. Private IP deployments reduce the attack surface to near zero for external threats. The only way to reach the device is from within the private network itself, which is inherently a much more controlled environment.

Regulatory and Compliance Alignment

Many industries — energy, utilities, healthcare, government — have regulatory requirements around network segmentation and data protection. Private APN deployments align naturally with these requirements because the data path is controlled end-to-end, there is no exposure to the public internet, and the traffic can be audited and monitored within the corporate network infrastructure.

Deterministic Routing

In a private deployment, you know exactly where traffic is going. There are no unexpected routes, no reliance on third-party DNS servers, and no risk of traffic being intercepted in transit across the internet. For industrial control systems where predictability and reliability are paramount, this matters.

---

The Ping Reboot Problem

Here’s where it gets interesting — and where many deployments run into trouble.

How Ping Reboot Normally Works

On a cellular router like a Teltonika RUT series or RUTX series device, the ping reboot function (sometimes called “Ping Reboot” or found under System > Auto Reboot > Ping/Wget Reboot) works like this:

• The router periodically sends an ICMP ping to a configured IP address — commonly 8.8.8.8 (Google DNS) or 1.1.1.1 (Cloudflare DNS).
• If the ping succeeds, the router knows its data connection is working.
• If the ping fails a configured number of times in a row, the router assumes the data connection has dropped and triggers a reboot to force a fresh connection.

This is an essential reliability mechanism for unattended remote devices. Cellular connections can stall for many reasons — network congestion, tower handover failures, PDP context drops, firmware quirks — and without ping reboot, a device can sit in a state where it appears connected but cannot actually pass traffic. In a remote, unattended deployment, this means a site visit to power-cycle the router, which is expensive, time-consuming, and defeats the purpose of remote connectivity.

Why 8.8.8.8 Doesn’t Work on Private IP SIMs

If your SIM card is on a private APN with no internet breakout, the router cannot reach 8.8.8.8, 1.1.1.1, or any other public IP address. The traffic has nowhere to go — the private APN doesn’t route to the internet.

This means:

• Every ping will fail — not because the connection is down, but because the destination is unreachable by design.
• The router will interpret this as a connection failure and reboot itself.
• After rebooting, the same thing happens — the ping fails again because the destination is still unreachable.
• The router enters a reboot loop, cycling endlessly, achieving nothing, and making the device unavailable for the very applications it’s supposed to be serving.

This is not a rare edge case. It is one of the most common configuration mistakes in private APN deployments, and it can take down an entire fleet of devices if the same default ping reboot configuration is pushed out across all routers.

---

The Solution: Getting a Pingable IP from Your SIM Provider

The fix is straightforward in principle: you need an IP address that sits within the private network and will reliably respond to ICMP ping requests.

Since your traffic never leaves the mobile operator’s infrastructure (or the private interconnect into your network), the IP address you ping must be one that exists within that closed ecosystem.

What to Ask Your SIM Provider

Contact your IoT connectivity provider and ask specifically:

“We are using ping reboot on our cellular routers as a connectivity watchdog. Our SIMs are on a private APN with no internet breakout. Can you provide us with an IP address within the private network infrastructure that will respond to ICMP ping and that we can use as our ping reboot target?”

Most established IoT connectivity providers will have a solution for this. Common options include:

1. The APN Gateway Address The gateway IP assigned during the PDP/PDN session is often pingable. This is the first hop from the device into the operator’s infrastructure. On the router, you can usually find this under the mobile interface status page. However — and this is important — not all operators allow ICMP to the gateway, so you must confirm this with your provider rather than assuming.

2. A Dedicated Monitoring IP Some providers maintain a specific IP address within their infrastructure that is designed to respond to pings from devices on private APNs. This is the ideal solution because it is purpose-built and supported.

3. A Server on Your Private Network If the private APN routes into your own corporate network, you can ping any server or device on your side of the network that you control and that will respond to ICMP. This could be your head-end server, a monitoring platform, or even a dedicated lightweight VM whose sole purpose is to respond to pings from your field devices.

4. The IP of Another Device on the Same APN In some architectures, devices on the same private APN can communicate with each other. If you have a known, permanently-online device (such as a server or gateway) on the same APN, its IP could be used as a ping target. This is less common and depends on the network architecture.

Important Considerations When Choosing a Ping Target

• Reliability: The IP you choose must be highly available. If it goes down for maintenance, every router configured to ping it will reboot. Choose something resilient.
• ICMP Must Be Allowed: Some network elements block ICMP by default. Confirm explicitly that the target will respond to ping.
• Latency: The ping target should respond quickly enough that the router doesn’t interpret normal network latency as a failure. Targets within the mobile core or the first hop of your private interconnect are ideal.
• Single Point of Failure: Consider what happens if the ping target becomes unreachable for legitimate reasons (maintenance, routing change). If possible, some routers allow you to configure multiple ping targets — use this feature if available.

---

Beyond Ping Reboot: Other Implications of Private IP Deployments

The inability to reach the public internet on a private APN doesn’t just affect ping reboot. There are several other important considerations.

Remote Management Platforms (e.g., Teltonika RMS)

Cloud-based remote management platforms like Teltonika RMS (Remote Management System) require the router to establish an outbound connection to a cloud server over the internet. On a private APN with no internet breakout, the router simply cannot reach the RMS servers.

This means:

• You cannot remotely configure, monitor, or troubleshoot routers via RMS.
• You cannot push firmware updates remotely through RMS.
• You lose the ability to view real-time status, signal strength, data usage, and diagnostics.

For many deployments, this is a significant operational limitation. RMS and similar platforms (such as Cradlepoint NCM, Digi Remote Manager, or Sierra Wireless AirVantage) are core tools for managing large fleets of routers, and losing access to them fundamentally changes how you manage your deployment.

Options for Remote Management on Private APNs

There are several approaches to restoring remote management capability while maintaining the security benefits of a private network:

Option 1: Split Tunnel / Selective Internet Breakout Some connectivity providers can configure a split tunnel where specific traffic (such as traffic destined for the RMS platform) is allowed to break out to the internet while all other traffic remains within the private network. This is sometimes implemented as a firewall rule on the APN allowing outbound connections to specific IP addresses or domains only. You retain the security benefits for your operational traffic while allowing management traffic to reach the cloud.

Ask your provider: “Can you configure selective internet breakout for specific destination IPs/domains on our private APN?”

Option 2: VPN-Based Management If your private APN routes into your corporate network, you can set up a VPN server on your side that the routers connect to, and then access router management interfaces through the VPN. Teltonika routers support OpenVPN, IPsec, WireGuard, and other VPN protocols that can be configured for this purpose. Your management traffic stays within the private network — you’re simply accessing the router’s web interface (or SSH/CLI) through a network path that doesn’t require internet access.

Option 3: Self-Hosted Management Platform Instead of relying on a cloud-based platform like RMS, you can deploy a self-hosted management solution within your private network. Options include open-source NMS platforms, TR-069/CWMP servers, or custom solutions built around SSH and API access. This gives you full fleet management without any internet dependency — but it requires more infrastructure and expertise to set up and maintain.

Option 4: Dual-SIM Architecture Some advanced deployments use a dual-SIM approach: one SIM on a private APN for operational data, and a second SIM on a standard APN with internet access for management traffic. Routers like the Teltonika RUTX series support dual SIM with policy-based routing, allowing you to direct management traffic through the internet-connected SIM while keeping operational traffic on the private APN. This adds cost (two SIMs per device) but gives you the best of both worlds.

NTP (Network Time Protocol)

Routers typically synchronise their clocks using public NTP servers on the internet. On a private APN, this won’t work. Without accurate time, logging becomes unreliable, certificate validation can fail, and scheduled tasks may not execute correctly. You’ll need to either configure a local NTP server on your private network or ask your provider if they offer an NTP service within the APN infrastructure.

DNS Resolution

If any application on the router requires DNS resolution (even just for logging or diagnostic tools), the default public DNS servers won’t be reachable. Ensure your private APN has internal DNS configured, or set the router’s DNS to point to a server on your private network.

Firmware Updates

Without internet access, you cannot download firmware updates from the manufacturer’s servers. Updates will need to be pushed through your private network management infrastructure, carried out on-site, or facilitated through a selective breakout if configured.

---

Configuration Walkthrough: Setting Up Ping Reboot Correctly on a Private APN

Here’s a practical step-by-step for configuring ping reboot on a Teltonika router deployed on a private IP SIM. The principles apply equally to other router brands.

Step 1: Confirm Your Network Architecture

Before configuring anything, confirm with your SIM provider:

• The APN name and credentials for the private APN.
• Whether the deployment is fully closed (no internet) or has selective breakout.
• A recommended ICMP-responsive IP address within the private network.
• Whether the gateway IP responds to ping.

Step 2: Verify Connectivity

Once the router is online with the private SIM:

• SSH into the router or access via the local web interface.
• Run a ping test to the recommended IP: ping <provided-IP>
• Confirm you get consistent replies with acceptable latency (typically under 100ms).
• Also verify that pinging a public IP like 8.8.8.8 fails — this confirms you’re on a genuinely closed network.

Step 3: Configure Ping Reboot

On a Teltonika router (RutOS):

1. Navigate to System > Auto Reboot > Ping/Wget Reboot.
2. Enable the ping reboot function.
3. Set the host to ping to the confirmed private network IP.
4. Set the ping interval (e.g., 5 minutes).
5. Set the ping timeout and retry count appropriately — for example, 3 failed attempts before reboot. Be generous here to avoid unnecessary reboots due to transient network events.
6. Configure the action — typically “Reboot” for a full device restart, though some routers also offer the option to restart just the mobile connection first.

Step 4: Test the Configuration

• Confirm the router logs show successful pings at the configured interval.
• If possible, simulate a connectivity failure (e.g., by temporarily changing the APN to an invalid value) and verify the router correctly detects the failure and reboots.
• After the reboot, confirm the router re-establishes the connection and pings resume successfully.

Step 5: Document the Configuration

For fleet deployments, document the ping target IP, the configuration settings, and the provider contact details. If the ping target IP ever changes, you’ll need to update every router in the field — another reason why remote management access (even via VPN) is so valuable.

---

Summary: Key Takeaways

Never enable ping reboot using default settings on a private IP SIM. The factory defaults point at public IP addresses like 8.8.8.8 that are unreachable on a closed network. The router will interpret this as a connection failure and reboot endlessly. This single misconfiguration is one of the most common — and most easily avoided — causes of device downtime in private APN deployments.

Private IP SIM deployments offer significant security advantages for IoT — removing devices from the public internet, reducing attack surfaces, and aligning with regulatory requirements. They are the right choice for many industrial, utility, and critical infrastructure applications.

However, they require careful consideration of features that rely on internet connectivity:

• Ping reboot must target an IP within the private network, not a public address. Contact your SIM provider for a suitable target.
• Cloud management platforms like Teltonika RMS will not work without internet access. Plan for alternatives: selective breakout, VPN management, self-hosted platforms, or dual-SIM architectures.
• NTP, DNS, and firmware updates all need alternative arrangements when internet access is unavailable.

The worst outcome is deploying hundreds of devices on private APNs with default ping reboot settings pointing at 8.8.8.8 — creating a fleet of routers stuck in endless reboot loops. A few minutes of planning and a conversation with your SIM provider will prevent this entirely.

Private IP deployments are not harder to manage — they just need to be managed differently. Get the fundamentals right, and you’ll have a secure, reliable, and self-healing connectivity layer for your IoT infrastructure.