--- title: Self-Hosting a VPN Behind CGNAT and a Dynamic IP | OpenVPN Blog description: "Before you install anything: check whether your ISP gives you a real public IP. If it doesn't, no amount of port forwarding will save you. Here's what to do." image: https://blog.openvpn.net/hubfs/Hobbyists-1250x360-5.png --- - [Blog](https://blog.openvpn.net) - [Zero Trust](https://blog.openvpn.net/tag/zero-trust) - [self-hosted](https://blog.openvpn.net/tag/self-hosted) - [ztna](https://blog.openvpn.net/tag/ztna) # Self-Hosting a VPN Behind CGNAT, a Dynamic IP, and a Consumer Router Oct 16, 2026 • 9 min read ![](https://blog.openvpn.net/hubfs/Hobbyists-1250x360-5.png) Share - - - - Self-Hosting a VPN Behind CGNAT and a Dynamic IP | OpenVPN Blog 10:08 By Heather Walters ## What you definitely need to check first. Most guides to self-hosting a VPN start with installing the server. That's the wrong place to start, because there's a precondition that decides whether any of it will work, and a meaningful number of people don't meet it. Here it is: a VPN server at home has to accept incoming connections. Which means the internet needs a way to reach it. If your ISP hasn't given you a routable public IP address, it doesn't have one, and nothing you do inside your network can change that. So let's do the checks first, then the setup. ## Check one: do you actually have a public IP? Two numbers, and they need to match. - Log into your router and find the WAN or internet IP address. - Visit any "what's my IP" service from a device on that network. If they match, you have a routable public address and you're fine. If they don't match, your ISP is putting you behind carrier-grade NAT. Your router's WAN address is on the ISP's internal network, not the internet. A useful tell: CGNAT addresses usually fall in 100.64.0.0/10 — anything starting 100.64. through 100.127. is a giveaway. Addresses starting 10., 172.16.–172.31., or 192.168. on your WAN interface mean the same thing. ## Why port forwarding can't fix CGNAT Because the forward you'd need isn't on your router. With CGNAT, hundreds or thousands of customers share one public address, and the ISP's equipment decides which internal customer each inbound packet belongs to. Your router can forward port 1194 from its WAN interface all it likes — traffic from the internet never reaches that interface, because the ISP's NAT has nowhere to send it. There's no entry in their translation table for connections you didn't initiate. This is why outbound things work perfectly and inbound things don't work at all. Browsing, streaming, downloads, and mesh VPNs are all fine. A server is not. Common on: Starlink, most mobile and 5G home internet, many fibre providers outside the US, and increasingly plenty of cable operators. Some ISPs will move you off CGNAT or sell you a static IP if you ask — worth one phone call before giving up. ## Check two: does your address change? Most residential connections hand out addresses by DHCP, so yours will change — after a reboot, an outage, or on the ISP's own schedule. The fix is dynamic DNS: a service that keeps a hostname pointed at your current address. A small client on your network or router notices the change and updates the record, so your VPN clients connect to homelab.example.net rather than a number that stops working on a Tuesday. Set this up before the VPN. It's the thing people forget and then spend an evening debugging while away from home, which is the worst possible time to discover it. ## The setup, briefly Assuming you passed both checks. Sizing. A small deployment is genuinely small: 2 vCPUs, 4 GB of RAM, and a 25 GB disk is comfortable for a homelab. A Proxmox guest, a spare mini PC, or a Raspberry Pi will all do it. Update the OS fully before installing anything. Two ports through the firewall. Forward both to the VM: - UDP 1194 — VPN traffic - TCP 443 — the client web interface where users download their profile, and TCP VPN traffic, Miss either and clients won't connect. Every router vendor calls port forwarding something slightly different, so this is the step where you'll be reading your own router's documentation rather than ours. The certificate warning is expected. Access Server ships with a self-signed certificate, so the first time you open the admin interface your browser will complain. That's normal, not a misconfiguration — click through for now. When you want it gone properly, the docs cover issuing a real certificate with Let's Encrypt via certbot, which also stops your users seeing the same warning. Your upload speed is the ceiling. Everything you pull from home goes out through your upload link, which on most residential connections is a fraction of the download figure. Fine for admin, SSH, and file access. Less fine if you were planning to stream 4K to three people simultaneously. Check your actual upload rate before assuming. ## If you're behind CGNAT You have three options, in rough order of hassle. Ask your ISP for a public IP. Sometimes free, sometimes a small monthly fee, sometimes flatly refused. One phone call. Put the server somewhere with a public address. A cloud VM has a static IP and no NAT problem, and you connect your home network to it. This works well and you keep full control of the server — the trade is that you're now paying for a VM and your traffic takes a longer path. Use a cloud-delivered service instead. This is the honest answer for most people in this situation. CloudConnexa needs no inbound port at all — a lightweight connector on your network makes an outbound connection to us, which CGNAT permits happily, and clients reach your network through that. No port forwarding, no dynamic DNS, no public IP required. The free tier here is five seats rather than Access Server's two simultaneous connections — a seat being a person, with several devices each. So for a household behind CGNAT this is both the only option that works and the more generous one. All features, no card. The decision between the two products still isn't really commercial — it's this. Public IP and want everything on your own hardware? Self-host. Behind CGNAT? Cloud-delivered, and you're running in minutes rather than fighting your ISP. That's a genuine trade-off rather than a free upgrade, and it's worth stating exactly: with the cloud-delivered option, we run both the control plane and the data plane. We're not only coordinating the connection — your traffic crosses our infrastructure. For most homelabs, that's a fine trade for something that works behind CGNAT when nothing else will. But if you came to self-hosting specifically because you didn't want a third party in the path, that's the thing CloudConnexa doesn't give you, and the cloud VM route above does — you'd be running Access Server on a machine you control, with a public IP, and both planes stay yours. Worth reading what a control plane actually knows before deciding which of those you actually want. ## The short version - Compare your router's WAN IP against a "what's my IP" service. Different? You're behind CGNAT. - Behind CGNAT: ask your ISP, use a cloud VM, or use a cloud-delivered service. Port forwarding will not help. - Public IP that changes? Set up dynamic DNS first. - Forward UDP 1194 and TCP 443. - Expect the self-signed certificate warning; fix it with Let's Encrypt when you're ready. - Remember your upload speed is the real limit. ### Ready to see how OpenVPN can help protect your organization from attacks? Try the self-hosted Access Server solution or the managed CloudConnexa service for free, no credit card required. [See Which One is Right for You](https://openvpn.net/product-comparison/?_gl=1*1hi46u*_ga*NDgyODEwNDkyLjE3NzIxMjIzNDE.*_ga_E45Z33NTV7*czE3Nzc5ODY2ODIkbzExMiRnMSR0MTc3Nzk4ODMyMSRqNTUkbDAkaDE4NzIyNTczNDc.*_fplc*dVltNzJ6YmZ0bFZTdld4NjRtWVpVWXclMkJEV3AzZGhPUlRZaUppdWNxQkRjOER3MFN0VW84JTJCdEJGdnRDTmVYNlI5NlJBdTRLZ0VGOTNHMHc0U3l3bVFsR3NzQXk5RzJIQVdzNHE0QVJHcSUyQlVKUlRsNTM0S1RWZERyZ0V4NDNnJTNEJTNE*_gcl_au*MTM5NjEwNTIxNy4xNzcyMTIyMzQx*_ga_SPGM8Y8Y79*czE3Nzc5ODY2ODEkbzExMyRnMSR0MTc3Nzk4ODMyMyRqNTMkbDAkaDA.) ## Frequently asked questions ### Can you run a VPN server behind CGNAT? Not a server that accepts inbound connections, no. Carrier-grade NAT means you don't have a routable public address, so there's nothing for clients on the internet to connect to, and port forwarding on your own router can't change that. Your options are to get a public IP from your ISP, host the server on a cloud VM instead, or use a cloud-delivered or mesh service that works by making an outbound connection rather than accepting an inbound one. ### How do you know if your ISP uses CGNAT? Compare the WAN IP address shown in your router's admin interface against what a "what's my IP" website reports. If they differ, you're behind CGNAT. Another strong indicator is a WAN address in the 100.64.0.0/10 range — anything from 100.64.x.x to 100.127.x.x is reserved specifically for carrier-grade NAT. ### Do you need a static IP to host a VPN? No. You need a routable public IP, but it doesn't have to be static. If it changes, a dynamic DNS service keeps a hostname pointed at the current address so your clients can still find the server. Static IPs are more convenient, and most ISPs will sell you one, but dynamic DNS is free and works fine. ### What ports does OpenVPN Access Server need open? Two ports, forwarded from your router to the server: UDP 1194 for VPN traffic, and TCP 443 for the client web interface where users download their connection profile. The admin interface listens on TCP 943, but there's no reason to expose that to the internet — reach it from inside your network instead. ### How do you fix the self-signed certificate warning? Replace the default self-signed certificate with one from a real certificate authority. Let's Encrypt is free and the usual choice, issued via certbot, and it requires a hostname pointing at your server — which you'll already have if you set up dynamic DNS. Until then the warning is cosmetic rather than a sign of anything broken, though your users will see it too, which is reason enough to fix it. ### Can you run a VPN server on a Raspberry Pi? Yes, comfortably for a homelab. A Pi 4 or 5 with 4 GB of RAM handles a couple of concurrent connections without difficulty. The limiting factor is almost never the Pi — it's your home upload bandwidth. Use decent storage rather than a tired microSD card, since the OS will be doing real work. ### Does a VPN let me reach my NAS without exposing it to the internet? Yes, and that's the main reason to use one. Instead of forwarding your NAS's web interface to the public internet — where it gets scanned continuously — you connect to the VPN and reach the NAS on its local address as though you were sitting at home. Nothing about the NAS is publicly reachable. Only the VPN port is exposed, and that's a much smaller thing to defend. [Heather Walters](https://blog.openvpn.net/author/heather-walters) Heather is a writer for OpenVPN. ## Related posts from OpenVPN ### Subscribe for Blog Updates ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "Heather Walters", "url" : "https://blog.openvpn.net/author/heather-walters" }, "dateModified" : "2026-10-16T17:00:00.185Z", "datePublished" : "2026-10-16T17:00:00.000Z", "headline" : "Self-Hosting a VPN Behind CGNAT and a Dynamic IP | OpenVPN Blog", "image" : [ "https://blog.openvpn.net/hubfs/Hobbyists-1250x360-5.png" ], "mainEntityOfPage" : { "@id" : "https://blog.openvpn.net/self-hosted-vpn-cgnat-dynamic-ip-home-router", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "https://blog.openvpn.net/hubfs/Dark=True%20Medium.png" }, "name" : "OpenVPN" } } ```