Vaultwarden en Proxmox: HTTPS y acceso remoto seguro

Por qué Vaultwarden en Proxmox necesita HTTPS

Vaultwarden en Proxmox necesita HTTPS porque la caja fuerte web hace todo el cifrado dentro del navegador, y el navegador solo ofrece esas funciones criptográficas en un contexto seguro. Si abres http://192.168.1.50:8000, la página carga pero no puede descifrar nada. Para una caja de contraseñas, la solución que recomiendo es HTTPS solo dentro de tu tailnet con tailscale serve. Así no abres ningún puerto en el router.

Esta guía es para quien ya tiene Vaultwarden funcionando en un contenedor LXC o en una VM de Proxmox. Muchas veces se instala con los scripts de la comunidad (Proxmox VE Helper-Scripts). Ahora quieres dos cosas: que el navegador y las apps de Bitwarden acepten la conexión, y que el móvil llegue al servidor cuando sales de casa. Comparo tres rutas según lo que exponen a internet, y explico la primera paso a paso.

Por qué el navegador rechaza http en una IP de tu red

La caja fuerte web de Bitwarden usa la Web Crypto API (crypto.subtle). Con ella deriva la clave a partir de tu contraseña maestra y cifra cada elemento. Los navegadores solo exponen crypto.subtle en un contexto seguro: una página servida por HTTPS, o por http://localhost. Una IP de tu LAN (red local) con http:// no es un contexto seguro. Por eso crypto.subtle no existe en esa página y el inicio de sesión no puede funcionar. La wiki de Vaultwarden lo dice así: la caja fuerte web usa APIs de criptografía web que la mayoría de navegadores solo ofrecen en contextos HTTPS.

Lo puedes comprobar tú mismo. Abre la consola del navegador (F12) en la página de Vaultwarden y escribe:

window.isSecureContext
typeof crypto.subtle

Por http:// en una IP verás false y "undefined". Por HTTPS con un certificado válido verás true y "object". Este mecanismo está explicado con más detalle en la guía para instalar Vaultwarden en un VPS con HTTPS, así que aquí no lo repito.

Si instalaste con el script de la comunidad, tu caso es un poco distinto. El script configura Vaultwarden con un certificado autofirmado en el puerto 8000, y te da la dirección https://IP:8000. El navegador te deja aceptar el aviso y seguir. Las apps de Bitwarden para móvil y escritorio no tienen ese botón. Ninguna autoridad en la que confíe el teléfono ha firmado ese certificado, así que la app no conecta. Necesitas un certificado de verdad, emitido para un nombre DNS (sistema de nombres de dominio) que el cliente pueda verificar.

Tres rutas, según lo que expone cada una

Antes de elegir, piensa en quién debe poder llegar a la pantalla de inicio de sesión de tu caja fuerte. Para casi todo el mundo, la respuesta honesta es: tú y tu familia, nadie más.

1. HTTPS solo en la tailnet con tailscale serve. Vaultwarden no queda expuesto a internet. Solo los dispositivos de tu tailnet (tu red privada de Tailscale) pueden abrirlo. No se usa Funnel, que es la función que publica un servicio en internet.
2. Redirección de puertos en el router, proxy inverso y DDNS (DNS dinámico). Es la respuesta habitual en los foros de Proxmox. Funciona, pero pone el inicio de sesión y la API de Vaultwarden delante de cualquier escáner de internet. Además, no funciona si tu conexión está detrás de CGNAT.
3. Un VPS pequeño como fachada pública, conectado a tu casa por WireGuard o Tailscale. Resuelve el CGNAT y oculta la IP de tu casa. El servicio sigue siendo público, y ahora mantienes dos máquinas.

Para una caja de contraseñas recomiendo la ruta 1. El resto de la guía empieza por ella.

Ruta 1: Tailscale en el LXC de Vaultwarden

Los pasos de Tailscale salen de su propia base de conocimiento, consultada en octubre de 2026. En ese momento la versión actual del cliente era la 1.102.5. La sintaxis de tailscale serve que uso existe desde la versión 1.52. Las versiones anteriores usaban otra distinta, así que los comandos copiados de un foro antiguo fallarán.

Paso 1: pasar /dev/net/tun al contenedor

Tailscale crea una interfaz de red virtual, y para eso necesita el dispositivo /dev/net/tun. Un LXC sin privilegios (unprivileged, que es lo que crea el script de la comunidad) no lo tiene por defecto. Sin él, tailscaled no puede crear la interfaz. Ejecuta esto en el host de Proxmox, como root, y cambia 105 por el ID de tu contenedor:

pct set 105 --dev0 /dev/net/tun
pct set 105 --features keyctl=1,nesting=1
pct reboot 105

Estos son los comandos que da la documentación de Tailscale para Proxmox. Ojo: --features sustituye la lista entera de opciones del contenedor, no la amplía. Si tu contenedor tenía otras opciones activadas, añádelas en la misma línea. Puedes ver las actuales con pct config 105.

Si prefieres la interfaz web, en versiones recientes de Proxmox está en Resources, Add, Device Passthrough, con /dev/net/tun como ruta del dispositivo. En Proxmox 7 se hace con dos líneas en /etc/pve/lxc/105.conf:

lxc.cgroup2.devices.allow: c 10:200 rwm
lxc.mount.entry: /dev/net/tun dev/net/tun none bind,create=file

Comprueba que el dispositivo ha llegado. Entra al contenedor con pct enter 105 y ejecuta ls -l /dev/net/tun. Debes ver una línea que empieza por c (dispositivo de caracteres) con los números 10, 200. Si dice No such file or directory, el contenedor no se ha reiniciado o la configuración tiene un error.

Si Vaultwarden está en una VM y no en un LXC, sáltate este paso. Una VM tiene su propio kernel, y Tailscale se instala como en cualquier servidor Linux.

Paso 2: instalar Tailscale y unir el contenedor a la tailnet

Dentro del contenedor ya eres root, así que no hace falta sudo. Las plantillas Debian mínimas a veces no traen curl:

apt update && apt install -y curl
curl -fsSL https://tailscale.com/install.sh | sh
tailscale up
tailscale version

tailscale up imprime una URL. Ábrela en tu navegador y autoriza la máquina en tu cuenta. tailscale version te dice qué cliente tienes. Si es anterior a la 1.52, actualiza antes de seguir.

Paso 3: el nombre de la máquina, antes de activar HTTPS

Este paso parece cosmético, pero no lo es. Cuando activas los certificados HTTPS, Tailscale los pide a Let's Encrypt para el nombre completo de la máquina, por ejemplo vaultwarden.tail1234.ts.net. Todo certificado público queda registrado en los registros de Certificate Transparency (CT), que son públicos y que cualquiera puede consultar. La documentación de Tailscale lo dice claramente: el nombre de dominio completo de tus dispositivos aparece en ese registro. También dice que no actives HTTPS si algún nombre de máquina contiene información sensible.

En la práctica significa esto: cualquiera puede saber que tu tailnet tiene una máquina llamada vaultwarden. No puede conectarse a ella, porque serve solo responde dentro de la tailnet. Pero el nombre queda publicado para siempre. Si eso te molesta, cambia el nombre de la máquina antes del paso siguiente. Se hace en la página Machines de la consola de administración, desde el menú de esa máquina. Puedes ver lo que ya está publicado buscando tu dominio de tailnet en https://crt.sh/.

Paso 4: MagicDNS y certificados HTTPS en la consola

En la consola de administración de Tailscale, abre la página DNS:

1. Comprueba que MagicDNS está activado. En las tailnets creadas desde octubre de 2022 viene activado por defecto.
2. En HTTPS Certificates, pulsa Enable HTTPS y acepta el aviso sobre el registro público.

MagicDNS es lo que da a cada máquina un nombre DNS dentro de tu tailnet. Sin él no hay nombre para el certificado, y por eso HTTPS no se puede activar.

Paso 5: tailscale serve, solo para la tailnet

Ahora conecta el nombre de la tailnet con Vaultwarden. El comando depende de cómo escucha tu instalación.

Con el script de la comunidad, Vaultwarden ya habla HTTPS en el puerto 8000 con su certificado autofirmado. Por eso el destino lleva el prefijo https+insecure://, que le dice a Tailscale que acepte ese certificado local sin verificarlo:

tailscale serve --bg https+insecure://localhost:8000

Si tu Vaultwarden escucha en HTTP plano, el destino es solo el puerto. Por ejemplo, para una instalación Docker que publica el puerto 8080 del host:

tailscale serve --bg 8080

La salida empieza por Available within your tailnet:, seguido de la URL https://vaultwarden.tail1234.ts.net/. Esa frase es la que importa: el servicio es visible dentro de tu tailnet y en ningún otro sitio. El parámetro --bg deja la configuración guardada, así que sobrevive a los reinicios. Revísala cuando quieras con tailscale serve status, y bórrala entera con tailscale serve reset.

Aquí no se usa Funnel. tailscale funnel es el comando que publica un servicio en internet a través de los servidores de Tailscale. Para una caja de contraseñas, eso te devuelve al problema de la ruta 2. Las diferencias exactas están en Tailscale Serve frente a Funnel. Si quieres más variantes de serve, por ejemplo rutas, otros puertos o apagar un único servicio, tienes la chuleta de comandos de tailscale serve.

Paso 6: DOMAIN tiene que coincidir con la URL que usan los clientes

Vaultwarden usa la variable DOMAIN para construir enlaces y para validar ciertas peticiones. La plantilla de configuración oficial dice que el dominio debe coincidir con la dirección desde la que accedes al servidor. Sin ella pueden fallar funciones como la descarga de adjuntos, los enlaces de los correos y U2F (las llaves de seguridad físicas). El valor incluye el esquema https://.

En una instalación del script de la comunidad, la configuración está en /opt/vaultwarden/.env. Añade esta línea con tu nombre real:

DOMAIN=https://vaultwarden.tail1234.ts.net

Y reinicia el servicio:

systemctl restart vaultwarden
systemctl status vaultwarden --no-pager

systemctl status debe mostrar active (running). En Docker, DOMAIN va en la sección environment del archivo compose, y después recreas el contenedor. Usa exactamente la URL que vas a escribir en las apps. Si DOMAIN dice una cosa y el cliente usa otra, el inicio de sesión puede funcionar y los adjuntos o las llaves de seguridad fallar más tarde. Ese error es mucho más difícil de diagnosticar.

Paso 7: comprobar desde otro dispositivo

Desde un portátil o un móvil con Tailscale conectado, abre https://vaultwarden.tail1234.ts.net/alive. Vaultwarden responde con una fecha y una hora. Si contesta, el certificado es válido y el proxy funciona. En la consola del navegador, window.isSecureContext ya devuelve true.

En la app de Bitwarden, en la pantalla de inicio de sesión, elige el servidor autoalojado (self-hosted). Después escribe la misma URL que pusiste en DOMAIN.

Opcional: cerrar el acceso desde la LAN

Con el script de la comunidad, Vaultwarden sigue escuchando en 0.0.0.0, es decir, en todas las interfaces. Cualquier equipo de tu red de casa todavía llega a https://IP:8000. Si quieres que la única entrada sea la tailnet, cambia este valor en /opt/vaultwarden/.env:

ROCKET_ADDRESS=127.0.0.1

Después ejecuta systemctl restart vaultwarden. tailscale serve sigue funcionando porque conecta con localhost. Desde otro equipo de la LAN, curl -k https://192.168.1.50:8000 debe fallar ahora con un mensaje que empieza por Failed to connect. Antes de hacerlo, instala Tailscale en todos los dispositivos que usan la caja fuerte. Si no, los dejarás fuera.

Qué hace el móvil cuando no llega al servidor

Con la ruta 1, el móvil solo llega a Vaultwarden mientras Tailscale está conectado. Conviene saber qué pasa cuando no lo está, porque no es un fallo total.

Según la documentación de Bitwarden, cualquier app de Bitwarden desbloqueada funciona sin conexión en modo de solo lectura. El ejemplo que dan es justo este caso: el modo avión, o no poder conectar con tu servidor autoalojado. Puedes ver y copiar tus contraseñas. No puedes crear ni editar nada, ni importar datos, porque esos cambios necesitan el servidor. También necesitas el servidor para descargar la caja fuerte la primera vez. Un móvil recién instalado no puede empezar sin conexión.

La consecuencia práctica: si vas a guardar una contraseña nueva en el móvil fuera de casa, deja Tailscale activo. La app de Tailscale en Android e iOS puede quedarse conectada en segundo plano. El tráfico hacia tu tailnet va por el túnel, y el resto sale de forma normal.

Ruta 2: redirección de puertos, proxy inverso y DDNS

Es la ruta que verás en casi todos los hilos de foro. Abres el puerto 443 del router hacia un LXC con un proxy inverso, como Caddy o Nginx Proxy Manager. Apuntas un nombre DDNS a la IP de tu casa. El proxy obtiene un certificado de Let's Encrypt. Con Caddy y el Vaultwarden del script de la comunidad, el bloque de configuración sería así:

vault.ejemplo.com {
    reverse_proxy https://192.168.1.50:8000 {
        transport http {
            tls_insecure_skip_verify
        }
    }
}

Qué expone a internet un puerto abierto

Expone la pantalla de inicio de sesión y toda la API de Vaultwarden. Eso incluye el panel /admin si tienes ADMIN_TOKEN configurado. Los escáneres automáticos encuentran un puerto 443 nuevo en cuestión de horas. Desde ese momento, cualquier fallo de Vaultwarden o del proxy se puede atacar desde fuera. Además, tu nombre DDNS apunta a la IP de tu casa, y ese nombre también acaba en los registros de Certificate Transparency.

Bitwarden cifra los elementos de la caja fuerte en el cliente, así que el servidor no guarda tus contraseñas en claro. Eso no hace que la exposición dé igual. Si eliges esta ruta, desactiva el registro de usuarios nuevos con SIGNUPS_ALLOWED=false y activa el segundo factor en todas las cuentas. Mantén también Vaultwarden y el proxy actualizados. Qué protege el diseño y qué no está explicado en el análisis de si Vaultwarden es seguro.

Cómo comprobar el CGNAT antes de planificar nada

Muchas conexiones domésticas, sobre todo de fibra y de 4G/5G, están detrás de CGNAT (NAT de nivel de operador). En ese caso tu router no tiene una IP pública propia. Comparte una con otros clientes, y la redirección de puertos nunca llega a tu casa. Haz esta comprobación antes de configurar nada.

Primero, mira la IP WAN en la página de estado de tu router. Después, desde el host de Proxmox, pregunta qué IP ve internet:

curl -4 https://icanhazip.com

Si las dos direcciones coinciden, tienes IP pública y la ruta 2 es posible. Si no coinciden, hay otro NAT entre tu casa e internet, y la redirección de puertos no funcionará. Una IP WAN en el rango 100.64.0.0/10 (de 100.64.x.x a 100.127.x.x) es la señal típica de CGNAT. Cuidado con una confusión frecuente: Tailscale también da a tus dispositivos direcciones de ese mismo rango. Una 100.x en la salida de ip addr de una máquina con Tailscale es su dirección en la tailnet, no la WAN del router.

Ruta 3: un VPS como fachada pública

Si estás detrás de CGNAT y aun así quieres una URL pública, necesitas delante una máquina que sí tenga IP pública. Un VPS pequeño recibe las conexiones en el puerto 443. Termina TLS (seguridad de la capa de transporte) con su propio certificado. Después reenvía el tráfico a tu Proxmox por un túnel WireGuard o por Tailscale. El montaje completo está en cómo publicar un servicio de casa detrás de CGNAT con un túnel inverso a un VPS.

Lo que ganas: funciona con CGNAT, y la IP de tu casa no aparece en ningún DNS. Lo que no cambia: Vaultwarden sigue expuesto a internet igual que en la ruta 2. Lo que añades: un segundo servidor que actualizar y un túnel que vigilar. Si se corta la luz o la fibra de casa, el VPS responde pero no tiene nada detrás.

La conclusión es directa: si un VPS va a estar en el camino de todas formas, normalmente es más sencillo instalar Vaultwarden en el VPS y sacar Proxmox de ese camino. Un único servidor con IP pública y una sola copia de seguridad es menos trabajo que dos máquinas y un túnel. La guía para hacerlo es Vaultwarden en un VPS con Docker y HTTPS. La ruta 3 solo tiene sentido si los datos deben quedarse físicamente en tu casa. Si dudas sobre qué servicios del homelab conviene llevar a un servidor alquilado, tienes la comparación entre Proxmox en casa y un VPS.

Qué ruta elegir para una caja de contraseñas

Para uso personal o familiar, la ruta 1 gana. No abre ningún puerto, funciona igual detrás de CGNAT, el certificado es válido para las apps y se renueva solo. Su único coste es que cada dispositivo necesita Tailscale. Las rutas 2 y 3 tienen sentido cuando debe entrar alguien que no puede instalar Tailscale. En ese caso, merece la pena pensar si el sitio correcto para Vaultwarden no es directamente un VPS.

Elijas la ruta que elijas, haz copias de seguridad del directorio de datos, que es /opt/vaultwarden/data con el script de la comunidad. Una copia del contenedor en Proxmox ayuda, pero comprueba que sabes restaurarla antes de necesitarla. El proceso completo está en cómo hacer copias de seguridad de Vaultwarden y restaurarlas.

FAQ

¿Por qué Vaultwarden no funciona por http en la IP de mi red local?

La caja fuerte web cifra y descifra en el navegador con la Web Crypto API. Los navegadores solo ofrecen crypto.subtle en un contexto seguro: HTTPS o http://localhost. En http://192.168.1.50:8000, la consola del navegador devuelve false para window.isSecureContext, así que el inicio de sesión no puede funcionar. Necesitas HTTPS con un certificado válido, por ejemplo con tailscale serve.

¿Cómo uso Tailscale en un LXC sin privilegios de Proxmox?

El contenedor necesita el dispositivo /dev/net/tun. En el host de Proxmox, ejecuta pct set <ID> --dev0 /dev/net/tun y pct set <ID> --features keyctl=1,nesting=1, y reinicia el contenedor. Dentro, ls -l /dev/net/tun debe mostrar un dispositivo de caracteres 10, 200. Después instala Tailscale con el script oficial y ejecuta tailscale up.

¿tailscale serve publica mi Vaultwarden en internet?

No. tailscale serve solo hace el servicio accesible dentro de tu tailnet, y su salida lo dice: Available within your tailnet. El comando que publica en internet es tailscale funnel, y no debes usarlo para una caja de contraseñas. Lo que sí es público es el nombre de la máquina, porque su certificado HTTPS queda en los registros de Certificate Transparency.

¿Qué pasa con la app de Bitwarden si el móvil no llega a mi servidor?

Según la documentación de Bitwarden, una app desbloqueada funciona sin conexión en modo de solo lectura. Puedes ver y copiar contraseñas, pero no puedes crear ni editar nada. Para guardar cambios, la app necesita conectar con el servidor, así que mantén Tailscale activo en el móvil.

¿Cómo sé si mi conexión está detrás de CGNAT?

Compara la IP WAN que muestra tu router con la que devuelve curl -4 https://icanhazip.com. Si no coinciden, hay otro NAT entre tu casa e internet, y abrir puertos en el router no servirá. Una IP WAN entre 100.64.0.0 y 100.127.255.255 es la señal típica de CGNAT. No la confundas con las direcciones 100.x que Tailscale da a tus dispositivos.