Static IP for Maritime Satellite Internet: CGNAT, VPNs, and Remote Access

A static IP for maritime satellite internet is an addressing service, not a complete remote-access design. Before ordering one, determine whether the vessel needs a public IPv4 address, a stable private address inside a managed network, an IPv6 prefix, or simply a secure way for the ship to reach a shore endpoint. Then define routing, firewall, VPN, identity, failover, monitoring, and contractual behavior around that requirement.

This guide focuses on vessel addressing and reachability. Use the broader maritime satellite internet guide for terminal and service selection, and satellite failover for ships for multi-WAN detection and traffic policy.

Quick Answer

Choose the addressing pattern from the communication requirement:

For many fleets, the clean answer is not “put a public server on every ship.” It is “let each vessel establish an authenticated outbound overlay to a stable enterprise edge.” Direct inbound exposure should have a documented operational need and a stricter security and ownership model.

Separate the Terms

Sellers and buyers often use “static IP” for different products. Write the requirement with all relevant qualifiers:

A persistent public egress address can satisfy allowlisting while all inbound sessions remain blocked. A static private address can support a managed VPN while being invisible to the public internet. Neither behavior is contradictory; they are different requirements.

Identify the Address You Actually Received

RFC 1918 reserves these IPv4 ranges for private internets:

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

RFC 6598 reserves 100.64.0.0/10 as Shared Address Space for service-provider use, including carrier-grade NAT deployments. Seeing one of these addresses on the WAN handoff is evidence that the interface is not directly assigned a globally routable IPv4 address. Seeing a different address does not by itself prove inbound reachability; the provider may still translate, proxy, route selectively, or filter upstream.

Collect three observations:

1. address, prefix, gateway, DNS, and lease information on the terminal or router handoff;
2. public source address observed by a controlled remote endpoint;
3. provider documentation for translation, filtering, routing, persistence, and inbound policy.

If the handoff address and observed egress address differ, at least one translation or proxy boundary exists. Trace the ownership before designing a VPN or publishing an allowlist.

What CGNAT Changes

Carrier-grade NAT lets a provider translate traffic for multiple subscribers through shared public IPv4 resources. RFC 6888 specifies common CGN requirements, including mapping, port-resource, and logging behavior. A particular satellite service still needs plan-specific evidence; the RFC does not say which provider or plan uses CGN.

Under CGNAT, an outbound connection can work normally while unsolicited inbound IPv4 traffic cannot be forwarded to the vessel because the customer does not control the provider's translation boundary. Common effects include:

• no customer-configurable inbound port forwarding at the provider CGN;
• public source addresses or mapped ports that can change;
• allowlists that fail when egress changes;
• protocols that embed addressing or assume stable mappings behaving differently;
• harder attribution and troubleshooting across customer and provider NAT layers;
• overlapping private or shared address space between ship, provider, and shore networks.

Do not infer that CGNAT makes all VPNs impossible. A tunnel initiated outbound from the vessel can often traverse NAT when its protocol, provider policy, middleboxes, and endpoints are compatible. Prove tunnel establishment, keepalive, rekey, idle behavior, MTU, reconnect, and failover on the purchased service.

Four Practical Architectures

1. Outbound-Only Internet Access

Use this when users and ship applications initiate sessions to public or company services and no shore system needs a routed path into the vessel.

ship client -> firewall/NAT -> satellite service -> internet service

Provider NAT may be acceptable. Preserve onboard segmentation and egress policy, and test critical applications. Do not buy a public address merely because it sounds more “enterprise.”

2. Vessel-Initiated Secure Overlay

The vessel gateway establishes a tunnel to a stable shore or cloud security edge:

ship networks -> security gateway == encrypted overlay ==> enterprise edge
                         |
                  satellite underlay

This pattern can decouple enterprise routes from the underlay address and can work across multiple WAN types. RFC 4301 describes IPsec security gateways, protected paths, and policy boundaries; RFC 7296 specifies IKEv2 negotiation and security associations. These standards do not guarantee that every terminal plan, NAT, firewall, and vendor configuration interoperates.

Specify:

• tunnel initiator, peer identities, authentication, algorithms, credentials, and renewal process;
• protected prefixes and traffic selectors, route preference, split or full tunneling, and prohibited flows;
• at least two enterprise-edge endpoints if that dependency requires resilience;
• bootstrap DNS and routing, NAT traversal, keepalive, liveness, rekey, and reconnect behavior;
• path MTU, fragmentation, maximum segment size policy, and tested application payloads;
• logging, alerting, configuration backup, emergency access, and credential revocation.

3. Provider-Managed Private WAN

A managed network can route vessel prefixes to company sites or a cloud interconnect without advertising them publicly. This may simplify fleet routing and support, but the exact isolation, provider core, gateway, handoff, addressing, encryption, and SLA boundaries must be documented.

Ask whether different customer sites can use overlapping ranges, who owns route changes, how a second WAN joins the network, how traffic exits to the internet, and where security inspection occurs. “Private” does not automatically mean encrypted or trusted.

4. Direct Public Inbound Service

Use a public routed address or prefix only when the operational requirement justifies direct reachability and the full design is controlled.

At minimum:

• terminate exposure on a hardened security gateway or purpose-built service boundary, not directly on bridge or machinery equipment;
• default-deny inbound traffic and permit only required sources, destinations, protocols, and time windows;
• use strong authentication and encryption, remove default credentials, patch supported software, and restrict administrative interfaces;
• segregate the exposed zone from operational, enterprise, welfare, and management networks;
• log allowed and denied attempts, alert on anomalies, and retain a tested isolation and recovery procedure;
• obtain accountable approval for the residual risk and third-party access.

The IMO maritime cyber-risk guidelines emphasize connected-system inventories, network segmentation, controlled remote access, third-party risk, monitoring, response, and recovery. A public address does not override those controls.

IPv6 Is a Separate Design Decision

IPv6 can provide globally unique addresses without IPv4 CGN, but global uniqueness is not permission for inbound access. The provider must offer IPv6 on the selected service, route a stable address or prefix as required, and define prefix persistence, filtering, DNS, and support. The vessel firewall must still default to the approved policy.

For dual-stack service, test IPv4 and IPv6 independently. Applications can choose one family while monitoring tests the other, creating a misleading “healthy” result. Record resolver answers, selected paths, firewall rules, tunnel behavior, and remote reachability for both.

Do not assume an IPv6 prefix remains unchanged across terminals, vessels, service areas, plan changes, or WAN failover. Put persistence and renumbering conditions in the contract.

Design the Onboard Address Plan

Create non-overlapping ship prefixes for each security zone and fleet unit. Overlap causes routing ambiguity when multiple vessels connect to the same enterprise overlay or when a support engineer needs simultaneous access.

Maintain an address registry containing:

• vessel, zone, VLAN or interface, prefix, gateway, DHCP or static allocation, and owner;
• route advertisement, translation, VPN selector, DNS zone, and monitoring source;
• approved inbound and outbound flows and their business owner;
• terminal, service, provider, account, public egress, and change conditions;
• reserved, retired, temporary, and emergency ranges.

If renumbering an existing fleet is impractical, document where translation occurs and how logs preserve the relationship between original and translated addresses. Avoid reusing provider handoff or 100.64.0.0/10 shared space inside the vessel; collisions make diagnostics and overlay routing harder.

Plan Address Behavior Across Multiple WANs

Each satellite, cellular, or port link can present a different source address, address family, NAT policy, MTU, and inbound rule. A WAN failover can restore packet flow but break an allowlist, VPN, or management session.

For every path, record:

If a remote system requires one stable source, place that identity at a customer-controlled or contracted egress point and route the vessel through an overlay. Then test failure of both the underlay and the egress point. A single cloud gateway can become the shared failure domain for every ship.

The satellite failover guide for ships covers health checks, policy states, application recovery, and failback in detail.

DNS, Certificates, and Dynamic DNS

DNS maps names to addresses; it does not create reachability through CGNAT or open a firewall. Dynamic DNS can track an address change when the customer actually controls an inbound-reachable address, but it cannot add a provider-side port mapping.

If DNS participates in remote access, define:

• who owns the zone and credentials;
• which system detects address changes and from which network viewpoint;
• record type, time to live, update authentication, and propagation expectations;
• behavior when the address changes during a live session;
• split-horizon or internal DNS requirements;
• certificate names, renewal dependencies, and clock requirements;
• monitoring from outside the satellite provider network.

Do not put raw vessel management interfaces on predictable public names without a security review. A convenient name also improves discoverability for unwanted traffic.

Procurement Checklist

Require written answers for the exact plan, hardware, vessel, and operating area:

1. Is the WAN handoff public, private, or shared IPv4, and is translation performed upstream?
2. Is the public IPv4 dedicated, persistent, routed, or only a stable egress translation?
3. Is unsolicited inbound IPv4 supported, filtered, or prohibited? Who controls the rules?
4. Is IPv6 available, and what address or prefix size, persistence, routing, and filtering apply?
5. Which VPN protocols and NAT-traversal behaviors are supported or restricted?
6. Can the service change address, prefix, translation, gateway, or policy after mobility, reboot, terminal replacement, plan change, or network maintenance?
7. Does the address persist across service zones, ports, countries, and satellite or gateway transitions?
8. What logs and timestamps can the provider supply for address assignment and translation incidents?
9. What DDoS, abuse, port, protocol, and security controls apply to a public service?
10. How are address resources returned, reassigned, or migrated at contract end?

Attach the answers to the service order. Marketing terms such as “business IP,” “priority IP,” or “fixed IP” are not substitutes for routing and security behavior.

Acceptance Tests

Run tests from controlled vessel and shore endpoints. Use approved, non-destructive procedures and retain configurations and timestamps.

Address and Translation

• record the handoff IPv4/IPv6 information and observed public egress from more than one controlled destination;
• reboot or reconnect only under an approved procedure and verify the stated persistence condition;
• confirm route, DNS, and translation behavior after terminal, account, or service transitions that are in scope.

Outbound Overlay

• establish the tunnel from every permitted WAN and network state;
• test authentication, routing, traffic selectors, rekey, idle timeout, reconnect, MTU, and real application transactions;
• fail the active WAN and measure tunnel and application recovery separately;
• fail or isolate a shore endpoint and prove the alternate or documented degraded mode.

Inbound Reachability

• test only the approved source, destination, protocol, and port combinations from outside the provider network;
• verify all other inbound attempts are denied and logged at the intended boundary;
• confirm no route exists from the exposed zone to prohibited onboard networks;
• test credential revocation, emergency isolation, alerting, and recovery.

Evidence Record

Retain service plan and provider statement, address assignments, route and firewall exports, VPN configuration, test source and destination, packet and application results, UTC timestamps, software versions, exceptions, remediation, and witness approval.

Troubleshooting Sequence

When remote access fails, isolate the boundary in order:

1. confirm terminal and WAN state;
2. record the current handoff and observed egress addresses;
3. verify route, DNS, and local firewall policy;
4. check whether CGN or provider filtering changed the expected path;
5. inspect tunnel negotiation, identity, credentials, selectors, NAT traversal, MTU, and route installation;
6. test the destination service and its return route;
7. compare primary and backup WAN behavior;
8. correlate provider, vessel gateway, security edge, and application timestamps.

Avoid opening broad inbound rules as a diagnostic shortcut. Capture evidence at each boundary and restore the approved policy after every controlled test.

FAQ

Do ships need a static public IP for satellite internet?

Not always. Outbound web, cloud, messaging, and many vessel-initiated VPN uses can work without one. A static or stable public address may be useful for source allowlisting or direct inbound service, but an outbound overlay or managed private WAN is often a safer and more portable enterprise design.

How can I tell whether the vessel is behind CGNAT?

Compare the router's WAN address with the public source address seen at a controlled remote endpoint. An address in 100.64.0.0/10 is Shared Address Space under RFC 6598. Private RFC 1918 addresses are also non-global. Confirm the actual translation and inbound policy with the provider.

Can port forwarding work through maritime CGNAT?

Customer-side port forwarding does not control a provider CGN. It works only if the upstream service supplies a compatible mapping or routed public service. Otherwise use a vessel-initiated overlay or another provider-supported architecture.

Will a VPN work without a static IP?

It can when the vessel initiates the tunnel to a stable endpoint and the complete path supports the protocol and NAT behavior. Test liveness, rekey, idle timeout, address changes, MTU, and multi-WAN recovery. Do not assume every VPN mode behaves the same.

Is a public IP less secure than CGNAT?

A public address increases the possibility of direct reachability, but security depends on routing, filtering, exposed services, identity, patching, segmentation, monitoring, and operations. CGN is not a substitute for a vessel firewall or cybersecurity program.

Does IPv6 remove the need for VPNs?

No. IPv6 addressing can remove an IPv4 translation dependency, but it does not provide authentication, encryption, authorization, segmentation, or operational ownership. Use the security architecture required by the application.

Can one static IP remain the same during satellite failover?

Only if the provider or an overlay architecture deliberately presents a stable route or egress identity across the paths. Separate providers normally assign different underlay addresses. Specify and test the behavior rather than inferring it from “static” on one link.

Related Guides

• Maritime Satellite Internet for Ships — broad vessel connectivity design and acceptance
• Satellite Failover for Ships — multi-WAN failure detection, policy, application recovery, and failback
• Satellite Network Topology — logical paths, hubs, gateways, and service boundaries
• Remote Site Network Monitoring — telemetry, alarms, and fault isolation over satellite
• Satellite Provider Evaluation — SLA measurement points, exclusions, support, and remedies
• QoS over Satellite — protecting critical applications on constrained and backup paths