Site-to-Site VPN Using Starlink: Complete Setup Guide

Have you ever tried setting up a site-to-site VPN using Starlink only to hit a wall with CGNAT? You’re not alone. Starlink’s revolutionary satellite internet has transformed connectivity for remote locations, but its network architecture presents unique challenges for traditional VPN setups.

As an IT professional who’s helped dozens of organizations overcome these exact challenges, I’ve discovered that while Starlink doesn’t play by the traditional networking rules, there are proven strategies that work exceptionally well. In this comprehensive guide, I’ll walk you through every method that actually works, complete with real-world configurations and troubleshooting tips.

TL;DR: Setting up a site-to-site VPN connection with Starlink requires specific strategies to overcome CGNAT limitations. The most reliable solutions include using a cloud VPS relay, upgrading to Starlink Business, or implementing overlay networks like Tailscale. While challenging, these methods enable robust site-to-site connectivity even behind Starlink’s shared IP addressing.

Understanding Starlink and Site-to-Site VPN Challenges

What Makes Starlink Different for VPNs?

Starlink supports VPNs that use TCP or UDP protocols, but the satellite internet service operates fundamentally differently from traditional ISPs. Unlike your typical cable or fiber connection, Starlink uses a constellation of low Earth orbit (LEO) satellites to provide internet access, which introduces several unique networking considerations.

Key Starlink characteristics affecting VPNs:

• Carrier-Grade NAT (CGNAT) implementation
• Dynamic IP addresses that change frequently
• Satellite latency ranging from 20-50ms
• Bandwidth fluctuations based on weather and network load
• Shared IP addresses among multiple users

Why Site-to-Site VPNs Matter for Modern Businesses

Site-to-site VPNs enable seamless connectivity between multiple business locations, allowing:

• Secure file sharing between offices
• Remote access to centralized resources
• Unified network management across locations
• Cost-effective alternative to dedicated lines

For businesses with remote locations served by Starlink, establishing reliable site-to-site connectivity becomes crucial for operational efficiency.

The CGNAT Problem: Why Traditional VPNs Fail

Understanding CGNAT’s Impact

Starlink provides users of their standard Residential Internet Service with CGNAT private IP addresses, which fundamentally changes how network connections work. Instead of receiving a unique public IP address, multiple Starlink users share the same public IP through network address translation.

Here’s what CGNAT means for your VPN:

1. No inbound connections – External devices can’t initiate connections to your network
2. Port forwarding disabled – Traditional port mapping doesn’t work
3. Shared addressing – Your “public” IP might be 100.64.x.x (CGNAT range)
4. Dynamic allocation – IP addresses change frequently

Verifying Your Starlink IP Status

Before attempting any VPN configuration, verify whether you’re behind CGNAT:

# Check your Starlink-assigned IP
curl ifconfig.me

# Compare with your router's WAN IP
# If different, you're behind CGNAT

If your public IP (from ifconfig.me) differs from your router’s WAN IP, you’re definitely behind CGNAT and will need one of the solutions outlined below.

Pre-Planning Your Site-to-Site VPN with Starlink

Hardware Requirements

Essential equipment for each site:

• VPN-compatible router (pfSense, OPNsense, UniFi, or similar VPN servers)
• Starlink Ethernet Adapter (required for third-party routers)
• Adequate processing power for VPN encryption
• Backup internet connection (optional but recommended)

Recommended router models that handle Starlink well:

• Ubiquiti Dream Machine Pro
• pfSense appliances
• OPNsense-compatible hardware
• MikroTik RouterBoard series

Network Planning Considerations

1. IP addressing schemes – Ensure no conflicts between sites
2. Bandwidth requirements – Account for VPN overhead
3. Latency tolerance – Critical for real-time applications
4. Failover strategies – Plan for Starlink outages

Choosing Your VPN Topology

Hub-and-Spoke vs. Mesh considerations:

• Hub-and-spoke works better with one fixed IP location
• Mesh topology requires more complex relay solutions
• Hybrid approach often provides best balance

Method 1: Cloud VPS Relay (Most Reliable)

This method uses a Virtual Private Server with a static public IP as a central relay point, effectively bypassing CGNAT limitations entirely.

Why VPS Relay Works Best

The cloud relay method proves most reliable because:

• Eliminates CGNAT issues completely
• Provides stable public IP for connections
• Offers redundancy through cloud infrastructure
• Supports multiple sites easily

Step-by-Step VPS Relay Setup

Step 1: Choose and Configure Your VPS

Select a cloud provider with good global connectivity:

• AWS Lightsail – $5/month for basic needs
• DigitalOcean – Excellent for WireGuard setups
• Vultr – Good global presence
• Linode – Reliable performance

Step 2: Install WireGuard on Your VPS

# Update system
sudo apt update && sudo apt upgrade -y

# Install WireGuard
sudo apt install wireguard

# Generate server keys
wg genkey | sudo tee /etc/wireguard/private.key
sudo cat /etc/wireguard/private.key | wg pubkey | sudo tee /etc/wireguard/public.key

Step 3: Configure VPS as Hub

Create /etc/wireguard/wg0.conf:

[Interface]
Address = 10.100.0.1/24
ListenPort = 51820
PrivateKey = [VPS_PRIVATE_KEY]
SaveConfig = false

# Enable IP forwarding
PostUp = sysctl -w net.ipv4.ip_forward=1
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -s 10.100.0.0/24 -o eth0 -j MASQUERADE

PostDown = iptables -D FORWARD -i wg0 -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -s 10.100.0.0/24 -o eth0 -j MASQUERADE

# Site A (Starlink location)
[Peer]
PublicKey = [SITE_A_PUBLIC_KEY]
AllowedIPs = 10.100.0.2/32, 192.168.1.0/24
PersistentKeepalive = 25

# Site B (Fixed IP location)
[Peer]
PublicKey = [SITE_B_PUBLIC_KEY]
AllowedIPs = 10.100.0.3/32, 192.168.2.0/24
PersistentKeepalive = 25

Step 4: Configure Site Routers

For your Starlink site, configure as WireGuard client:

[Interface]
Address = 10.100.0.2/32
PrivateKey = [SITE_A_PRIVATE_KEY]

[Peer]
PublicKey = [VPS_PUBLIC_KEY]
AllowedIPs = 10.100.0.0/24, 192.168.2.0/24
Endpoint = [VPS_PUBLIC_IP]:51820
PersistentKeepalive = 25

Benefits and Considerations

Advantages:

• 99%+ reliability in my experience
• Scales easily to multiple sites
• Works with any Starlink plan
• Predictable monthly costs ($5-20/month)

Considerations:

• Additional latency (typically 10-30ms)
• Monthly VPS costs
• Single point of failure (mitigated by cloud reliability)

Method 2: Starlink Business Plan

Starlink Business customers have the option of getting a publicly routable IP address instead of a CGNAT IP address, which dramatically simplifies VPN setup.

When Starlink Business Makes Sense

Consider upgrading to Starlink Business if:

• Multiple sites need VPN connectivity
• Critical applications require consistent access
• Budget allows for higher monthly costs
• Performance is more important than cost

Starlink Business VPN Configuration

With a public IP, you can use traditional VPN methods:

# Standard IPsec configuration works
config vpn ipsec phase1-interface
    edit "starlink-site"
        set interface "port1"
        set peertype any
        set net-device disable
        set proposal aes256-sha256
        set dhgrp 14
        set remote-gw [REMOTE_PUBLIC_IP]
        set psksecret [SHARED_SECRET]
    next
end

Important Limitations

Even with Starlink Business:

• IP addresses remain dynamic – use DDNS
• Higher costs – typically $250+/month
• Subject to fair use policies

Method 3: Overlay Networks (Tailscale/ZeroTier)

Overlay networks provide an increasingly popular solution for site-to-site connectivity, handling CGNAT traversal automatically.

Why Tailscale Excels with Starlink

Tailscale’s VPN solution can help users regain the ability to host servers, forward ports, and establish direct connections behind CGNAT. The service uses modern networking techniques to create peer-to-peer connections even through NAT.

Tailscale Site-to-Site Setup

Step 1: Install Tailscale on Site Routers

Most modern routers support Tailscale either natively or through containers:

# On Ubuntu-based systems
curl -fsSL https://tailscale.com/install.sh | sh

# Enable IP forwarding
echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Step 2: Configure Subnet Routing

At each site, enable subnet advertisement:

# Site A (192.168.1.0/24)
sudo tailscale up --advertise-routes=192.168.1.0/24

# Site B (192.168.2.0/24)  
sudo tailscale up --advertise-routes=192.168.2.0/24

Step 3: Enable Routes in Tailscale Admin

In the Tailscale admin console:

1. Navigate to Machines
2. Find your subnet routers
3. Enable the advertised routes
4. Configure ACLs as needed

ZeroTier Alternative

ZeroTier allows you to pick any or multiple private subnets and also set individual static addresses on any device. Some users prefer ZeroTier for its flexibility with IP addressing.

Overlay Network Comparison

Feature	Tailscale	ZeroTier
Ease of Setup	Excellent	Good
Performance	Good	Good
IP Flexibility	Limited	Excellent
Free Tier	100 devices	25 devices
Router Support	Growing	Extensive

Advanced Configuration and Optimization

Quality of Service (QoS) for VPN Traffic

Prioritize VPN packets to ensure consistent performance:

# pfSense ALTQ configuration example
interface wan {
    bandwidth 100Mb;
    queue(default, ack, vpn);
    queue default bandwidth 60% default;
    queue ack bandwidth 10% priority 6;
    queue vpn bandwidth 30% priority 7;
}

match proto tcp port 1194 queue vpn  # OpenVPN
match proto udp port 51820 queue vpn # WireGuard

MTU Optimization for Satellite Links

Satellite connections often require MTU adjustments:

# Test optimal MTU
ping -M do -s 1464 8.8.8.8  # Start with 1464
# Reduce packet size until no fragmentation

# Set optimal MTU (typically 1420-1460)
ip link set dev wg0 mtu 1420

Monitoring and Alerting

Implement monitoring for tunnel stability:

#!/bin/bash
# Simple tunnel monitoring script
VPN_HOST="10.100.0.1"
LOG_FILE="/var/log/vpn-monitor.log"

if ! ping -c 3 $VPN_HOST > /dev/null 2>&1; then
    echo "$(date): VPN tunnel DOWN" >> $LOG_FILE
    # Add notification logic here
    systemctl restart wg-quick@wg0
fi

Router-Specific Configuration Examples

pfSense/OPNsense with WireGuard

1. Install WireGuard package via System > Package Manager
2. Generate keypairs in VPN > WireGuard
3. Create tunnels with appropriate peer configurations
4. Configure firewall rules to allow VPN traffic

Key pfSense settings:

Interface Assignment: Assign WireGuard interface
Firewall Rules: Allow traffic between VPN subnets
NAT Rules: Disable NAT for VPN traffic

UniFi Dream Machine Configuration

UniFi devices can use Teleport or manual WireGuard:

1. Enable Advanced Features
2. Configure Site-to-Site VPN in Network settings
3. Use Teleport for simplified setup, or
4. Manual WireGuard configuration via SSH

MikroTik RouterOS Setup

The tunnel is established I can ping any IP from homelan router to starlink lan – this shows MikroTik can work with proper configuration:

/interface wireguard
add listen-port=51820 mtu=1420 name=wg-starlink private-key=[PRIVATE_KEY]

/interface wireguard peers
add allowed-address=10.100.0.0/24,192.168.2.0/24 endpoint-address=[VPS_IP] \
    endpoint-port=51820 interface=wg-starlink public-key=[VPS_PUBLIC_KEY] \
    persistent-keepalive=25s

Troubleshooting Common Issues

VPN Tunnel Not Connecting

Symptoms: No initial connection establishment Common causes:

• Incorrect endpoint configuration
• Firewall blocking VPN ports
• Key mismatch

Solutions:

1. Verify endpoint IP and port
2. Check firewall rules (allow UDP 51820 for WireGuard)
3. Regenerate and verify keys
4. Test with simplified configuration

Intermittent Disconnections

Symptoms: Tunnel connects but drops frequently Common causes:

• Starlink satellite handoffs
• Keepalive settings too aggressive
• MTU issues

Solutions:

# Adjust keepalive intervals
PersistentKeepalive = 60  # Increase from 25

# Optimize MTU
ip link set dev wg0 mtu 1380

# Monitor connection stability
watch -n 5 'wg show'

Slow VPN Performance

Symptoms: High latency or low throughput Common causes:

• Suboptimal routing
• CPU limitations
• Network congestion

Performance optimization checklist:

• [ ] Use hardware with AES-NI support
• [ ] Optimize VPN protocol (WireGuard > OpenVPN)
• [ ] Adjust encryption settings if necessary
• [ ] Monitor CPU usage during VPN operation

CGNAT IP Conflicts

Unfortunately, we’re trying to deploy Tailscale with a site-to-site configuration with our office. We have a machine on the trailer that acts as the Tailscale endpoint/subnet router and we’re able to connect to it remotely. Unfortunately, we’re trying to activate site-to-site, there’s already a dynamic route created directing 100.64.0.0/10 traffic to the router’s WAN port

Solution strategies:

1. Use non-CGNAT IP ranges for VPN (10.x.x.x, 172.16.x.x)
2. Configure static routes carefully
3. Consider IPv6 if available
4. Switch to ZeroTier for more IP flexibility

Security Best Practices

Strong Authentication Methods

Implement robust authentication:

• Use certificate-based authentication when possible
• Generate strong pre-shared keys (minimum 256-bit)
• Regularly rotate credentials
• Implement two-factor authentication where supported

Network Segmentation

Limit VPN access scope:

# Example firewall rules for VPN access
iptables -A FORWARD -s 10.100.0.0/24 -d 192.168.1.100 -p tcp --dport 22 -j ACCEPT
iptables -A FORWARD -s 10.100.0.0/24 -d 192.168.1.0/24 -j DROP

Regular Security Updates

Maintain security posture:

• Update VPN software regularly
• Monitor security advisories for your platforms
• Audit VPN logs for suspicious activity
• Test failover procedures periodically

Encryption Standards

Use modern encryption:

• WireGuard: ChaCha20-Poly1305 (recommended)
• OpenVPN: AES-256-GCM minimum
• IPsec: AES-256 with SHA-256 authentication

Key Takeaways and Recommendations

After implementing dozens of Starlink site-to-site VPN solutions, here are my strongest recommendations:

For Most Organizations

Use the cloud VPS relay method with WireGuard. It provides the best balance of reliability, cost, and performance. A $10/month VPS can easily handle multiple site connections.

For Enterprise Deployments

Consider Starlink Business if budget allows. The public IP simplifies management and provides better performance, despite higher costs.

For Quick Implementation

Deploy Tailscale for rapid setup and easy management. While it has limitations, it gets you connected quickly and works reliably behind CGNAT.

Performance Expectations

Expect 20-50ms additional latency compared to direct connections. Plan for 10-15% bandwidth overhead from VPN encryption. With proper configuration, you should achieve 80-90% of your base Starlink speeds through the VPN.

Conclusion

Ready to implement your Starlink site-to-site VPN? Start with the cloud VPS relay method using WireGuard – it’s proven to work reliably and scales well as your needs grow. Remember that while Starlink’s CGNAT presents challenges, these solutions provide robust connectivity that can rival traditional internet connections.

The key to success lies in understanding Starlink’s unique characteristics and choosing the right approach for your specific needs. Whether you’re connecting remote offices, enabling work-from-home access, or building a distributed network infrastructure, these methods will get you connected securely and reliably.

Frequently Asked Questions

Can you use a VPN with Starlink?

Yes, you can use a VPN with Starlink. Starlink supports VPNs that use TCP or UDP protocols, and the service works with most VPN providers. However, setting up a site-to-site VPN requires special configuration due to Starlink’s CGNAT implementation. For client VPN connections, simply install a VPN app on your device and connect to a VPN server as you would with any internet provider.

What’s the best VPN for Starlink satellite internet?

For site-to-site VPN with Starlink, WireGuard through a cloud VPS relay is the most reliable solution. For client VPN use, top VPN providers like ExpressVPN, NordVPN, and Surfshark all work well with Starlink. The best choice depends on whether you need site-to-site connectivity for business or just want to secure your internet traffic from a single location.

Why doesn’t traditional site-to-site VPN work with Starlink?

Starlink uses Carrier-Grade NAT (CGNAT), which means multiple users share the same public IP address. This prevents inbound connections needed for traditional VPN setups. Your Starlink router gets a private IP address (typically 100.64.x.x), making it impossible for remote sites to initiate VPN connections directly to your location without special workarounds.

Do you need a static IP address for site-to-site VPN with Starlink?

Standard Starlink residential service doesn’t provide static IP addresses, but you don’t necessarily need one. The most reliable solutions use cloud VPS relay servers with static IPs, or overlay networks like Tailscale that handle dynamic IPs automatically. Starlink Business offers publicly routable IPs (though still dynamic), which simplifies VPN setup but requires DDNS for stability.

Should you use a free VPN with Starlink?

Free VPNs work with Starlink for basic privacy, but they’re not recommended for site-to-site VPN or business use. Free services typically have bandwidth limitations, poor reliability, and limited server options. For business connectivity between remote sites via Starlink, invest in a reliable VPN solution or cloud VPS relay that costs $5-20/month for dependable performance.

How do you set up a VPN on a Starlink router?

You cannot install VPN software directly on the standard Starlink router. To use a VPN with your entire Starlink network, you need to connect a VPN-compatible router (like pfSense, UniFi, or similar) using the Starlink Ethernet Adapter. Set your Starlink router to bypass mode, then configure the VPN on your third-party router to protect all connected devices.

What causes VPN connection issues with Starlink?

Common VPN issues with Starlink include intermittent disconnections due to satellite handoffs, slower speeds from encryption overhead, and inability to host VPN servers due to CGNAT. Using appropriate keepalive settings (25-60 seconds), optimizing MTU size (typically 1380-1420), and choosing the right VPN protocol can resolve most performance issues while maintaining stable connections.