Problema

En entornos con Proxmox, es frecuente que los administradores puedan conectarse a una VM desde la consola del host (por ejemplo, usando qm terminal) pero no desde otro equipo de la misma red. Los síntomas típicos incluyen:

  • ssh: connect to host X.X.X.X port 22: No route to host
  • Mensajes de “key exchange identification” o “Connection closed by remote host” al intentar abrir una sesión SSH.
  • Imposibilidad de acceder a la interfaz web de la VM (puerto 80/443) desde clientes externos.
  • El host Proxmox también muestra problemas de conectividad hacia dispositivos fuera de su VLAN.

Estos fallos aparecen aunque el host y las VMs aparecen “running” en qm list, la configuración de red del host parece correcta y el firewall de Proxmox está habilitado sin reglas explícitas.

Causa

Los orígenes más habituales de este tipo de bloqueo son:

  1. Puente de red mal configurado o inactivo
    Proxmox usa vmbr0 (u otro bridge) para exponer las interfaces de las VMs a la red física. Si el bridge no está enlazado a la NIC física, o si la NIC está en modo “down”, las VMs quedan aisladas aunque el host tenga conectividad.

  2. Política de firewall a nivel de bridge o VM
    El firewall integrado (pve-firewall) puede estar activo y aplicar reglas por defecto que niegan tráfico entrante, incluso sin reglas visibles en la UI. Además, reglas en iptables o nftables creadas por paquetes de terceros pueden interferir.

  3. Problemas de VLAN / etiquetado
    Cuando la NIC del host está configurada para una VLAN específica, pero la VM usa una VLAN distinta (o ninguna), el tráfico se descarta en el switch. Cambios de hardware (p.ej. sustitución de PSU) pueden provocar que la NIC vuelva a su configuración de fábrica, perdiendo la etiqueta VLAN.

  4. ARP y tabla de encaminamiento corrupta
    Después de un reinicio inesperado o de una sustitución de hardware, la tabla ARP del switch o del host puede quedar con entradas obsoletas, provocando “no route to host” aunque la ruta exista.

  5. MTU incompatibles
    Si la MTU del bridge difiere de la de la NIC física (por ejemplo, 1500 vs 9000), los paquetes pueden fragmentarse o ser descartados, generando cierres de conexión silenciosos.

  6. Restricciones de seguridad del switch
    Algunas switches aplican “port security” o “BPDU guard” que bloquean puertos que detectan cambios de MAC inesperados, lo que ocurre cuando una VM toma la MAC de la NIC del host al reiniciar.

Solución

1. Verificar estado del bridge y de la NIC física

ip link show vmbr0
ip addr show vmbr0
ethtool -i eth0   # sustituir eth0 por la NIC real
  • vmbr0 debe estar UP y tener la dirección IP del host.
  • La NIC física asociada (eth0 o ens18) debe estar UP y sin errores.
  • Si el bridge está “DOWN”, levántalo con ifup vmbr0 o reinicia el servicio de red: systemctl restart networking.

2. Comprobar configuración de VLAN

Revisa /etc/network/interfaces o los archivos bajo /etc/network/interfaces.d/. Un ejemplo típico:

auto vmbr0
iface vmbr0 inet static
    address 192.168.10.10/24
    bridge_ports eth0.100
    bridge_stp off
    bridge_fd 0
  • Asegúrate de que la sub‑interfaz (eth0.100) coincide con la VLAN configurada en el switch.
  • Si la VM necesita una VLAN distinta, crea una segunda sub‑interfaz o usa vlan en la definición de la VM.

3. Desactivar temporalmente el firewall de Proxmox

pve-firewall stop
iptables -F
nft flush ruleset
  • Si la conectividad vuelve, el problema está en alguna regla implícita. Reactiva el firewall y revisa pve-firewall status y los archivos bajo /etc/pve/firewall/.

4. Revisar tablas ARP y rutas

ip neigh show
ip route show
  • Busca entradas “FAILED” o “INCOMPLETE”. Elimina con ip neigh del <IP> dev <iface> y permite que se regenere.
  • En el switch, verifica la tabla MAC y, si es necesario, limpia la caché.

5. Probar con MTU homogénea

ip link set dev vmbr0 mtu 1500
ip link set dev eth0 mtu 1500
  • Si la red física soporta jumbo frames, ajusta ambos lados al mismo valor (p.ej. 9000).

6. Confirmar que la VM tiene una MAC única y no está colisionando con la del host

qm config <VMID> | grep net
  • Cambia la MAC si coincide con la del host: qm set <VMID> -net0 e1000,mac=XX:XX:XX:XX:XX:YY.

7. Verificar políticas del switch

  • Asegúrate de que el puerto al que está conectado el host no tenga “port security” que limite el número de MACs.
  • Si el switch soporta LLDP, revisa que no esté bloqueando tráfico por “BPDU guard”.

Cuándo aplicar esta solución

  • Síntomas: SSH o HTTP a VMs falla desde cualquier host externo, mientras que la consola KVM funciona; el propio Proxmox también muestra “no route to host” a equipos de la misma VLAN.
  • Entorno: Proxmox 6/7 o versiones posteriores, con bridges basados en NIC físicas, VLANs configuradas y firewall habilitado.
  • No aplica: Cuando la VM está apagada, cuando el problema se limita a un solo cliente con firewall local, o cuando la red física está caída (cable desconectado, switch offline).

Código

# 1. Estado del bridge y NIC
ip link show vmbr0
ip addr show vmbr0
ethtool -i eth0

# 2. Reiniciar servicios de red y firewall
systemctl restart networking
pve-firewall stop
iptables -F
nft flush ruleset

# 3. Limpiar ARP y forzar re‑aprendizaje
ip neigh flush all
arp -d -i vmbr0 192.168.10.20   # IP de la VM

# 4. Forzar MTU uniforme
ip link set dev vmbr0 mtu 1500
ip link set dev eth0 mtu 1500

# 5. Ver y cambiar MAC de la VM
qm config 101 | grep net
qm set 101 -net0 e1000,mac=DE:AD:BE:EF:00:01

Verificación

  1. Desde otro host de la misma VLAN, ejecuta ssh -v user@<IP_VM> y verifica que la negociación de claves avanza sin “no route to host”.
  2. Abre un navegador y accede a http://<IP_VM> o https://<IP_VM>; la página debe cargar.
  3. En el host Proxmox, comprueba ping <IP_VM> y traceroute <IP_VM> para confirmar rutas.
  4. Re‑activa el firewall (pve-firewall start) y revisa que las reglas necesarias (por ejemplo, ACCEPT en in para puertos 22, 80, 443) estén presentes.

Notas adicionales

  • Después de cambiar hardware (PSU, NIC, etc.) siempre revisa la configuración de la NIC en /etc/network/interfaces. Algunos servidores vuelven a cargar una configuración predeterminada que elimina etiquetas VLAN.
  • Mantener una copia de la configuración de red (cp /etc/network/interfaces /root/interfaces.bak) facilita la comparación tras incidentes.
  • Si utilizas lxc junto a qemu, recuerda que los contenedores comparten el mismo bridge; una regla que bloquee tráfico en lxc también afectará a las VMs.
  • Documenta cualquier regla de firewall personalizada en /etc/pve/firewall/ para evitar sorpresas al actualizar Proxmox.