Satellite Failover for Ships: VSAT, LEO, and Multi-WAN Design

Satellite failover for ships is the controlled movement of approved traffic from an impaired vessel WAN path to a usable alternative. It is not proved by installing two antennas or by showing that both links can reach the internet. A working design must detect the right failure, choose a permitted path, preserve security policy, restore the required applications, raise an actionable alarm, and return traffic without creating another outage.

This guide focuses on resilience across shipboard VSAT, LEO, cellular, and port connectivity. For initial service and terminal selection, start with the broader maritime satellite internet guide. For public addressing and remote access, use static IP for maritime satellite internet.

Quick Design Rule

A failover claim is complete only when all six questions have evidence:

usable failover = independent alternate path
                + trustworthy failure detection
                + deterministic traffic policy
                + secure addressing and overlay behavior
                + application recovery within the required time
                + monitored failback and retained test evidence

Treat these as different functions:

Do not use these terms interchangeably in a specification or acceptance report.

Define the Required Outcome Before the Router

Start with applications and outage consequences, not a preferred SD-WAN product. For each traffic class, document:

• source, destination, protocol, port, and direction of session initiation;
• identity, DNS, time, certificate, cloud, and shore-side dependencies;
• normal path, permitted alternate paths, and prohibited paths or operating zones;
• busy-period bandwidth, packet size, latency and loss sensitivity, and cost policy;
• maximum detection time, restoration time, data-loss tolerance, and safe degraded mode;
• whether an existing session must survive or whether a clean reconnect is acceptable;
• operational owner, security approver, alarm recipient, and recovery procedure.

An example policy worksheet:

The design should shed or rate-limit lower-priority traffic before it overwhelms a smaller backup link. Use the QoS over satellite guide to build the degraded policy from the purchased capacity, not the primary link's headline speed.

Draw the Failure Domains

Put both WAN paths on one physical and logical diagram. Mark every shared element:

ship applications and user networks
             |
      switching / firewall
             |
     multi-WAN policy point
        /             \
 terminal A         terminal B
        |               |
 satellite path A   satellite/cellular path B
        |               |
 gateway / core A   gateway / core B
        \             /
       shore, cloud, or internet service

Then audit the apparent diversity:

Two services sold by different brands can still share infrastructure. Conversely, two terminals on one provider may have some diverse elements but a shared core. The decision is not whether paths are “independent” in the abstract; it is whether they are independent of the failure cases the vessel must survive.

Build Layered Health Checks

A physical carrier or modem lock proves only part of a path. A public ping can succeed while DNS, VPN, the required application, or the return route is broken. One remote target can also fail while the WAN remains usable.

Use several layers of evidence:

1. Terminal state: power, alarms, receive state, transmit authorization, obstruction or pointing condition, and provider registration.
2. Local interface: link state, address, route, errors, queue drops, and handoff health between terminal and WAN router.
3. Network path: probes to controlled endpoints across the provider path and, where appropriate, more than one destination.
4. Security overlay: tunnel state, key exchange or keepalive evidence, route installation, and protected traffic counters.
5. Application transaction: a small, safe request that proves the actual dependency chain.
6. Performance guardrails: sustained loss, delay, jitter, or available capacity conditions that distinguish a brownout from a hard outage.

RFC 5880 specifies Bidirectional Forwarding Detection for rapid detection between forwarding engines. BFD can be useful when the adjacent network and equipment support it, but it is not a universal end-to-end application test and should not be assumed to be available across a retail internet service.

Tune detection to the path. An interval copied from a low-latency terrestrial link can flap on a variable satellite service or waste scarce return capacity. For every probe, specify destination, protocol, interval, timeout, success and failure counts, traffic cost, expected path behavior, and response to ambiguous results.

Avoid Flapping

Use a state model instead of a binary “ping equals route” rule:

healthy -> suspect -> degraded -> failed
   ^          |          |          |
   |          +----------+----------+
   +------ stable recovery / hold-down

• Suspect: collect faster or broader evidence without immediately moving all traffic.
• Degraded: move or protect selected critical flows while observing the path.
• Failed: withdraw the path for the traffic classes covered by the failed test.
• Recovery: require a defined stable period, then restore traffic gradually or with operator approval.

Use different thresholds for a total path loss and a performance brownout. A link that carries telemetry may still be acceptable for that class even when it cannot support voice or bulk transfer.

Keep Routing, NAT, DNS, and Security in the Same Design

The WAN router may switch paths in seconds while applications remain offline. Common reasons include:

• the public source address changes and a remote peer or allowlist rejects it;
• NAT state exists only on the failed path;
• a site-to-site VPN is bound to one interface, peer address, or route;
• DNS answers or resolvers differ between paths;
• an application pins a connection to one transport session;
• return traffic follows a different path and is rejected by a firewall or provider;
• identity, certificate validation, time, or cloud security services are unreachable on the backup;
• backup capacity is consumed by uncontrolled welfare traffic before critical sessions recover.

Ordinary TCP sessions usually cannot be assumed to survive a source-address change. Some explicitly supported mechanisms can offer different behavior: RFC 8684 defines Multipath TCP subflows across multiple addresses, and RFC 9308 describes QUIC connection-migration applicability. These standards do not mean an arbitrary existing application, operating system, middlebox, and service path supports seamless migration. Prove it end to end or specify application reconnection.

An outbound overlay to a stable shore or cloud endpoint can present a consistent enterprise route while the underlay changes. That design still needs two reachable endpoints where required, independent DNS or bootstrap logic, secure credential storage, tunnel re-establishment tests, capacity controls, and a recovery path if the overlay itself fails.

Protect the Shipboard Security Boundary

The IMO maritime cyber-risk guidelines call for identifying connected systems and dependencies, protecting through controls including segmentation and remote-access management, detecting events, responding, and recovering. Failover policy must preserve those controls.

Do not let an emergency route create a broad bridge between:

• bridge, navigation, machinery, cargo, or other operational technology;
• company administration and business systems;
• crew, passenger, or guest access;
• terminal, router, and security-device management;
• vendor remote support and shore operations.

Each alternate path needs an approved zone, firewall, identity, logging, remote-access, and update policy. A bypass cable that restores internet access but removes segmentation is not a successful recovery.

Specify Failover and Failback Separately

For each policy, write these timers and actions explicitly:

T_detect       = time until the policy declares impairment
T_decide       = time to apply the selected routing or overlay state
T_transport    = time until packets traverse the alternate path
T_application  = time until the required application works

total service restoration = T_detect + T_decide + T_transport + T_application

Measure them separately. “WAN switched in five seconds” says nothing about a VPN that takes another minute to recover or a user application that requires manual login.

Failback can be more disruptive than failover. Define:

• minimum stable time before the primary is eligible again;
• whether existing sessions stay on the backup while new sessions use the primary;
• whether critical applications require operator approval;
• how routes, NAT, tunnels, DNS, and QoS return to normal;
• how repeated transitions are limited and reported.

Acceptance Test Matrix

Agree safe test conditions, witnesses, measurement points, thresholds, and remedies before installation. Do not simulate antenna, power, maneuvering, or RF events that create an unsafe vessel condition.

Record at least:

• UTC-synchronized router, firewall, terminal, VPN, DNS, application, and provider timestamps;
• vessel position, heading, speed, loading or obstruction state, and relevant operating zone;
• path state, probe results, routes, addresses, tunnel state, traffic counters, queue drops, and application transactions;
• detection, packet restoration, application recovery, failback, alarm, acknowledgment, and escalation times;
• software, configuration, service plan, test endpoints, exceptions, corrective actions, and retest result.

Operational Runbook

A backup path degrades if it is never exercised. Establish a risk-based schedule that the vessel and shore teams can execute safely:

1. verify both services, plans, authorizations, subscriptions, and support contacts remain current;
2. review terminal, power, network, overlay, and application alarms for hidden failures;
3. run a controlled application-level switchover and failback test;
4. confirm backup capacity, traffic shaping, addressing, VPN, DNS, logging, and remote management;
5. inspect configuration drift, software changes, credential expiry, allowlists, and shore endpoints;
6. retain evidence, assign exceptions, and test the correction.

Use remote site network monitoring to separate terminal, RF, IP, security, and application symptoms. Alert on a degraded protection path even while the primary remains healthy; otherwise the first visible failure may arrive when no backup is available.

Procurement Questions

Ask bidders to answer with diagrams, plan documents, configurations, and test evidence:

• Which vessel, route, zones, operating modes, terminals, and service plans are included?
• Which physical, space, gateway, terrestrial, management, and support elements are shared?
• What signals are available for health checks, and who controls their thresholds?
• Can the backup carry the defined degraded traffic matrix at its purchased service level?
• What public-address, NAT, IPv6, VPN, DNS, and inbound-access behavior applies on each path?
• Which sessions are expected to survive, reconnect automatically, or require operator action?
• How are failover and failback measured, logged, alarmed, and changed?
• What happens when a plan, network, gateway, terminal software, or service area changes?
• Who owns incidents that cross the terminal, provider, overlay, ship LAN, and application boundaries?

Tie the answers to the satellite provider evaluation guide. A service credit does not restore a ship, but a precise measurement and responsibility boundary prevents gaps between vendors.

FAQ

What is the best satellite failover setup for a ship?

There is no universal pair of services. Choose paths that satisfy the vessel's route, installation, authorization, application, security, support, and failure-domain requirements. Then prove the degraded traffic and recovery behavior in dockside and route-representative tests.

Should a ship use VSAT plus LEO?

That can create useful orbit, terminal, and service diversity, but the labels do not prove independence. Check antenna views, power, onboard routing, gateway and terrestrial paths, addressing, support, and route authorization. Other combinations may fit a vessel better.

How fast should ship failover be?

Derive the requirement per application. Separate failure detection, route or overlay change, packet restoration, and application recovery. A very short router timer can cause flapping on a variable path and may not improve the actual application outcome.

Will active calls and VPN sessions survive failover?

Do not assume they will. Source-address, NAT, tunnel, transport, peer, and application behavior all matter. Use an explicitly supported continuity mechanism or specify and test reconnection.

Can one ping target control failover?

It is weak evidence. Combine local terminal state, controlled path probes, security-overlay state, and safe application transactions. Use multiple failure and recovery conditions with hysteresis.

Is two antennas enough for redundancy?

No. They may share blockage, structure, power, cables, router, provider core, gateway, addressing, DNS, or support. Show how the architecture survives each required failure.

Related Guides

• Maritime Satellite Internet for Ships — broad vessel service, terminal, network, contract, and sea-trial design
• Static IP for Maritime Satellite Internet — CGNAT, public addressing, VPN overlays, and inbound remote access
• Satellite Diversity Explained — satellite, orbit, gateway, site, and frequency diversity
• Satellite Gateway Diversity — provider ground-path resilience and common dependencies
• Satellite Link Availability — availability objectives, measurement, and combined paths
• Satellite Terminal Architecture — RF and network interfaces inside the terminal system