Proxmox VE remote access, done safely

Why not just forward port 8006?

The Proxmox web interface is a full administration console: it can delete VMs, change storage, and open a root shell on the host. Anything exposed to the internet gets probed constantly, so a weak password, a reused password or a future vulnerability would give an attacker the whole machine – and everything running on it. There is nothing an outsider needs on port 8006, so the safe answer is not to expose it.

The same goes for SSH on the host (22), SPICE (3128) and Proxmox Backup Server (8007).

1. Reach it over a VPN

A VPN puts your laptop or phone on your home network, so you can use https://<host>:8006 exactly as you do at home.

• WireGuard – follow the WireGuard guide. A small Debian container on the Proxmox host itself works well as the VPN server; current Proxmox kernels include the WireGuard module. Forward one UDP port (51820) to it.
• Tailscale – works behind CGNAT with no port forwarding. Install it on the host or in a container and enable subnet routing to your LAN.

2. Give the host a real name

Browsers always use HTTPS for .app names, so a name for Proxmox needs a certificate they trust. The name itself can point at the host’s private LAN address – it only has to work for you, at home or on the VPN.

1. In the uk.app DNS settings, add an A record: host pve, value your Proxmox host’s LAN address, for example 192.168.1.5.
2. Check from home: nslookup pve.yourname.uk.app should return that address.

3. A trusted certificate without opening any port

Proxmox’s built‑in ACME client (Datacenter → ACME) can use HTTP validation, which would need port 80 open to the host, or DNS validation with the providers bundled from acme.sh. uk.app’s hook is a separate download rather than a bundled plugin, so the simplest way is to run acme.sh on the host yourself and have it install the result where Proxmox looks for a custom certificate.

You need a uk.app API token with the read and write:records scopes from my.uk.app/tokens. Then, as root on the Proxmox host:

apt install unzip
curl https://get.acme.sh | sh -s email=you@example.com
curl -fsSLO https://uk.app/downloads/ukapp-tools.zip && unzip ukapp-tools.zip
install -m 755 ukapp.py /usr/local/bin/ukapp
cp dns_ukapp.sh ~/.acme.sh/dnsapi/
install -m 600 /dev/null /root/.ukapp-api-token && nano /root/.ukapp-api-token

export UKAPP_TOKEN="$(cat /root/.ukapp-api-token)"
~/.acme.sh/acme.sh --issue --server letsencrypt --dns dns_ukapp --dnssleep 300 -d pve.yourname.uk.app

~/.acme.sh/acme.sh --install-cert -d pve.yourname.uk.app --ecc \
  --fullchain-file /etc/pve/local/pveproxy-ssl.pem \
  --key-file /etc/pve/local/pveproxy-ssl.key \
  --reloadcmd "systemctl restart pveproxy"

/etc/pve/local is the node’s own folder in the cluster file system, and pveproxy-ssl.pem / pveproxy-ssl.key are the file names Proxmox uses for a custom certificate. The self‑signed certificate Proxmox created at install time stays in place underneath and is used again if you delete these two files. Now https://pve.yourname.uk.app:8006 opens with a padlock, on the LAN or over the VPN.

For automatic renewal, use the wrapper from the HTTPS guide so the renewal job has the API token. In a cluster, repeat the steps on each node with its own name.

If you really must expose it

Sometimes a VPN isn’t possible – a locked‑down work laptop, say. If you decide to publish the interface anyway, reduce the risk as far as you can:

• Turn on two‑factor authentication for every account (Datacenter → Permissions → Two Factor, TOTP or WebAuthn), and don’t use root@pam for daily work.
• Restrict source addresses in /etc/default/pveproxy with ALLOW_FROM, DENY_FROM and POLICY if you connect from known networks, then restart pveproxy.
• Put it behind a reverse proxy with its own authentication rather than forwarding 8006 directly, and enable the Proxmox firewall.
• Watch the authentication log (journalctl -u pvedaemon) for failed logins, and consider fail2ban.

Even with all of that, a VPN remains the better answer.

Dynamic DNS for the VPN

The VPN endpoint needs a public name that follows your IP, separate from the private pve record above. Point home.yourname.uk.app at your public address with a DDNS token – from your router (OpenWrt), your NAS, or a cron job in the VPN container (see the start guide). Only that record changes when your IP does; pve keeps pointing at the LAN address.

Check it

1. Nothing web‑facing is open: run the port checker against your public IP on 8006. It should say closed or filtered.
2. The VPN works: on mobile data, connect the VPN and open https://pve.yourname.uk.app:8006.
3. The certificate is right: the browser should show a padlock with no warning. Check expiry dates in (node) → System → Certificates. The public SSL checker can’t reach a private address, which is exactly what you want here.