Starlink + VPN + Netflix: Why Streaming Stutters

Starlink has more than enough bandwidth for streaming. A VPN server in Germany has plenty of capacity too. And yet: 4K streams drop out, Netflix picks 720p, the connection hangs, and nobody understands why.

The reason isn’t bandwidth. It’s in the layer below.

The real problem: CGNAT + double NAT

Starlink uses CGNAT by default.

What exactly happens there?

Your traffic is already translated at Starlink in a huge NAT pool: you don’t get your own public IPv4 address. Then your own router takes over and translates a second time. This is called double NAT.

For normal browsing: no problem.

For streaming over VPN: a serious problem.

Why?

• Every data packet is “wrapped” twice and “unwrapped” twice
• Connections always have to be initiated from the inside out
• Many VPN protocols struggle with this setup
• Streaming services often spot VPN servers more easily when NAT connections look unusual

Think of it like this: your data packet has to get past two bouncers before it gets outside. Each one checks, stamps, translates. That costs time, creates overhead, and with a VPN a third bouncer comes on top.

The right VPN protocol for streaming

Not all VPN protocols are equal. For Starlink + streaming there’s a clear ranking.

✅ WireGuard: the best choice

WireGuard is clearly the best protocol for Starlink connections:

• Runs over UDP: ideal for fluctuating connections
• Very low overhead: Starlink’s bandwidth comes through in full
• Stable with changing latency, and Starlink has exactly that quirk
• Fast reconnect after brief connection interruptions
• Hardware-accelerated on current devices (router, NAS, Raspberry Pi)

If you use WireGuard, you notice the difference immediately: a cleaner connection, no constant re-logging into the streaming service.

⚠️ OpenVPN: works, but not optimal

OpenVPN is widely used and very stable. For streaming over Starlink, though, it has drawbacks:

• Higher processing load, especially on older routers
• TCP mode: visible buffering when packets are lost
• UDP mode: better, but still more overhead than WireGuard
• Easier for many streaming services to detect and block

If you already use OpenVPN: choose UDP mode, never TCP for streaming.

❌ IPsec / IKEv2: less suitable for streaming

IPsec / IKEv2 are excellent for site-to-site networking and business VPNs. For streaming there are better options:

• Sensitive to CGNAT and double NAT
• Connection setup is sometimes unstable with Starlink latency fluctuations
• Not all commercial VPN providers offer it in an optimal way

Eliminating double NAT: the most important step

Before optimizing VPN protocols: double NAT has to go.

The solution is bypass mode on Starlink.

If the original Starlink router stays active and another router runs in front of it (for example a UniFi Cloud Gateway), you have double NAT.

Set up correctly:

• Starlink router → enable bypass mode
• Starlink acts only as a modem
• Your own router gets the connection directly
• Only one NAT layer between inside and outside

This alone noticeably improves VPN stability. Everything else is fine-tuning afterward.

More on this: Using Starlink with UniFi properly

IPv6 and streaming VPN: does it make sense?

The honest answer: for streaming over VPN, rather not, and here’s why.

Starlink natively delivers IPv6. That sounds good at first: no CGNAT, direct reachability, a modern protocol. And all of that is true.

But when it comes to streaming VPN, there’s one specific problem: the IPv6 leak.

What is that?

Many commercial VPN services tunnel IPv4 traffic cleanly. But IPv6 traffic runs past the VPN, straight through Starlink. Netflix, ARD Mediathek and the like then don’t see the German IP of the VPN server, but your real Starlink IPv6 address, and with it your actual location.

The result: the VPN is active, yet there’s still no access to the German content.

When IPv6 still matters with a VPN

• If the VPN provider explicitly supports IPv6 in the tunnel (e.g. Mullvad, ProtonVPN)
• If the goal isn’t streaming geo-blocking but privacy
• With self-hosted VPN servers with full IPv6 tunneling

What you should do

For streaming VPN setups: either tunnel IPv6 through the VPN on the WAN or disable it on the router.

On UniFi this works cleanly with a network rule or VLAN configuration. Devices in the streaming VLAN then get no IPv6 gateway to the outside, so all traffic goes through the VPN tunnel.

For simpler setups without UniFi: enable the “IPv6 leak protection” or “IPv6 blocker” option in the VPN client. Most good VPN apps have it by now.

Optimizations with UniFi hardware

With UniFi hardware, streaming over VPN can be solved far more elegantly than with a simple router.

Policy-based routing: selective VPN

This is the most powerful feature for this use case.

The idea: not all devices need to go through the VPN. Only the ones that need it.

With a UniFi Cloud Gateway or a Dream Machine you can set up:

• Smart TV in the living room → VPN (for German media libraries)
• Work laptop → no VPN, directly over Starlink
• Phone → depending on the WiFi network
• Surveillance cameras → no VPN, own VLAN

The result: whoever is watching Netflix doesn’t load the VPN connection of those who are working. And the overall connection stays faster, because only the traffic that really should go through the tunnel does.

In the current UniFi Network software this feature is called “Traffic Management” (in German versions “Traffic-Steuerung”, also “Policy-Based Routing”). It’s available from UniFi Network 8.x and requires a Cloud Gateway.

VLANs: cleanly separating streaming devices

A dedicated VLAN just for streaming devices has several advantages:

• Enable VPN routing for this VLAN only
• Block or tunnel IPv6 selectively in this VLAN
• Streaming devices have no access to the home network (security)
• Set bandwidth limits for the streaming VLAN, if desired

A sensible VLAN layout as an example:

• Home network: PCs, laptops, directly over Starlink
• Streaming: smart TVs, Firestick, Apple TV → VPN tunnel in DE
• IoT: smart home devices, no VPN, no outbound internet access
• Guests: guest WiFi, directly over Starlink, no internal access

Configuring DNS correctly

An often overlooked point: DNS.

If the VPN is active but DNS requests still go through Starlink’s own servers, Netflix can still detect your location via a DNS leak. The DNS resolver knows your actual connection.

On the UniFi Cloud Gateway:

• In the streaming VLAN, enter a DNS server that belongs to the VPN provider
• Alternatively: force DNS requests through the VPN tunnel as well (most VPN providers offer this)
• Or: use Cloudflare (1.1.1.1) or AdGuard DNS as a neutral DNS, never the Starlink DNS

QoS and bandwidth management

Starlink has enough bandwidth, but not unlimited. If several people stream at the same time and someone else is uploading a large backup, streams can drop.

With UniFi you can control this:

• Limit bandwidth for the streaming VLAN (e.g. max. 50 Mbit/s guaranteed, the rest if free)
• Prioritize video conferences over downloads
• Protect the Starlink uplink, which is the bottleneck (15–30 Mbit/s)

Optimizations without UniFi

If you don’t (yet) have UniFi hardware, you can still improve quite a bit:

• Install the VPN directly on the router instead of on each device individually: this takes load off the devices and centralizes configuration (FritzBox with Wireguard, Asus routers with Merlin firmware, GL.iNet routers)
• Choose VPN providers with obfuscated servers: these disguise VPN traffic so it looks like normal HTTPS traffic. Helps especially when streaming services aggressively block VPN addresses.
• Choose the server location carefully: Frankfurt isn’t always the fastest. Sometimes a server in the Netherlands or Vienna is the more stable connection for Spanish Starlink users.
• Enable split tunneling in the VPN client: only the streaming service goes through the tunnel, everything else goes direct. This is the manual equivalent of policy-based routing in UniFi.

Which VPN provider works well with Starlink and streaming?

Recommending a single provider wouldn’t be credible: the situation changes constantly, because streaming services actively block VPN IP ranges.

What to check when choosing:

• Supports WireGuard as a protocol
• Has IPv6 leak protection and DNS leak protection built in
• Offers split tunneling
• Has servers in Germany with fast peering
• Regularly updates its IP addresses (because old ranges get blocked by Netflix)

Self-hosted VPN servers on a German VPS are often the most stable solution, because that IP address isn’t yet on the streaming providers’ blocklists. Most large commercial providers have long had their German IP ranges on Netflix’s list.

Bottom line: what really counts

If you want streaming over Starlink with a VPN to run cleanly, you need three things:

• No double NAT: Starlink in bypass mode
• The right protocol: WireGuard, UDP mode, done
• No IPv6 leak: either tunnel it completely or disable it

Everything else (VPN provider, server location, VLAN structure) is optimization afterward. But without these three foundations, even the most expensive hardware won’t help.

With UniFi hardware, you get much further with policy-based routing, separate VLANs and targeted DNS configuration than with a standard router, because you can finally control who goes online when and with what. For streaming setups, that’s the real advantage.

Starlink has the bandwidth. You just have to route it properly.

🔧 For pros: technical details

This section is aimed at network technicians and advanced users.

WireGuard MTU optimization on Starlink

Starlink itself typically has an MTU of 1500 bytes, but in practice it’s often effectively lower, because Starlink uses its own tunnels internally. WireGuard adds 60 bytes of overhead by default.

Recommended MTU configuration for WireGuard over Starlink:

• WireGuard interface MTU: 1280 (conservative, always works)
• Alternatively: try 1420, and if there are problems, reduce to 1380
• On UniFi: enter the WireGuard MTU in the VPN tunnel interface
• Enable MSS clamping: prevents TCP fragmentation problems in the tunnel

Policy-based routing in UniFi Network

From UniFi Network 8.x (current version) under: Settings → Traffic Management → Traffic Routes

Setting up a sensible routing policy for streaming:

• Source: streaming VLAN (e.g. 192.168.30.0/24)
• Destination: Any (0.0.0.0/0) or specific Netflix/ARD IP ranges
• Next hop: WireGuard tunnel interface
• Kill switch: disable the route if the VPN tunnel is down → no fallback to cleartext

IPv6 leak prevention via firewall

In the streaming VLAN, block outbound IPv6 on the UniFi gateway:

• Firewall rule: IPv6 WAN Out, source = streaming VLAN, destination = Any → Block
• Alternatively: disable IPv6 in the VLAN profile (no router advertisement into the VLAN)
• DNS: in the streaming VLAN, point DHCP option 6 to the VPN provider’s DNS (e.g. Mullvad: 193.138.218.74)

Starlink’s CGNAT and NAT keepalive

Starlink’s CGNAT connections have short timeouts for UDP sessions (often 30–60 seconds of inactivity). WireGuard then drops the session and the stream stutters.

Solution: set WireGuard PersistentKeepalive = 25. It keeps the NAT session open in Starlink’s CGNAT without generating any significant traffic.

Self-hosted WireGuard VPS

For maximum control and the cleanest streaming results: your own WireGuard server on a German VPS (Hetzner, Netcup, Contabo).

Advantages over commercial providers:

• Your own IP, not yet on Netflix blocklists
• No uncertainty about logging
• Full control over MTU, DNS, IPv6
• Cost: €3–5/month for a small VPS

UniFi can be configured directly as a WireGuard peer: no VPN client needed on every device. The entire tunnel runs on the gateway, and all streaming devices in the VLAN benefit automatically.