How to Connect Two Starlink Sites With a VPN: A CGNAT-Friendly Guide

Starlink can be a strong primary connection at a home, workshop, cabin, or remote office. Connecting two of those locations is a different problem: each site may be behind carrier-grade NAT (CGNAT), both routers may use the same private subnet, and a connection that works for browsing may still fail for private devices.

This guide shows a vendor-neutral way to plan a site-to-site VPN between two Starlink locations. It focuses on the decisions that matter before you click through a router setup wizard.

What you are building

A site-to-site VPN lets devices at Site A reach selected devices at Site B as though the two private networks were joined. Common examples include:

• Accessing a file server or NAS at the other property
• Viewing a local dashboard or home-automation service
• Reaching a printer, camera recorder, or management interface
• Allowing two small offices to share selected internal services

You do not need to route all internet traffic through the other Starlink connection. For most homes and small offices, start with only the private subnets that need to communicate.

Check the two sites before choosing a VPN

Write down the following for both locations:

1. The Starlink router or third-party router in use
2. The local subnet and router address, such as 192.168.10.0/24 and 192.168.10.1
3. Which devices or services need to be reachable
4. Whether each site has an additional router, firewall, mesh system, or access point
5. Whether either site already uses a VPN, guest network, VLAN, or remote-access overlay

Make the private subnets different

This is the most common planning mistake. If both locations use 192.168.1.0/24, a VPN router cannot tell whether 192.168.1.50 is at Site A or Site B.

Choose different ranges before you build the tunnel. For example:

• Site A: 192.168.10.0/24
• Site B: 192.168.20.0/24

Use a third range for any VPN or transit network if your chosen platform needs one. Avoid changing a working network during a busy period, and record the old settings so you can roll back.

Understand CGNAT

CGNAT means the Starlink connection may not provide a public IPv4 address that accepts unsolicited inbound connections. A traditional VPN server at Site A may therefore be unreachable from Site B, even when the server is configured correctly.

Do not start by assuming that port forwarding will solve this. First decide which of these designs matches your needs:

Option 1: An outbound overlay network

An overlay VPN is usually the simplest choice for two homes or small sites. Each device or router makes an outbound connection to the VPN coordination or relay service, so neither Starlink site needs a directly reachable public IPv4 address.

Choose this when you want:

• A quick setup with minimal router changes
• Selective access between sites
• A simple way to reach a few devices
• A design that continues to work when the WAN address changes

Install the client on supported routers, subnet routers, or individual devices. Advertise only the private subnets you need, approve the routes, and keep the default internet path local at each site unless there is a specific reason to use an exit node.

Option 2: A hub-and-spoke WireGuard design

For more control, place a WireGuard hub on a small cloud server or another location with a stable public endpoint. Both Starlink sites initiate outbound tunnels to the hub. The hub routes Site A traffic to Site B and Site B traffic to Site A.

Choose this when you need:

• Full control of keys and routing
• Predictable firewall rules
• A small number of fixed sites
• Central logging or a standard configuration you can back up

The hub must know the private subnet behind each peer. Site A should route 192.168.20.0/24 through its tunnel, while Site B should route 192.168.10.0/24 through its tunnel. Keep the hub itself on a separate transit range and do not reuse either site's LAN range.

Option 3: A direct router-to-router tunnel

A direct tunnel can work when at least one side has a reachable public endpoint or a supported relay mechanism. It is less predictable when both sides are behind CGNAT, and it may require keepalives or vendor-specific traversal features.

Use it only after confirming the addressing and reachability conditions. If the tunnel depends on inbound port forwarding at a Starlink site, treat that as a design constraint rather than an assumption.

Build the smallest useful route

Start with one service and one direction. For example:

• Site A users can reach a NAS at 192.168.20.20
• Site B users cannot reach every device on Site A
• Neither site sends normal web browsing through the remote Starlink connection

This smaller design is easier to secure and troubleshoot. Add additional routes only after the first service works.

On each site, allow only the traffic you need:

• The destination subnet or host
• The required protocol and port
• The trusted source subnet
• Established return traffic

Avoid exposing a management interface directly to the internet. A VPN route should not automatically make every router, camera, printer, or smart-home device available to every user.

Configure and test in this order

1. Export or record the current router and VPN settings.
2. Confirm the two LAN subnets are different.
3. Create the tunnel or join both sites to the chosen overlay.
4. Confirm both peers show as connected.
5. Add the route from Site A to Site B.
6. Add the return route from Site B to Site A.
7. Allow the required traffic in both site firewalls.
8. Test by IP address before testing by hostname.
9. Test one service, such as an HTTPS dashboard or file share.
10. Test again from both directions if both directions are required.

If a ping fails, that does not always mean the VPN is broken. Many devices ignore ping. Test the actual service port as well, and check the host's local firewall.

Troubleshooting checklist

The tunnel is offline

Check power, WAN access, the VPN client status, system time, and whether the site firewall blocks outbound VPN traffic. If the site uses a second router, confirm which device is actually running the VPN.

The tunnel is connected but the remote LAN is unreachable

Check the route on both sides. Then look for a missing return route, an overlapping subnet, or a firewall rule that permits the tunnel but blocks forwarding to the LAN.

One service works but another does not

Check the service host's own firewall and listening address. A service bound only to 127.0.0.1 or only to its local interface will not accept remote-LAN connections. Verify the port from the remote site and confirm that the device is awake.

Names do not resolve

Start with IP addresses. If IP access works, add a deliberate DNS plan: advertise a DNS server reachable through the tunnel, create local records, or use the VPN platform's approved naming feature. Do not assume that a hostname from one site's router will resolve at the other site.

Performance is poor

Test each Starlink site locally first, then test across the tunnel. Cross-site traffic can be limited by the slower upload path, encryption overhead, relay distance, or the destination device. Keep bulk backups and media transfers off the tunnel until the basic path is stable.

Security and recovery checklist

• Use unique administrator passwords and enable multi-factor authentication where available.
• Use separate VPN keys or device identities for each site.
• Limit routes and ports to the services that need them.
• Keep a copy of the working configuration outside the router.
• Record which subnet belongs to each site.
• Test that local internet access still works after the tunnel is enabled.
• Test a clean rollback before making the VPN a dependency for important work.
• Review connected peers and routes periodically.

Bottom line

For two Starlink locations, plan around CGNAT instead of treating it as an edge case. Give each site a unique private subnet, use an outbound overlay or a public hub when direct inbound access is unreliable, route only the services you need, and test the return path as carefully as the tunnel itself.