When organizations start talking about low-Earth-orbit (LEO) satellite connectivity, the conversation usually begins with coverage, bandwidth, resilience and how quickly they can get a location online. What does not always come up early enough is whether the public IP will stay the same.
One question I've started asking much earlier in these conversations is: What breaks if that public IP changes?
It sounds like a small detail. It often isn’t. Depending on the LEO provider and service plan, you may receive a public IP address, but that address may still be dynamically assigned rather than static. In other words, having a public IP does not necessarily mean you have a static public IP.
I have spoken with organizations using public IPs over LEO connections where the address has stayed the same for so long that people naturally start treating it as static. Before long, applications, security controls and operational processes become hard-coded to an address that’s not guaranteed to remain the same.
Then the “static” address changes. The first question is why is our site down, and once they realize they lost connectivity because of an IP change, it becomes: “Can we make this static without reworking the network?”
Sometimes we can. Sometimes the answer involves changing more of the environment than the customer expected.
That’s why I think the better time to have the static IP conversation is before the LEO service is deployed, not after everything around it has already been designed.
A Static IP Requirement Usually Points to Something Else
When someone tells me, “We need a static IP,” my next question is: What depends on it?
Because the IP itself is rarely the requirement. Something in the environment needs that address to remain consistent:
- A firewall policy relies on an IP allowlist
- Remote administration or inbound access depends on a known address
- An application uses the public IP to identify the location
- A third-party service accepts traffic only from an approved public IP
They can all lead to the same request for a static IP, but they can have very different implications for the design.
For an organization with one location, discovering an IP dependency after deployment might mean you can work around it.
Across 20, 50 or 100 locations, it becomes a much bigger operational challenge. Now you need to know which sites have IP dependencies, what happens to each one during failover and who owns the remediation if an address changes.
That’s the part I think gets underestimated.
Failover Is Not Just About Restoring Internet Access
On paper, the design can look straightforward: Primary circuit fails → LEO backup takes over → site stays online.
From a connectivity perspective, that can be a successful failover. From an application perspective, it can still be a failure.
Imagine the LEO connection takes over exactly as planned, but a payment system rejects the traffic because it no longer comes from the approved IP.
That leads to one of the most important lessons I have learned from these projects: A failover design should be tested against what the business needs to keep working, not simply whether the backup connection comes online.
What Solving It Can Mean in Practice
We recently looked at this exact requirement for a national restaurant chain that was considering LEO satellite connectivity as a backup across multiple locations.
The organization needed a static public IP to support remote management and payment systems, rather than relying on an address that might change. Instead of trying to make the satellite connection’s public IP static, our engineering team looked at whether the static public IP could be provided elsewhere in the design.
The design used primary broadband under normal conditions, with a secondary LEO satellite connection as backup. A Peplink device at the site would establish a SpeedFusion™ connection to a centrally hosted SpeedFusion FusionHub™, through which both broadband and LEO traffic would flow.
That meant the site could switch between broadband and LEO without relying on either connection to provide the stable public IP and without dealing with a change in the static IP address for the site.
Three Things I Would Ask Your Teams Before Deployment
Before we get too far into hardware or the failover design, there are three things my team tries to understand:
- What breaks if the public IP changes? Is it an allowlist, remote access, an application, a security policy or something else?
- What needs to keep working during failover? It’s not enough for the backup connection to come online. Which applications and processes still need to work once traffic moves onto that connection?
- Where should the static public IP come from? Does it need to come from the active connection at the site, or can traffic from both broadband and LEO be routed through a central location that provides a consistent static IP?
The need for a static public IP can completely change how failover needs to be designed. Once the architecture is in place, changing where that static public IP is provided can become much harder.
Ethan Ralston
Ethan Ralston - Vice President, Enterprise Sales
Ethan Ralston has more than 20 years of experience in wireless and enterprise connectivity. As Vice President of Enterprise Sales at Globalgig, he leads the Global Connectivity Sales team, helping organisations solve complex challenges across cellular IoT, eSIM, fixed wireless access, satellite connectivity, network failover and managed services.
Previously, Ethan was President and co-owner of Feeney Wireless, which grew into a nationally recognised wireless solutions provider before its acquisition by Inseego in 2015.