WireGuard vs OpenVPN: Satellite VPN Guide (2026)

Updated 23 September 2026 · vpn, satellite internet, crew connectivity, network settings

WireGuard vs OpenVPN: which VPN protocol survives high-latency satellite links? High latency means a long delay between sending a signal and getting a reply back — normal on any satellite connection, since the signal has to travel to space and down again. Going by the published evidence, WireGuard is the better first choice on a ship: it is faster and drops fewer chunks of data than OpenVPN in the tests available so far. OpenVPN, run in its slower but more firewall-friendly mode, is the backup to keep for networks that block WireGuard's connection type. Nobody has published a test of both protocols on the same live satellite connection, so be suspicious of any headline that names a clear winner.

That short answer leaves out most of what matters at sea. The protocol you pick is only one setting, and on a satellite hop the other settings often decide whether your video call holds or your remote desktop freezes. This guide covers what the tests actually show, what they cannot show, and how to set up each protocol so it has a fair chance on a crew network.

WireGuard vs OpenVPN on a satellite link: the short answer

Use WireGuard as your default on a satellite link. Keep OpenVPN running in its TCP mode ready as a fallback.

WireGuard sends its data using UDP, a fast delivery method that doesn't stop to confirm each piece arrived before sending the next. That's why it's lightweight. OpenVPN can use that same fast method, or switch to TCP, a slower method that double-checks every piece and resends anything lost. A firewall — the security software a ship's IT department uses to filter network traffic — often blocks UDP but rarely blocks TCP, because TCP is what ordinary web browsing already uses. That is why OpenVPN's TCP mode is the one method almost guaranteed to get through a locked-down network.

WireGuard does less work per packet (a packet is one small chunk that a message gets broken into for the trip), which matters when the link is already slow and every extra bit of processing costs time. OpenVPN is the only one of the two that can switch to TCP when the ship's firewall blocks UDP — that switch can be the difference between reaching your bank's website and staring at a spinner.

Neither protocol makes the satellite faster. The signal still has to travel up to the satellite and back down. The vessel still moves between beams or satellites, the dome still loses sight of the sky behind a crane or a funnel, and the whole crew still shares the same pipe after dinner. A VPN adds a layer on top of all that. The most you can hope for is a layer that adds as little delay and loss as possible and recovers quickly when the link drops.

If you already know why a tunnel slows a connection, skip ahead. If you don't, our explainer on why a VPN makes an already slow ship connection even slower explains the overhead in plain terms.

What the published tests actually show

The published tests show WireGuard ahead on ordinary broadband and both protocols doing badly under simulated high latency. None of them tested a real satellite link, and that gap matters more than any single figure.

The RTINGS broadband comparison

RTINGS published the cleanest side-by-side numbers in its comparison dated August 14, 2025. The table below copies those figures exactly, and every row comes from that one test on a normal land connection.

In that RTINGS test, WireGuard's download speed — measured in Mbps, or megabits per second, which is how much data moves in one second — was more than double OpenVPN's speed over UDP. The same test measured OpenVPN over UDP losing 15.2% of its packets. That's roughly one piece of data in seven never arriving on the first try and having to be resent. On a ship, that lost-packet rate would hurt more than the raw speed gap, because a stalled bank page or a frozen video call doesn't care how many megabits were technically available if the pieces that matter got dropped. OpenVPN over TCP lost no packets in that test, but at 44.1 Mbps its download was the slowest of the three modes.

Most summaries skip one detail from that RTINGS write-up. When downloading a large file, WireGuard's latency rose noticeably more than OpenVPN's did. This happened even though the two protocols had almost the same latency while idle, before any download started. In plain terms: WireGuard moved more data, but its delay grew more while it was busy doing so. On a satellite link, where delay is already the main problem, that's worth remembering before starting a big download in the middle of a video call home.

The MDPI high-latency study

A peer-reviewed study published in 2025 by MDPI — an academic publisher whose journals go through independent expert review before printing — is the closest thing to a satellite test in the research. Researchers used VMware, software that builds a simulated computer network inside a lab, to recreate high-latency conditions. In that simulation, both WireGuard and OpenVPN fell to between 0 and 10 Mbps. That's barely enough to load a plain webpage, let alone hold a video call. The same study also reported packet loss of 12.35% for WireGuard and 47.01% for OpenVPN in a separate VMware baseline test.

Read that study carefully, because it does not prove WireGuard stays fast at high latency — it shows the opposite. High latency crushed both protocols, and WireGuard simply lost fewer packets along the way. It gives no evidence that WireGuard stays usable once latency climbs. A lab simulation also isn't the same as a real satellite connection, which adds jitter (uneven delay that varies from one moment to the next, instead of staying steady) and beam switching (the dish handing your connection from one satellite or beam to another) on top of plain delay.

A third data point: a 2026 cloud-environment study

A separate 2026 study of VPN performance in cloud environments, published through Glasgow Caledonian University's research repository, reported 18.71 ms latency and 2.63% packet loss for OpenVPN, versus 14.95 ms latency and 2.46% packet loss for WireGuard under its tested conditions. Those numbers are far better than either RTINGS' or MDPI's, because a cloud data-center link has nothing like satellite delay. It's included here only to show that the WireGuard-ahead pattern holds in a third, unrelated test — not because it tells you anything about a ship's connection.

None of these three results are directly comparable to each other. The tests used different hardware, network conditions, implementations and workloads. A satellite-specific benchmark with matched equipment and link conditions is unknown — nobody has published one.

What the vendor pages add

WireGuard's own performance page reports tests run with iperf3, a network-speed testing tool, averaged over 30 minutes, according to the page as checked on September 23, 2026. It has no satellite figures. OpenVPN's comparison page, checked the same date, focuses on features: transport choice, account management and fallback options. Windscribe's blog calls WireGuard a good fit for satellite handoffs. That is a provider's marketing claim, and the post gives no measurement to back it.

Why satellite links are hard on any VPN

Satellite links are hard on any VPN because they combine long delay, bursty loss and short outages, and each one affects a tunnel differently. Once you know the three problems, you know which setting to reach for.

Delay stretches every handshake

Every round trip over a geostationary satellite — one that stays fixed above the same point on Earth — takes far longer than a round trip over land broadband. A tunnel that needs several round trips to set itself up pays that cost every single time it connects. A protocol with a short, simple handshake reconnects faster after a drop, which means less time staring at a "connecting" spinner. This is the main reason behind the common claim that WireGuard recovers better at sea, although no source in the research measures it on a real satellite hop.

Loss triggers retransmission

When packets go missing, something has to resend them. With WireGuard and with OpenVPN over UDP, the tunnel itself resends nothing — the apps inside the tunnel recover the same way they would without a VPN. With OpenVPN over TCP, the tunnel resends lost packets itself, and so does any TCP app running inside it, such as a browser or a file sync. This is called the TCP-over-TCP problem. Two layers of retransmission timers react to the same loss, and each one backs off and waits before trying again. On a long-delay link, those waits pile up until the connection feels frozen. The research does not put a number on how much time this costs. The mechanism does explain why OpenVPN over TCP was the slowest mode even on RTINGS' ordinary land connection in August 2025.

Outages and beam switches break state

When a vessel changes beam or satellite, or the dome loses line of sight, the link drops for a moment and sometimes comes back with a different public address. Ship firewalls also forget idle UDP sessions after a while. Either event can leave a tunnel that looks connected while nothing actually gets through — the app shows a green light but the page never loads. Our guide on why a VPN keeps disconnecting on ship WiFi goes through these causes one by one, including keepalive settings.

Which VPN protocol survives high latency satellite links in practice

In practice, the protocol that survives is the one your ship's network actually lets through, tuned for the link you have. Usually that means trying WireGuard first, OpenVPN over UDP second, and OpenVPN over TCP when nothing else connects.

Start with WireGuard

WireGuard is the right first try because it is lighter on the connection. In the RTINGS test of August 14, 2025, it also lost no packets and was the fastest of the three modes. Many VPN apps let you choose the protocol in their settings, so switching takes about a minute. If it connects and holds through a video call, you are done.

Drop to OpenVPN over UDP if WireGuard misbehaves

Try OpenVPN over UDP if WireGuard connects but stalls, because some networks handle the two protocols differently even though both use UDP. Remember the 15.2% packet loss RTINGS recorded for this mode in August 2025, and watch for choppy calls as a sign it's happening to you too.

Keep OpenVPN over TCP as the fallback

OpenVPN over TCP is your fallback when the crew network blocks or throttles UDP, which some shipboard firewalls do. OpenVPN's comparison page, checked on September 23, 2026, says WireGuard is UDP only and has no TCP-443 fallback. On a network that blocks UDP, WireGuard simply will not connect unless you add an extra wrapper. OpenVPN over TCP will be slow, but a slow connection that works beats a fast one that won't connect when you need to reach your bank.

Tune the tunnel, whatever you pick

On a satellite link, these settings often matter more than which protocol you choose.

1. Lower the MTU if pages half load. MTU stands for the largest single chunk of data a network link will carry in one piece. A tunnel wraps every packet in extra headers, and if the wrapped packet is bigger than the link allows, it gets split or silently dropped — you see sites that start loading and then hang. Most VPN apps and routers let you lower the tunnel MTU a step at a time until the hangs stop.
2. Turn on keepalive. A small signal sent at a regular interval tells the ship's firewall the session is still in use, so it doesn't forget you during a quiet period. That prevents the "connected but nothing works" state after a lull in traffic.
3. Pick a nearby server. Every extra hop after the ground station (the facility that connects the satellite network back to the ordinary internet) adds delay on top of the satellite trip. Choose a server close to your provider's teleport, which is often in a different country from the one you're sailing past.

If you are on Starlink, our guide to a VPN that works with Starlink Maritime covers the setups that suit that network. On older L-band links, read whether a VPN actually works on Inmarsat Fleet Broadband before you spend data on a tunnel at all.

Side by side: WireGuard vs OpenVPN features that matter at sea

On features, WireGuard wins on simplicity and OpenVPN wins on flexibility. This table includes only what the research supports.

Pros and cons of each protocol on a ship

Each protocol has clear strengths and real weaknesses on a satellite link. Here they are without the marketing.

WireGuard pros

• It is lighter and faster on the published land tests, which leaves more of a thin satellite pipe for your actual traffic — one less thing competing for bandwidth when several crew members are online at once.
• Its packet record is cleaner, with no loss in RTINGS' August 2025 test and lower loss than OpenVPN in both the 2025 MDPI study and the 2026 cloud study.
• It is simple to configure when you run your own server, so there are fewer settings to get wrong, and less time lost troubleshooting from a cabin with a slow connection.

WireGuard cons

• It runs over UDP only. OpenVPN's comparison page says it has no TCP fallback, so a firewall that blocks UDP stops it completely — no workaround, no partial connection, just nothing.
• It has no built-in obfuscation. According to OpenVPN's page and a secondary technical guide, that makes WireGuard easier for a network to detect and block if the ship's provider or a port country filters VPN traffic.
• Its delay grows under load. RTINGS noted in August 2025 that WireGuard's latency rose more than OpenVPN's during a download, which can hurt a call that shares the link with a big download.
• It has no accounts or MFA built in. That matters more to a company rolling it out across a fleet than to a single crew member.

OpenVPN pros

• Its TCP fallback gets you through networks that block UDP, which is the difference between working and not working on a locked-down crew network.
• Its management tools are mature, according to OpenVPN's own page, which suits companies that need accounts, MFA and single sign-on across a fleet.

OpenVPN cons

• It lost a lot of packets over UDP — 15.2% in RTINGS' August 2025 test and 47.01% in the 2025 MDPI baseline.
• It is very slow over TCP, and the TCP-over-TCP retransmission problem gets worse as delay grows, which costs you time and, on a metered data plan, money for data already resent once.
• It has more settings to get wrong. That is a real cost when you are troubleshooting from a cabin, where high ping makes every change slow to test.

Who should not bother with either

Some seafarers are better off with no VPN at all, or with a different fix. If you only want faster streaming, a tunnel adds overhead and rarely helps, so start with the basic crew WiFi fixes instead. If you pay per megabyte on an older link, the protocol overhead costs you money every session, whichever one you pick. And if your company IT bans personal VPNs on the crew network, follow the rule, because a banned tunnel can get your device kicked off the network entirely.

If you mostly need voice calls home, the calling app matters more than the protocol. VoIP apps — voice-call apps that use the internet instead of a phone line — vary a lot in how well they handle satellite delay, with or without a VPN running.

FAQ

Is WireGuard faster than OpenVPN on satellite internet?

WireGuard was faster on a land connection in RTINGS' comparison of August 14, 2025, but no published source tests both protocols on the same live satellite link. The 2025 MDPI study found that both collapsed under simulated high latency, with WireGuard losing fewer packets. On a ship, expect WireGuard to feel a little better and neither one to feel fast.

Why does my VPN connect on WiFi in port but fail at sea?

The usual causes are a crew network firewall that blocks or throttles UDP and a session that times out during quiet periods or beam changes. Try OpenVPN over TCP to test for the first cause, and turn on keepalive to test for the second. If pages half load, lower the tunnel MTU.

Should I use OpenVPN over TCP or UDP on a ship?

Use UDP when it connects and keep TCP for networks that block UDP. In RTINGS' August 2025 test, OpenVPN over TCP was far slower than over UDP. Running TCP apps inside a TCP tunnel also stacks retransmissions — each layer resends lost data on top of the other — and that gets worse as delay grows. TCP is the mode that keeps you connected when nothing else will.

Does the VPN protocol change my satellite ping?

No protocol can reduce the delay of the satellite hop itself. A tunnel can only add time on top, through encryption, extra headers and the distance to the VPN server. Picking a server near your provider's ground station keeps that extra time small.

Can WireGuard get through a network that blocks VPNs?

According to OpenVPN's comparison page and a secondary technical guide, WireGuard has no built-in obfuscation, so a network that detects and blocks VPN traffic can stop it. Wrappers that disguise WireGuard traffic do exist, but the only source on them in our research is a secondary guide. For ports with heavy restrictions, see our guide to VPNs for restricted ports.

Verdict

On a satellite link, run WireGuard first, tune the MTU and keepalive, and have OpenVPN over TCP ready for the day the crew network blocks UDP. The RTINGS data from August 2025, the 2025 MDPI study and a 2026 cloud-environment study all agree on the same pattern — WireGuard faster, OpenVPN's TCP mode slower but more reliable through firewalls — but none of them tested a real satellite link, so let your own connection settle it. Switch protocols, test a video call, and keep whichever one holds.

Related reading

• The best VPN for ports with internet restrictions like China and the UAE
• VoIP apps that survive satellite latency at sea
• Starlink vs VSAT for crew welfare

Sourcing and limits

Every figure in this guide is credited to whoever published it, with the date it was measured: RTINGS' numbers are from its comparison dated August 14, 2025; the packet-loss figures are from a 2025 peer-reviewed MDPI study; the cloud-latency figures are from a 2026 study published through Glasgow Caledonian University's research repository. No source found here tests WireGuard and OpenVPN on the same live satellite connection, so that specific comparison is marked unknown rather than estimated. Claims taken from WireGuard's and OpenVPN's own comparison pages are marked as vendor claims, not independent measurements. Figures and prices change — check the named source directly before relying on any number here that is more than a few months old.