WireGuard vs OpenVPN: Satellite VPN Guide (2026)

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

Some links on this page are affiliate links. If you buy through them we may earn a commission at no extra cost to you — it never changes which product we recommend.

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. It is normal on any satellite connection, because 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 and where they stop. It also explains how each protocol behaves on the three kinds of link you meet on board (geostationary VSAT, Starlink and the older L-band services) and how to set up each one 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 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 is the security software a ship's IT department uses to filter network traffic. It 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 WireGuard vs OpenVPN 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 was more than double OpenVPN's speed over UDP. Speed here is measured in Mbps, or megabits per second, which is how much data moves in one second. 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. 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, and 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.

A note on age: these figures are now more than a year old. VPN apps, server hardware and protocol implementations have all been updated since August 2025, and I have not seen a newer RTINGS run published. Treat the numbers as a picture of the gap between the modes at that date. The exact megabits will have moved, and the ranking may not have.

The MDPI high-latency study

A peer-reviewed study published in 2025 by MDPI is the closest thing to a satellite test in the research. MDPI is an academic publisher whose journals go through independent expert review before printing. The 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. It gives no support to the idea that WireGuard stays fast at high latency. High latency crushed both protocols, and WireGuard simply lost fewer packets along the way. A lab simulation also differs from a real satellite connection, which adds jitter and beam switching on top of plain delay. Jitter is uneven delay that varies from one moment to the next. Beam switching is the dish handing your connection from one satellite or beam to another.

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. The study earns its place here for one reason: the WireGuard-ahead pattern shows up again in a third, unrelated test. It tells you nothing direct 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, because 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.

All the published numbers in one place

The last row is the honest one. Every other row tells you how the protocols rank on something that isn't a ship.

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

A geostationary satellite stays fixed above the same point on Earth, about 35,786 km up. A request and its reply have to cover that distance four times: up and down on the way out, up and down on the way back. At the speed of light that comes to roughly 480 ms before any equipment, queueing or ground routing adds its share, which is why real VSAT round trips often sit around 600 ms or higher. Land broadband does the same trip in tens of milliseconds.

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 and 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.

How each protocol handles the three problems

The two protocols were designed with different goals, and it shows most clearly when the link misbehaves. Here is how each one deals with delay, loss and outages, based on how the protocols are built. None of this has been measured on a real satellite hop, so read it as mechanism, and let your own tests have the last word.

Handshake length

WireGuard sets up a session with a single exchange: your device sends one message and the server sends one back. That is one round trip. On a geostationary link that works out to a little over half a second before data starts flowing again.

OpenVPN builds its session on TLS, the same family of encryption that protects banking websites. The TLS negotiation needs several round trips before the tunnel carries traffic, and OpenVPN over TCP adds TCP's own connection setup on top. On a 600 ms link, every extra round trip adds another 0.6 seconds or so, and a reconnect that takes a moment on land can stretch to several seconds at sea. This is an illustration based on round-trip counts, and the exact figure depends on the server, the settings and how busy the link is.

Changing address after a beam switch

WireGuard is built to follow a device whose address changes. When a valid, correctly encrypted packet arrives from a new address, the server simply starts replying to that address. For a ship that comes out of a beam switch behind a new public address, that means the tunnel often carries on without a full reconnect.

OpenVPN can do something similar with its float option, but many setups leave it off. More often an OpenVPN tunnel notices the silence, waits for its keepalive timer to run out, and then restarts the whole TLS negotiation. That is the several-round-trip cost from above, paid again after every drop.

Rekeying and quiet periods

WireGuard renews its encryption keys roughly every two minutes during active use, with a quick single round-trip exchange. When nothing is being sent, WireGuard sends nothing at all unless you tell it to. That is good for your data allowance and bad for firewalls that forget idle sessions, which is why the keepalive setting further down matters so much at sea.

OpenVPN renegotiates keys on a longer timer (the default is once an hour) and usually runs its own keepalive pings as part of the configuration. It is chattier by default, which helps it stay in a firewall's memory and costs a little more data.

Loss inside the tunnel

In UDP mode, both protocols leave loss recovery to the apps inside the tunnel, which is the right design for a lossy link. OpenVPN over TCP is the exception, with the double retransmission problem described above. That is the main technical reason the TCP mode should stay a fallback.

Your satellite link type changes the answer

The phrase "satellite internet" covers links that behave very differently. The protocol advice stays broadly the same across all of them, but what you should worry about first changes a lot.

The delay figures are typical ranges and vary with the provider, the weather, the load on the beam and how the ship's network is built. Treat them as a rough guide and measure your own link with a simple ping before and after connecting the VPN.

Geostationary VSAT

This is where the handshake difference between the protocols matters most. Every reconnect costs whole seconds, so a tunnel that recovers in one round trip has a real advantage. WireGuard first, with keepalive on, is the setup to start with. Choose a VPN server close to the teleport (the ground station that links the satellite network to the internet), which may be in a country far from where the ship is sailing.

Starlink at sea

With delay closer to land broadband, both protocols feel far more usable, and the gaps from the RTINGS land test are probably a better guide here than on VSAT. The low-orbit satellites move fast and the dish hands over between them often, so short blips are part of normal life. WireGuard's habit of following an address change helps. The bigger obstacle on many ships is the company firewall in front of the Starlink terminal, which may still block or throttle UDP. If you are on Starlink, our guide to a VPN that works with Starlink Maritime covers the setups that suit that network.

L-band

On older L-band links, bandwidth is the limit. FleetBroadband tops out at a few hundred kilobits per second on the fastest terminals, and many crew allowances are billed by the megabyte. Here the question is whether a VPN is worth the overhead at all. If it is, WireGuard's lower overhead and silence when idle make it the lighter option, provided you keep the keepalive interval long enough to avoid burning data. Read whether a VPN actually works on Inmarsat Fleet Broadband before you spend data on a tunnel.

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.

Port 443 is the one to pick in TCP mode. It is the port every secure website uses, so a firewall that blocked it would break ordinary browsing for the whole crew. Most VPN apps that offer OpenVPN over TCP use 443 automatically or let you choose it.

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.

Settings that work: example configurations

This section is for anyone running their own server or editing configuration files by hand. The values below are well-known starting points. Your ship's network may need something different, so change one value at a time and test after each change.

WireGuard

A WireGuard client configuration for a satellite link looks something like this. The keys and addresses are placeholders.

[Interface]
PrivateKey = <your private key>
Address = 10.0.0.2/32
DNS = 10.0.0.1
MTU = 1380

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

MTU. The usual WireGuard default is 1420 bytes. That value comes from a standard 1500 byte packet minus WireGuard's 80 bytes of overhead over IPv6 (60 over IPv4). Satellite networks, company firewalls and extra tunnels inside the ship's own network can shrink the space available, so 1420 is sometimes too big at sea. Step down through 1380, 1340 and 1280, loading a few heavy pages at each step. Keep the highest value that loads everything cleanly.

PersistentKeepalive. WireGuard is silent when idle, which lets a ship's firewall forget the session. A value of 25 seconds is the widely used starting point, short enough for most firewalls. If your tunnel still drops after quiet spells, try 15. If you pay per megabyte and the tunnel is stable, try a longer value and see whether it holds.

Endpoint port. Some crew networks allow only a short list of UDP ports. If 51820 is blocked, running the server on UDP 443 or UDP 53 sometimes gets through, since those ports carry other everyday traffic. This is a trick to test, and a network that inspects traffic can still spot and block it.

OpenVPN over UDP

client
dev tun
proto udp
remote vpn.example.com 1194
keepalive 10 60
tun-mtu 1500
mssfix 1360
float

keepalive 10 60 sends a ping every 10 seconds and restarts the tunnel after 60 seconds without an answer. On a geostationary link, don't set the second number too low, or a short outage during a beam switch will trigger a full, slow renegotiation that a little patience would have avoided.

mssfix tells apps inside the tunnel to use packets small enough to fit once wrapped. It is OpenVPN's main tool against the half-loaded page problem. Start around 1360 and lower it in steps if pages still hang.

float lets the server accept packets from a new client address after the link drops and comes back behind a different public address. The server has to allow it too.

OpenVPN over TCP

client
dev tun
proto tcp-client
remote vpn.example.com 443
keepalive 10 60
mssfix 1360

The only real changes are the transport and the port. Keep this as a second profile on your device, ready for the day UDP stops working. Don't make it your everyday setting, for the TCP-over-TCP reasons above.

Commercial VPN apps

If you use a commercial VPN app, you won't touch these files. You'll pick a protocol from a menu. The labels vary between providers:

Set the protocol by hand before you sail. "Automatic" modes are tuned for land networks and can bounce between protocols on a flaky satellite link, which looks exactly like a VPN that keeps disconnecting.

Picking a VPN service for a ship

The protocol question only helps if your VPN service lets you choose. For a seafarer, the features that count are simple: WireGuard for everyday use, OpenVPN over TCP for locked-down networks, some form of obfuscation for restricted ports, and enough device slots for a phone, a laptop and a tablet.

NordVPN covers all of that. Its NordLynx protocol is built on WireGuard, and the app also offers OpenVPN over UDP and TCP, plus obfuscated servers that run over OpenVPN for networks that block VPN traffic. On a satellite link, run NordLynx day to day and keep OpenVPN TCP selected on your laptop for the voyages where the crew firewall is strict.

Surfshark offers WireGuard and OpenVPN over UDP and TCP as well, and its plan has no limit on the number of devices, so one subscription covers your phone, laptop and tablet. That is useful at sea, where you might keep one device on WireGuard and another on OpenVPN TCP to see which the network prefers that week. Its Camouflage mode, which disguises OpenVPN traffic, is worth switching on in ports with heavy filtering.

Neither service can change the satellite hop. Both give you the protocol choices this guide recommends, and neither one will fix a firewall that blocks everything. Check the current plan prices on the provider's site before buying, since VPN pricing changes often and discounts run in cycles.

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, plus design facts about how each protocol is built.

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. That is 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 reconnects in one round trip and follows an address change without a full restart, which matters most on long-delay geostationary links.
• 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. There is no workaround and 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 is silent when idle. Without keepalive set, a ship's firewall can forget the session during a quiet spell.
• 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.
• It has many tuning options, such as mssfix and float, that can be set for an awkward link once you know what you are doing.

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. That costs you time and, on a metered data plan, money for data resent more than once.
• Its handshake is long, so every reconnect after a beam switch costs several satellite round trips.
• 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.

How to test both protocols on your own ship

Since no published test covers a live satellite link, your own ship is the only test bench that counts. A fair comparison takes about half an hour and needs nothing but your phone or laptop.

1. Measure the link without a VPN. Run a ping to a well-known site for a minute and note the average and the worst values. Run one speed test. This is your baseline, and it tells you which kind of link you are on.
2. Connect with WireGuard and repeat. Same ping, same speed test, same server. The difference from the baseline is the cost of the tunnel.
3. Hold a short video call. Five minutes is enough. Note any freezes, audio drops or reconnects. This matters more than the speed test.
4. Leave it idle for twenty minutes, then load a page. If the page hangs, your firewall is dropping idle sessions and you need a shorter keepalive.
5. Repeat steps 2 to 4 with OpenVPN over UDP, then OpenVPN over TCP.
6. Test again at a busy time. The same link can feel completely different after dinner, when the whole crew is online, compared with the middle of a working day.

Write the results down. Crew networks change between voyages, after a satellite provider switch or after the company updates its firewall, and notes from last contract make the next round of testing quicker.

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.

What MTU should I set for WireGuard on a ship?

Start at the common WireGuard default of 1420 bytes. If pages start loading and then hang, step down to 1380, then 1340, then 1280, testing a few heavy pages at each step. Keep the highest value that loads everything cleanly, because a lower MTU means more packets and slightly more overhead for the same data.

What keepalive interval works on a satellite crew network?

For WireGuard, PersistentKeepalive = 25 (seconds) is the widely used starting value and is short enough to stop most firewalls from dropping an idle session. For OpenVPN, a line such as keepalive 10 60 sends a ping every 10 seconds and restarts the tunnel after 60 seconds of silence. On a metered plan, remember that every keepalive costs a small amount of data.

Does a VPN use more satellite data?

Yes. Every packet carries extra tunnel headers, and keepalive pings add a trickle of traffic even when you are idle. WireGuard adds 60 bytes per packet over IPv4 and 80 over IPv6, which is roughly 4 to 5 percent on a full-size packet. OpenVPN's overhead depends on its settings and is usually a bit higher. On a per-megabyte plan that adds up over a contract.

Is NordLynx the same as WireGuard?

NordLynx is NordVPN's protocol built on WireGuard, with NordVPN's own additions for handling user privacy on shared servers. On a ship it behaves like WireGuard: UDP only, light and fast, with no TCP fallback. When it will not connect, switch the app to OpenVPN over TCP.

Which protocol reconnects faster after a beam switch?

WireGuard, in principle. Its handshake needs a single round trip and it picks up a new public address from the next valid packet, while OpenVPN runs a longer TLS negotiation that needs several round trips. On a geostationary link each round trip costs over half a second, so the difference is noticeable. No published test measures this on a real satellite hop.

Should I use a VPN on Starlink at sea?

A VPN works on Starlink much as it does on land broadband, and Starlink's lower delay makes either protocol feel far better than on geostationary VSAT. The same rule applies: WireGuard first, OpenVPN over TCP if the crew network in front of the dish blocks UDP. Our Starlink Maritime VPN guide covers the setups that suit that network.

Verdict

On a satellite link, run WireGuard first, tune the MTU and keepalive, and have OpenVPN over TCP on port 443 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 and more reliable through firewalls. None of them tested a real satellite link, so let your own connection settle it. On geostationary VSAT, WireGuard's one round-trip handshake gives it the edge after every drop. On Starlink, the crew firewall matters more than the protocol. On L-band, ask first whether the tunnel is worth the data. 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
• Why a VPN keeps disconnecting on ship WiFi

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 and left unestimated. Claims taken from WireGuard's and OpenVPN's own comparison pages are marked as vendor claims, since the vendors measured or described their own products. The satellite delay figures are typical ranges from the physics of the orbits and common experience on board, and your own link can differ. The configuration values (MTU 1420, PersistentKeepalive 25, keepalive 10 60, mssfix 1360) are standard starting points, not measured optimums for any particular ship. The RTINGS figures are now more than a year old and I have not found a newer run, so treat them as a snapshot of the ranking at that date. Figures and prices change. Check the named source directly before relying on any number here that is more than a few months old.

Latest updates

• Is a VPN Legal in Port? Local Law Decides, Ship WiFi Too — our newest guide on this topic.
• Why Does My VPN Leak DNS on Ship WiFi? 3-Step Fix — our newest guide on this topic.
• eSIM vs Local SIM for Offshore Rig Crew Near the Coast — our newest guide on this topic.
• How to Choose Between Airalo and Yesim: 4 Rotation Checks — our newest guide on this topic.