Native Windows VPN to a Home Server Behind CGNAT: The Cloud Relay Method

Windows ships with a VPN client. For some setups, that native client is the one you need. A specific corporate policy, a preference for built-in tools, or a protocol requirement can all be the reason. The problem is CGNAT. Most home connections have no public IP for that client to dial into directly.

Why Native Windows VPN Can’t Reach a Home Server Behind CGNAT

Native Windows VPN only connects outward to a server; it cannot accept inbound connections from a server sitting behind CGNAT. Your ISP shares one public IP among many customers, so nothing can reach your home router directly. A cloud relay solves this by giving the VPN a real public IP to connect to.

This is a fundamentally different problem than the one Tailscale solves. Tailscale devices dial out to a coordination server and negotiate a peer-to-peer path. Neither end needs to accept an inbound connection. Windows’ native IKEv2 and SSTP clients were not built that way. They expect a server address to connect to, and CGNAT means your home router has none worth connecting to.

If Tailscale would work for your use case, it is the easier path. This guide covers the specific case where you need the native Windows client itself. That means not just VPN-style access to your home network.

The Architecture: A Cloud VPS as the Rendezvous Point

The fix uses two tunnels meeting at one cheap cloud VPS. Windows connects to the VPS over IKEv2, since the VPS has a real public IP. The VPS then forwards that traffic across a second tunnel. That WireGuard tunnel is built outbound from your home server, reaching past the CGNAT from the inside.

Neither the Windows client nor the home server ever needs to accept an inbound connection. Only the VPS does, and it has a real public IP built for exactly that. Our guide on how NAT works covers the translation concepts this design routes around.

Step 1: Set Up the VPS as the IKEv2 Endpoint (strongSwan)

A small Ubuntu VPS with a public IP becomes the VPN endpoint. Install strongSwan, generate a server certificate, and configure ipsec.conf for IKEv2 with a client address pool. Windows’ native client authenticates against this certificate, so no separate software is required on the Windows side.

Install strongSwan and its PKI tools, then generate a root CA and a server certificate whose subject name matches the VPS’s domain or IP address:

apt update && apt install strongswan strongswan-pki libcharon-extra-plugins

ipsec pki --gen --type rsa --size 4096 --outform pem > caKey.pem
ipsec pki --self --ca --lifetime 3650 --in caKey.pem \
  --dn "CN=NetworkCheckr Relay CA" --outform pem > caCert.pem

ipsec pki --gen --type rsa --size 2048 --outform pem > serverKey.pem
ipsec pki --pub --in serverKey.pem | ipsec pki --issue \
  --cacert caCert.pem --cakey caKey.pem \
  --dn "CN=vps.example.com" --san "vps.example.com" \
  --flag serverAuth --outform pem > serverCert.pem

Copy the certificates into /etc/ipsec.d/. Then define the connection in /etc/ipsec.conf with keyexchange=ikev2, a client address pool like rightsourceip=10.10.10.0/24, and rightauth=pubkey for certificate-based login. strongSwan’s own Windows interoperability documentation covers the exact proposal settings Windows expects. Open UDP 500 and UDP 4500 on the VPS firewall for IKEv2 and its NAT traversal.

Step 2: Build the Outbound Tunnel from Home to the VPS (WireGuard)

Your home server initiates the WireGuard connection to the VPS, not the other way around. That single outbound direction is what gets past CGNAT. A PersistentKeepalive setting holds the connection open so the VPS can send traffic back at any time.

Generate a WireGuard key pair on both the VPS and the home server, then configure the home side to dial out to the VPS’s public IP:

[Interface]
PrivateKey = <HOME_PRIVATE_KEY>
Address = 10.200.200.2/24

[Peer]
PublicKey = <VPS_PUBLIC_KEY>
Endpoint = <VPS_PUBLIC_IP>:51820
AllowedIPs = 10.200.200.1/32
PersistentKeepalive = 25

On the VPS side, the matching peer block lists your home LAN subnet in AllowedIPs. That tells the VPS to route that traffic through the tunnel. A subnet mismatch here is the single most common misconfiguration. Our subnetting guide covers the CIDR math if your home LAN range is unfamiliar.

Step 3: Route Traffic Between the Two Tunnels

The VPS needs to connect the IKEv2 clients to the WireGuard tunnel, not just host both separately. Enable IP forwarding, then add the home LAN subnet to the WireGuard peer’s allowed IPs. That one setting is what makes the two tunnels act as a single path.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i wg0 -j ACCEPT
iptables -A FORWARD -o wg0 -j ACCEPT
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE

This is the step that turns two separate tunnels into one working path. Without it, the VPS happily terminates both connections but never forwards a single packet between them. Test forwarding with a simple ping from the VPS to a device on your home LAN. Do this before touching the Windows side at all.

Step 4: Add the Native VPN Connection on Windows

On the Windows side, open Settings, Network and internet, VPN, and add a connection. Choose Windows built-in as the provider and IKEv2 as the type. Point the server address at the VPS, select certificate authentication, and Windows handles the rest with no extra app installed.

Import the client certificate first. Use certmgr.msc to place it under Personal certificates and the CA under Trusted Root Certification Authorities. Microsoft’s own VPN client configuration guide covers this import step in detail. Once the certificate is in place, the VPN connection screen picks it up automatically.

Testing the Full Path

Connect the Windows VPN first, then ping the WireGuard tunnel address on the VPS to confirm that hop works. Next, ping a device on the home LAN itself. If the first ping succeeds but the second fails, the problem sits in the routing between the two tunnels.

Working through the path in order isolates the fault instead of guessing. A successful IKEv2 connection with no reachable VPS tunnel address points at strongSwan or the firewall. A reachable VPS but an unreachable home device points at the forwarding rules or the AllowedIPs mismatch from Step 2.

SSTP as a Fallback When IKEv2 Is Blocked

Some networks, especially hotel and corporate Wi-Fi, block the UDP ports IKEv2 needs. SSTP runs entirely over TCP port 443, the same port as ordinary HTTPS traffic. That lets it pass through almost every firewall. Configure it as a second VPN profile pointed at the same VPS.

SSTP is Windows-only, which is not a drawback here. The entire point of this guide is the native Windows client. Add a second connection profile in the same Settings menu, selecting SSTP instead of IKEv2. Point it at the same VPS address and certificate. Keep both profiles, and switch between them depending on the network you’re on.

Cost, Maintenance, and When to Use Tailscale Instead

A VPS for this setup typically costs $4 to $6 a month. The tradeoff is maintenance: certificate renewals, security patches, and two tunnels to keep healthy. If you do not specifically need Windows’ native client, our Tailscale guide covers a setup with far less ongoing work.

Be honest about which problem you’re actually solving. If the goal is reaching a home server, our guide on accessing your home network with Tailscale gets there faster. No VPS, no certificates, and no manual routing required. Reach for this cloud-relay approach specifically when the native Windows client itself is the requirement.

Frequently Asked Questions

Related Tools & Resources

These guides cover the concepts and simpler alternative behind this project. NAT and CGNAT mechanics, subnet math for the tunnel configuration, and the Tailscale path most people should try first.

References

These sources back every technical claim in this guide. They include official Microsoft Learn documentation for the native VPN client. They also include strongSwan’s own Windows interoperability docs and WireGuard’s site-to-site configuration references. Each protocol’s behavior is documented directly by its maintainers, not by a secondary summary.