How To Install Pritunl VPN Server on Ubuntu 26.04 LTS

Ubuntu 26.04 LTS, codenamed Resolute Raccoon, was released on 23 April 2026 and is supported with standard security updates through April 2031. It is a sensible foundation for a new VPN gateway, particularly when you want a long-lived server platform rather than an interim Ubuntu release. However, Pritunl installation on Ubuntu 26.04 requires more care than a typical apt install tutorial suggests.

The important compatibility detail is that Pritunl’s current installation documentation provides a tested Ubuntu procedure for Ubuntu 24.04, using the noble repositories. The same documentation explicitly warns that future support for Ubuntu installations is not tested or guaranteed, while RHEL-compatible distributions receive Pritunl’s continuous testing and update focus.

That does not make Ubuntu 26.04 unusable. It means the administrator must validate package availability, MongoDB compatibility, OpenVPN behavior, kernel networking, and firewall rules before treating the deployment as production-ready. For a lab, homelab, temporary bastion, or low-risk internal environment, using the Ubuntu 24.04 repository packages on Ubuntu 26.04 may work. For a business VPN carrying sensitive traffic, the safer choices are either:

Use Ubuntu 24.04 LTS, which matches Pritunl’s documented Ubuntu installation path.
Use Oracle Linux 9, AlmaLinux 9, Rocky Linux 9, or another supported RHEL-compatible operating system.
Install Ubuntu 26.04 on a test node first, then promote it only after a full client and failover test.

This guide explains both the practical installation procedure and the operational decisions behind it. It covers MongoDB, repository signing, systemd services, IP forwarding, firewall design, DNS, VPN organization and user creation, TLS, performance, backups, monitoring, and the troubleshooting issues that commonly appear after the first successful login.

Table of Contents

What Pritunl Provides

Pritunl is a web-managed VPN platform built around OpenVPN and WireGuard. Instead of manually maintaining individual OpenVPN certificates, client configuration files, firewall rules, and user records, Pritunl provides a central control plane for:

VPN organizations and users.
OpenVPN and WireGuard servers.
Client profile generation.
User authentication and optional multi-factor authentication.
Network routes and DNS settings.
Multiple VPN hosts and clustered deployments.
Administrative access control.
Client connection monitoring.

Pritunl stores its application configuration and VPN metadata in MongoDB. A single-node installation can run MongoDB locally, while a larger deployment can use a dedicated or replicated MongoDB service. Pritunl’s documentation notes that all application data is stored in MongoDB, including the information required to rebuild or move a server.

A common use case is remote access to private infrastructure. For example, a small operations team may connect to a VPN subnet such as 10.20.0.0/24, then reach internal services on 192.168.50.0/24. Another organization may use Pritunl as a secure administrative bastion for SSH, database access, internal dashboards, and private Git services.

Pritunl is not automatically a complete security architecture. It does not remove the need for host patching, least-privilege access, firewall controls, log monitoring, DNS planning, or backup testing. The VPN is one security boundary, not the entire security model.

Prerequisites and Planning

Before installing Pritunl, decide whether the server is intended for testing or production.

Minimum server layout

For a small installation, a reasonable starting point is:

One public IPv4 address.
One vCPU, although two vCPUs are more comfortable.
At least 2 GB RAM for a small team.
20–25 GB of SSD-backed storage.
Ubuntu Server 26.04 LTS with a static hostname.
Root or passwordless sudo access.
A provider firewall or security group.
A DNS record such as vpn.example.com.

Pritunl’s documentation recommends high-clock-speed CPUs for VPN nodes and higher-memory instances for MongoDB. It also states that larger deployments generally perform better with several smaller VPN nodes than with a small number of oversized nodes.

The real bottleneck is usually CPU encryption capacity or network throughput, not disk space. A server with fast storage but a weak shared CPU can struggle during traffic spikes. Conversely, a VPN gateway with adequate CPU and a slow disk may still perform well because its normal workload is mostly network and cryptographic processing.

Required network ports

The exact VPN port depends on the server configuration, but a typical installation needs:

TCP 22 for SSH, preferably restricted to an administration IP range.
TCP 443 for the Pritunl web interface and possibly VPN traffic.
UDP 1194 for OpenVPN, unless you select another port.
A WireGuard UDP port if WireGuard is enabled.
TCP 80 only when using HTTP-based certificate validation or an HTTP-to-HTTPS redirect.

Do not open every port globally. The VPN service may be public, but the administrative interface should be restricted whenever possible. A cloud security group is useful as an outer firewall, while local firewall rules provide defense in depth.

Confirm the operating system

Run these checks before adding repositories:

cat /etc/os-release
uname -a
hostnamectl
dpkg --print-architecture

You should verify that the system reports Ubuntu 26.04 and that the architecture is supported by the packages you intend to install. Most cloud servers use amd64; some ARM servers may have different package availability.

Check the codename:

. /etc/os-release
printf 'Ubuntu release: %s\n' "$VERSION_ID"
printf 'Ubuntu codename: %s\n' "$VERSION_CODENAME"

On Ubuntu 26.04, the codename should be resolute. Do not replace the codename with jammy, focal, or another release simply because a random tutorial uses it.

Update and Harden Ubuntu

Start with a clean, updated server:

sudo apt update
sudo apt full-upgrade -y
sudo apt install -y ca-certificates curl gnupg lsb-release jq \
  net-tools dnsutils unattended-upgrades

Reboot if the kernel or other core packages were upgraded:

sudo reboot

After reconnecting, confirm that SSH is working before making further changes. If you administer the server remotely, keep one existing SSH session open while modifying firewall rules. That simple precaution prevents many avoidable lockouts.

Create a dedicated administrative account if the cloud provider initially supplied only a generic account:

sudo adduser vpnadmin
sudo usermod -aG sudo vpnadmin

Install your SSH public key for the new account rather than relying on password authentication. Then review /etc/ssh/sshd_config and, after testing key-based access, consider:

PasswordAuthentication no
PermitRootLogin no

Validate the configuration before restarting SSH:

sudo sshd -t
sudo systemctl reload ssh

Do not disable root login or passwords until you have confirmed that a second terminal can log in successfully using the intended administrator account.

Configure the Pritunl Repositories

The Ubuntu 26.04 compatibility warning

This is the most important part of the procedure.

Pritunl’s documented Ubuntu commands currently target Ubuntu 24.04 and use the MongoDB, OpenVPN, and Pritunl noble repositories. The official documentation does not provide a dedicated resolute repository procedure.

First, test whether repositories for resolute exist. Do not assume that they do:

curl -fsSI https://repo.pritunl.com/stable/apt/dists/resolute/Release
curl -fsSI https://repo.mongodb.org/apt/ubuntu/dists/resolute/mongodb-org/8.0/Release

A successful HTTP response does not guarantee that every package will install correctly, but a 404 confirms that a native repository is unavailable.

If native resolute repositories are not available, the documented noble packages are the only practical Ubuntu path. This is a repository compatibility workaround, not official Ubuntu 26.04 support. Test it on a disposable server before using it with real users.

Add signed repositories

Use per-repository keyrings. Avoid older tutorials that use apt-key; that mechanism is deprecated and places trust more broadly than necessary.

Create the repository files:

sudo tee /etc/apt/sources.list.d/mongodb-org.list >/dev/null <<'EOF'
deb [signed-by=/usr/share/keyrings/mongodb-server-8.0.gpg] \
https://repo.mongodb.org/apt/ubuntu noble/mongodb-org/8.0 multiverse
EOF

sudo tee /etc/apt/sources.list.d/openvpn.list >/dev/null <<'EOF'
deb [signed-by=/usr/share/keyrings/openvpn-repo.gpg] \
https://build.openvpn.net/debian/openvpn/stable noble main
EOF

sudo tee /etc/apt/sources.list.d/pritunl.list >/dev/null <<'EOF'
deb [signed-by=/usr/share/keyrings/pritunl.gpg] \
https://repo.pritunl.com/stable/apt noble main
EOF

The continuation characters in the shell heredoc are part of the repository line. If you prefer to avoid line wrapping entirely, write each entry as one physical line:

sudo tee /etc/apt/sources.list.d/mongodb-org.list >/dev/null <<'EOF'
deb [signed-by=/usr/share/keyrings/mongodb-server-8.0.gpg] https://repo.mongodb.org/apt/ubuntu noble/mongodb-org/8.0 multiverse
EOF

Download and install the signing keys:

sudo install -d -m 0755 /usr/share/keyrings

curl -fsSL https://www.mongodb.org/static/pgp/server-8.0.asc \
  | sudo gpg --dearmor --yes \
  -o /usr/share/keyrings/mongodb-server-8.0.gpg

curl -fsSL https://swupdate.openvpn.net/repos/repo-public.gpg \
  | sudo gpg --dearmor --yes \
  -o /usr/share/keyrings/openvpn-repo.gpg

curl -fsSL https://raw.githubusercontent.com/pritunl/pgp/master/pritunl_repo_pub.asc \
  | sudo gpg --dearmor --yes \
  -o /usr/share/keyrings/pritunl.gpg

Inspect the key files:

sudo ls -l /usr/share/keyrings/*pritunl* \
  /usr/share/keyrings/*mongodb* \
  /usr/share/keyrings/*openvpn*

Now update package metadata:

sudo apt update

If apt update reports a missing resolute distribution, check the repository files for accidental use of resolute. The fallback procedure intentionally uses noble, because that is the release documented by Pritunl.

Check candidate versions before installing anything:

apt-cache policy pritunl mongodb-org openvpn wireguard

Also inspect package dependencies:

apt-cache depends pritunl
apt-cache depends mongodb-org

If APT proposes removing major system packages, downgrading core libraries, or installing packages from a mixture of incompatible distributions, stop. Do not force the installation with --allow-downgrades or broad --allow-remove-essential options.

Install MongoDB and Pritunl

Install the required packages:

sudo apt install -y pritunl openvpn mongodb-org wireguard wireguard-tools

The Pritunl documentation uses MongoDB 8.0, the OpenVPN stable repository, the Pritunl stable repository, WireGuard packages, and a local MongoDB service in its Ubuntu procedure.

Enable and start MongoDB:

sudo systemctl enable --now mongod
sudo systemctl status mongod --no-pager

Then start Pritunl:

sudo systemctl enable --now pritunl
sudo systemctl status pritunl --no-pager

Confirm that both services are listening:

sudo ss -lntup | grep -E ':(27017|443)\b'

MongoDB should normally listen only on localhost for a single-node installation. Check the bind configuration:

sudo grep -nE 'bindIp|port' /etc/mongod.conf

A local database generally should not be exposed to the public internet. If mongod is listening on 0.0.0.0:27017, correct that before continuing unless you have a deliberate, authenticated, TLS-protected cluster design.

Review recent logs:

sudo journalctl -u mongod -n 80 --no-pager
sudo journalctl -u pritunl -n 80 --no-pager

If MongoDB fails to start because of an unsupported library or architecture, this is a strong indication that Ubuntu 26.04 is not yet a suitable base for this installation. At that point, move to Ubuntu 24.04 or a supported RHEL-compatible distribution rather than trying to patch around the dependency failure.

Complete the Initial Web Setup

Retrieve the Pritunl setup key:

sudo pritunl setup-key

Open the setup page in a browser:

https://vpn.example.com/

If DNS is not ready, use the server’s public IP temporarily:

https://SERVER_PUBLIC_IP/

The initial connection may display a self-signed certificate warning. That is expected during first boot, but it should not be the permanent production state.

Enter the setup key when requested. For a local MongoDB installation, the database URI is usually:

mongodb://localhost:27017/pritunl

The setup key is used during initial database setup and is not a permanent administrator credential. Pritunl’s documentation identifies the MongoDB URI in /etc/pritunl.conf and the host identity in /var/lib/pritunl/pritunl.uuid.

After the database connection is accepted, change the default administrative password immediately. Use a long, unique password stored in a password manager. If the interface offers an organization-wide or administrative MFA option, enable it before distributing VPN profiles.

Verify the configured database URI from the shell:

sudo pritunl get-mongodb

Expected output for a local installation resembles:

mongodb://localhost:27017/pritunl

Do not expose MongoDB to the internet merely because the web interface is reachable. The web interface and database have entirely different trust requirements.

Configure DNS and HTTPS

A stable DNS name is preferable to an IP address. Create an A record:

vpn.example.com.    IN    A    SERVER_PUBLIC_IP

If the server has IPv6, add an AAAA record only after confirming that IPv6 routing and firewall policy are correct. A broken AAAA record can cause some clients to wait for an unreachable IPv6 path before falling back to IPv4.

Pritunl can use a trusted certificate for the web interface. The exact certificate workflow may depend on the installed Pritunl version and your DNS or ACME setup. Before requesting a certificate, confirm:

dig +short vpn.example.com
curl -4 https://api.ipify.org

The DNS address should point to the same public IP used by the server. If you use an external reverse proxy, preserve WebSocket support and ensure that the proxy does not interfere with VPN profile downloads or administrative sessions.

A practical production arrangement is:

Restrict the Pritunl web interface to HTTPS.
Use a valid certificate for the hostname.
Redirect or block plain HTTP after certificate issuance.
Put administrative access behind an IP allowlist or a separate management VPN.
Never place the MongoDB port behind the reverse proxy.

Configure IP Forwarding and Firewall Rules

Pritunl creates VPN interfaces and routing rules as VPN servers are configured. The host still needs to be able to forward packets between the VPN interface, the public interface, and private networks.

Check forwarding:

sysctl net.ipv4.ip_forward
sysctl net.ipv6.conf.all.forwarding

Enable IPv4 forwarding persistently:

sudo tee /etc/sysctl.d/60-pritunl-forwarding.conf >/dev/null <<'EOF'
net.ipv4.ip_forward = 1
EOF

sudo sysctl --system

Enable IPv6 forwarding only if you are intentionally providing IPv6 VPN routing:

sudo tee -a /etc/sysctl.d/60-pritunl-forwarding.conf >/dev/null <<'EOF'
net.ipv6.conf.all.forwarding = 1
EOF

sudo sysctl --system

Ubuntu’s default firewall tooling can conflict with rules generated by VPN software. Pritunl’s Ubuntu instructions disable UFW, but that should not be interpreted as “run an unfiltered server.”

If your cloud provider firewall is the primary policy layer, define only the required ports there and use Pritunl’s own generated rules for VPN traffic. If you must use UFW, test carefully and do not reload it blindly after creating a VPN server:

sudo ufw status verbose
sudo iptables-save | sudo less
sudo nft list ruleset | sudo less

At minimum, your external firewall should allow SSH from trusted administration addresses and allow the selected HTTPS and VPN ports. For example, using UFW before Pritunl’s VPN rules are created might look like:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from ADMIN_IP/32 to any port 22 proto tcp
sudo ufw allow 443/tcp
sudo ufw allow 1194/udp

Do not copy these rules without replacing ADMIN_IP and confirming the actual VPN port. If Pritunl manages firewall state directly, using a cloud security group is often less surprising than repeatedly reloading UFW.

Create a VPN Server

The exact labels can vary slightly by Pritunl version, but the workflow is consistent.

Create an organization

In the web interface:

Open the Users area.
Create an organization, such as Operations.
Add users to that organization.
Require strong passwords and MFA where appropriate.

Avoid using one shared VPN account for an entire team. Individual accounts provide accountability and make revocation straightforward when someone leaves the organization.

Create the VPN server

Open the Servers area and create a server. Choose:

A descriptive name, such as prod-remote-access.
OpenVPN or WireGuard according to client and feature requirements.
A private VPN subnet that does not overlap with common home or office networks.
A UDP port that is allowed by the external firewall.
DNS servers appropriate for your users.
The routes users need to access.

Avoid common private ranges such as 192.168.0.0/24 and 192.168.1.0/24 for the VPN pool. Many residential routers use those networks, and overlapping routes produce confusing behavior. A less common subnet such as 10.77.0.0/24 is often easier to operate, provided it does not overlap with your internal networks.

If remote users need access to an internal LAN, add a route for that LAN. For example:

VPN client subnet: 10.77.0.0/24
Internal network:  192.168.50.0/24

The internal network must also know how to return traffic to the VPN subnet. You can solve that either by:

Adding a route on the internal router pointing 10.77.0.0/24 to the Pritunl server’s private IP.
Using NAT on the Pritunl server when modifying the internal router is not possible.

Routing is cleaner because internal systems can see the original VPN client address. NAT is easier in some cloud or small-office environments, but it reduces visibility and can complicate access-control logging.

Attach the organization

After creating the VPN server, attach the organization and start the server. Download a client profile for a test user and import it into the Pritunl client or a compatible OpenVPN/WireGuard client.

Test from at least two networks:

A normal broadband connection.
A mobile hotspot or another external network.

A VPN that works from inside the same cloud provider but fails from a mobile network usually has a firewall, port, protocol, or MTU problem.

Test the Connection Methodically

Do not treat a successful login as a complete test.

On the client, verify that:

ip addr
ip route
resolvectl status

You should see a VPN interface and routes corresponding to the configured VPN network.

Test the VPN gateway:

ping -c 3 10.77.0.1

Test DNS:

dig internal-service.example.com

Test a specific internal service:

nc -vz 192.168.50.20 22
curl -I https://internal-service.example.com

From the server, monitor the connection:

sudo journalctl -u pritunl -f
sudo ss -s
sudo ip -s link

Check routing and forwarding:

ip route
sudo sysctl net.ipv4.ip_forward
sudo nft list ruleset

For packet-level troubleshooting, tcpdump is invaluable:

sudo tcpdump -ni any host 10.77.0.10

Replace the address with a real VPN client address. If packets arrive on the VPN interface but never leave toward the internal network, inspect forwarding and route rules. If packets leave correctly but replies never return, inspect the internal router’s route or NAT policy.

Performance Tuning for Production

VPN performance is a combination of CPU, packet size, routing, encryption, and provider limits.

CPU and concurrency

OpenVPN encryption can become CPU-bound as concurrent traffic increases. Monitor per-process CPU usage:

top -H -p "$(pidof pritunl | cut -d' ' -f1)"

Or use:

pidstat -p ALL 1

A high CPU base clock is often more useful than many slow virtual cores for a single VPN process. If user count and throughput grow, distribute users across multiple VPN hosts rather than waiting for one server to become saturated. Pritunl’s own deployment guidance recommends multiple smaller nodes for larger installations.

Memory and MongoDB

MongoDB benefits from available memory because it uses the filesystem cache. Avoid running unrelated workloads, build systems, WordPress databases, or heavy monitoring agents on the same small VPN node.

Review memory pressure:

free -h
vmstat 1

If the host starts swapping during traffic bursts, increase RAM before changing database settings. Swap can keep a server alive, but it is not a performance solution for a latency-sensitive VPN gateway.

Network and MTU

A VPN adds encapsulation overhead. Users may report that SSH works while large file transfers, package downloads, or some websites stall. This is often an MTU or path-MTU issue.

Test progressively smaller packets:

ping -M do -s 1300 -c 3 VPN_GATEWAY_IP
ping -M do -s 1200 -c 3 VPN_GATEWAY_IP

The correct value depends on the path and protocol. Do not reduce MTU arbitrarily across the entire server. Adjust the VPN server or client configuration after confirming the problem, then retest large transfers.

Disk and logs

Monitor disk usage:

df -h
sudo du -sh /var/log/* 2>/dev/null | sort -h

A full filesystem can stop MongoDB, prevent profile generation, and cause unrelated service failures. Configure log retention and monitor /var/lib/mongodb and /var/lib/pritunl.

Security Practices That Matter

Use a minimal server installation. Every additional package increases the maintenance surface.

Apply updates regularly:

sudo apt update
sudo apt full-upgrade -y

Before upgrading Pritunl, MongoDB, OpenVPN, or the Ubuntu release, take a backup and test the upgrade on a separate instance. Do not combine an operating-system release upgrade with a VPN platform migration unless you have a documented rollback plan.

Restrict SSH:

sudo ss -lntp | grep ':22'

Use SSH keys, disable unused accounts, and review authentication logs:

sudo journalctl -u ssh --since "24 hours ago"

Enable MFA for administrative accounts and, where appropriate, VPN users. Revoke profiles immediately when an employee, contractor, or device is no longer trusted.

Do not allow users to reach every internal subnet by default. Start with the smallest route set required for their job. A VPN user who needs access to one Git server does not necessarily need unrestricted access to production databases, hypervisors, and backup systems.

If MongoDB is local, bind it to localhost. If you later move MongoDB to another host, enable authentication and protect the connection with network controls and TLS. The Pritunl documentation recommends a dedicated database server for clusters and notes that database traffic across untrusted networks should use SSL.

Back Up Pritunl Correctly

Backing up only /etc/pritunl.conf is not sufficient. The main application data lives in MongoDB.

First, verify the database URI:

sudo pritunl get-mongodb

Record the host identity as well:

sudo pritunl get-host-id

Create a database dump:

sudo mkdir -p /var/backups/pritunl
sudo mongodump --db=pritunl --out=/var/backups/pritunl/dump-$(date +%F)

Compress it:

sudo tar -C /var/backups/pritunl \
  -czf /var/backups/pritunl/pritunl-$(date +%F).tar.gz \
  "dump-$(date +%F)"

Protect the backup:

sudo chmod 600 /var/backups/pritunl/pritunl-*.tar.gz

Copy backups to storage outside the VPN server. A backup on the same disk does not protect against disk failure, accidental deletion, or a compromised host.

A restoration test is more valuable than a backup job that has never been used. Restore a recent dump to a staging MongoDB instance and verify that organizations, users, servers, and configuration data are present. Pritunl documents mongodump and mongorestore for local database backup and restoration.

Preserve the MongoDB URI and host ID during a migration. Pritunl documents commands for retrieving and setting both values, and warns that changing the host ID can make the system appear as a new cluster host.

Troubleshooting Common Errors

`apt update` returns 404 for `resolute`

This means the repository does not publish a native Ubuntu 26.04 distribution. Confirm that the Pritunl, MongoDB, and OpenVPN files use the documented noble path. If the packages still cannot be installed cleanly, stop using the 26.04 workaround and deploy Ubuntu 24.04 or a supported RHEL-compatible distribution.

`NO_PUBKEY` or signature errors

Check that the keyring exists and that the repository’s signed-by path matches it:

sudo ls -l /usr/share/keyrings/pritunl.gpg
grep -R pritunl /etc/apt/sources.list.d/

Recreate the keyring if it is empty or corrupt. Do not bypass signature verification with insecure APT options.

`mongod` fails to start

Inspect the service log:

sudo journalctl -u mongod -b --no-pager

Common causes include:

Unsupported MongoDB packages on Ubuntu 26.04.
Incorrect ownership under /var/lib/mongodb.
A full filesystem.
A malformed /etc/mongod.conf.
A stale process or damaged database files after an unclean shutdown.

Check ownership:

sudo stat -c '%U:%G %a %n' /var/lib/mongodb

Do not delete the database directory as a troubleshooting shortcut. That destroys Pritunl’s configuration and user data.

The web interface does not load

Check service state and listeners:

sudo systemctl status pritunl --no-pager
sudo ss -lntp | grep -E ':(443|9700)\b'
sudo journalctl -u pritunl -b --no-pager

Then inspect the cloud firewall, local firewall, DNS record, and TLS configuration. Testing locally can distinguish an application failure from a network failure:

curl -kI https://127.0.0.1/

If localhost works but the public address does not, investigate firewall rules, provider security groups, routing, or DNS.

Users authenticate but cannot reach internal hosts

Check all four components:

The VPN client has the expected route.
The Pritunl server has a route to the internal network.
IPv4 forwarding is enabled.
The internal network has a return route or NAT is configured.

Use:

ip route get 192.168.50.20
sudo sysctl net.ipv4.ip_forward
sudo tcpdump -ni any host 192.168.50.20

This problem is usually routing, not authentication.

OpenVPN authentication fails unexpectedly

Update Pritunl and the OpenVPN package before changing user passwords or certificates. Pritunl’s documentation notes that newer OpenVPN clients can send passwords in an encoded format that older Pritunl versions may not recognize.

Also verify that the client profile was generated after the server and organization configuration were finalized. Importing an old profile can preserve obsolete routes, ports, or certificates.

VPN is slow or unstable

Check CPU, packet loss, MTU, and provider throttling:

uptime
free -h
sar -n DEV 1 5
ip -s link

Test the VPN from another network. If only one ISP or mobile provider is affected, compare UDP and TCP behavior, check carrier-grade NAT, and confirm that the selected port is not filtered.