Best Self-Hosted VPNs With a Web UI for Ubuntu Server — Compared by NAT, Ports, and Setup
Choose a self-hosted VPN by web interface, public reachability, required ports, team size, and the amount of server maintenance you want.
Quick Answer
WG-Easy is the best self-hosted VPN with a web UI for one Ubuntu server and a small number of users. Choose NetBird for teams and mesh routing, AmneziaVPN when an app-driven deployment matters more than a browser dashboard, and OpenVPN Access Server when older clients and centralized user administration are the priority. Headscale is an advanced control-plane option, but it does not include a web UI. If the Ubuntu host is behind CGNAT or cannot receive an inbound UDP port, place the VPN endpoint on a public VPS.
Find the right self-hosted VPN in four choices
Pick the operating model first. The tool changes the software recommendation, public-port expectation, and server placement without pretending that every UI solves the same problem.
Describe the VPN you need
The recommendation updates as you change the operating model and network path.
WG-Easy
It keeps the moving parts small: WireGuard, a focused browser UI, QR/config export, and a single main tunnel listener.
- Public ports
- Allow the configured WireGuard UDP port. Keep the web admin private or publish it only through authenticated HTTPS.
- Placement
- Run the NAT/CGNAT preflight before installing. If public reachability is unclear, a small public VPS is the predictable placement.
Best self-hosted VPN solutions for Ubuntu Server
“VPN server,” “web UI,” and “mesh control plane” are different layers. This table keeps the interface, connection path, and required public listeners separate.
| Option | Best for | UI | Connection path | Public ports | Model |
|---|---|---|---|---|---|
WG-Easy Best overall | One server, family, or homelab | Focused browser admin | Direct WireGuard endpoint | One public UDP listener; protect the admin UI separately | Open source |
NetBird | Teams, policies, and multiple networks | Browser dashboard | Direct mesh when possible, relay when needed | TCP 80/443 and UDP 3478 in the current quickstart; confirm the full deployment list | Open-source self-hosted platform |
AmneziaVPN | App-driven deployment to your server | Desktop or mobile app, not a web UI | Direct endpoint using the selected protocol | Protocol-dependent; the app configures the selected stack | Open-source apps and server components |
OpenVPN Access Server | Older clients and centralized user administration | Admin and Client web interfaces | Direct OpenVPN endpoint | TCP 443/943 and UDP 1194 by default; confirm active services | Commercial product with two free concurrent connections |
Headscale plus a community UI | Advanced Tailscale-compatible control | No built-in UI; community component required | Direct peer path with DERP fallback support | Control-plane HTTPS plus any separately hosted relay requirements | Open source |
Decide the connection path before installing a VPN server
A polished UI cannot create an inbound path through CGNAT. Compare the router WAN address with the public address reported by our NAT and public-IP checker, then choose the placement below.
Public address reaches the router
Home hosting can work. Reserve the Ubuntu LAN address, forward only the chosen tunnel port, mirror the rule in UFW, and verify from an external network.
WAN is private or in 100.64.0.0/10
Suspect double NAT or CGNAT. Confirm it with the CGNAT check guide; a public VPS is the predictable endpoint when the ISP boundary cannot be changed.
Direct peer path is unreliable
Use a public hub or a mesh design with relay fallback. Keep “direct,” “relayed,” and “publicly reachable” as separate states when diagnosing performance.
Five UIs, five different operating models
WG-Easy: the simplest WireGuard web UI
WG-Easy combines a WireGuard server with a focused web interface. Administrators can create, edit, disable, download, and scan client configurations, see usage, and add two-factor authentication without turning a small VPN into a full identity platform.
- Choose when
- Choose it for a personal server, family, small lab, or one public VPS where simple peer administration is the main job.
- Avoid when
- Skip it when the project needs organization-wide identity, granular policy, automatic multi-site routing, or a relay-aware mesh.
NetBird: dashboard, identity, routes, and mesh
NetBird adds users, groups, access policies, network routes, DNS, setup keys, and relay-assisted connectivity around WireGuard. Its browser dashboard answers the team-management questions that a simple peer list does not.
- Choose when
- Choose it when several administrators or networks need repeatable enrollment and policy instead of hand-managed configuration files.
- Avoid when
- Skip it for a single server when the extra services, domain, ports, and identity layer would create more maintenance than value.
AmneziaVPN: deploy from an app, not a web panel
AmneziaVPN is the outlier in this list: its open-source desktop or mobile app connects to a Linux server and deploys a chosen VPN protocol. That reduces terminal work, but it is not a browser-based multi-admin dashboard.
- Choose when
- Choose it when the closest possible experience to installing an app and following prompts matters more than web administration.
- Avoid when
- Skip it when several administrators need a shared browser console, policy model, or clearly documented fixed port matrix.
OpenVPN Access Server: mature clients and user administration
OpenVPN Access Server provides an Admin Web UI and a Client Web UI on Ubuntu, centralized profiles and users, and broad OpenVPN client support. Two concurrent connections are included free; larger use is licensed.
- Choose when
- Choose it for compatibility, controlled user provisioning, and an established OpenVPN workflow.
- Avoid when
- Skip it when the goal is a fully open-source stack, a minimal footprint, or WireGuard-first performance with no connection license.
Headscale: control plane first, UI second
Headscale is a self-hosted control server for Tailscale-compatible clients. The project explicitly has no built-in web interface, so every community UI adds its own version compatibility, authentication, exposure, and update work.
- Choose when
- Choose it when you already understand the client/control-plane model and accept composing and maintaining the management UI separately.
- Avoid when
- Do not choose it solely because the search query says “with UI”; WG-Easy or NetBird is a more honest default for that requirement.
Do you need a VPS for the self-hosted VPN?
Keep the existing Ubuntu server when it already has a stable public path. When CGNAT, a changing home address, or a locked router is the concrete pain, a public VPS replaces the missing inbound path with a fixed public endpoint, gives you control of several TCP and UDP ports, and keeps client profiles pointed at one address.
One prerequisite
Vultr
The practical default when the old Ubuntu host is behind CGNAT, has a changing address, or cannot reserve the VPN port.
- Ubuntu cloud images and full root control
- Cloud firewall rules keep the public listener explicit
- Global locations make a nearby endpoint easier to choose
- Eligible new users can use the current $300 credit for 30 days
DMIT
The route-focused alternative when the path between East Asia and North America matters more than a very broad region catalog.
- Los Angeles, Hong Kong, and Tokyo locations
- Routing profiles aimed at trans-Pacific paths
- KVM instances with full root control
- A fixed public endpoint with ports you manage
How to set up WG-Easy on Ubuntu Server
Use the current, release-matched official WG-Easy instructions for the Compose file. The stable implementation sequence below remains valid even when image tags or environment names change.
- 1
Choose a reachable placement
Use the home Ubuntu server only when it has a usable public path and you control the router. With CGNAT, a locked router, or an unreliable public address, use a public VPS.
- 2
Prepare Ubuntu and a stable endpoint
Update Ubuntu, install Docker using its official instructions, point a DNS name at the public address if desired, and decide how the web admin interface will stay private or sit behind HTTPS.
- 3
Install the current WG-Easy release
Follow the release-matched WG-Easy Docker Compose guide, set the public WireGuard host, create strong admin credentials, and start the container without exposing an unauthenticated admin interface.
- 4
Open the WireGuard path once
Allow the selected WireGuard UDP port in Ubuntu and the cloud firewall. On a home server, forward the same UDP port from the router to the Ubuntu host.
- 5
Create and import a client
Create one named client in the UI, download its configuration or scan the QR code, and import it into the official WireGuard app on a device outside the server network.
- 6
Verify the handshake and route
Connect over mobile data or another external network, confirm a recent WireGuard handshake, and test the private service address. A loaded admin page alone does not prove the UDP tunnel works.
Protect the admin UI independently
Verify the service, listener, handshake, and route
Run the checks in order. A UDP “port open” website is not conclusive for WireGuard because the protocol does not answer unauthenticated probes like a normal TCP service.
Ubuntu verification commands
Adjust the Compose service name and UDP port if the current release or your configuration differs.
sudo docker compose ps
sudo ss -lunp | grep 51820
sudo docker compose logs --tail=100
sudo wg show1. Process
The container or system service is healthy.
2. Listener
Ubuntu is listening on the expected UDP port.
3. Handshake
wg show reports a recent authenticated peer handshake.
4. Route
The client can reach the intended private address or subnet.
Fix the first broken layer, not every VPN setting
If the home router cannot accept the connection at all, compare a public hub, mesh, and reverse path in our remote access without port forwarding guide. If the protocol choice is still open, use the OpenVPN vs WireGuard comparison before changing the server stack.
| Symptom | Check first | Focused fix |
|---|---|---|
| The client has no handshake | Endpoint address, UDP listener, cloud firewall, and router path | Make every layer use the same UDP port; test from mobile data, not the server LAN. |
| Handshake works but no private service opens | AllowedIPs, forwarding, return route, and host firewall | Trace the tunnel address first, then the destination subnet; do not change the public port. |
| The web UI opens but the VPN does not | Whether only TCP 443 reaches the server while WireGuard UDP is blocked | Treat the admin page and the tunnel as two separate listeners and verify both. |
| The tunnel drops after idle time | The client is behind NAT and the latest handshake ages out | Use PersistentKeepalive on the NATed client when the connection must remain reachable. |
| Small requests work but larger transfers stall | Tunnel MTU and nested VPN or mobile paths | Lower MTU methodically and retest; do not assume the port is closed after a valid handshake. |
Self-hosted VPN for Ubuntu Server questions
Official documentation used for this guide
Product capabilities, current deployment prerequisites, port examples, UI status, and the Access Server free connection limit were checked against these first-party sources on August 6, 2026.