Proxmox: VMs sin Internet — errores comunes en vmbr0 y soluciones rápidas

Guía de diagnóstico rápido

Si estás de guardia, no quieres una lección de redes. Quieres un orden de triaje que encuentre el cuello de botella rápido. Aquí está el camino que uso: invitado → bridge → uplink → gateway → DNS. No adivines. Mide.

Primero: confirma el dominio del fallo (solo invitado, solo host o aguas arriba)

• Desde el host: ¿puede alcanzar el gateway y la Internet? Si sí, probablemente aguas arriba está bien.
• Desde una VM: ¿puede alcanzar su gateway por defecto? Si no, el problema está dentro del invitado, la vNIC, el bridge, el etiquetado VLAN o un firewall entre el invitado y el gateway.
• Desde una VM: ¿puede alcanzar una IP en Internet (por ejemplo, un resolvedor conocido) pero no nombres DNS? Si sí, es DNS o interceptación de DNS.

Segundo: verifica que vmbr0 esté transportando los tramas correctas

• ¿Tiene vmbr0 la configuración IP correcta (si es la interfaz L3 del host) y los puertos correctos (NIC física o bond como puerto de bridge)?
• ¿Están las VLAN etiquetadas donde crees que están? Los bridges con soporte VLAN de Proxmox no arreglan por arte de magia errores en el trunk.
• ¿Está habilitado el Firewall de Proxmox a nivel Datacenter / Nodo / VM con un DROP por defecto que olvidaste?

Tercero: valida el comportamiento del gateway y el MTU

• Revisa las tablas ARP y neighbor: si ARP falla, ni siquiera estás en Capa 2.
• Revisa desajustes de MTU: clásico cuando el host funciona (paquetes pequeños) y el tráfico de la VM se queda estancado (Path MTU Discovery bloqueado).
• Revisa offloads y los ajustes de bridge netfilter: pueden producir síntomas de “hace ping pero TCP está muerto”.

Deja de hacer esto: reiniciar aleatoriamente la red con la esperanza de que “reaprenda”. Los bridges no “aprenden” de esa manera; reenvían. Tu problema es determinista, aunque sea molesto.

Cómo funciona vmbr0 realmente (y por qué falla)

vmbr0 en Proxmox suele ser un bridge de Linux. Piénsalo como un switch virtual que vive en el kernel. Tus VMs se conectan a él mediante interfaces tap (por ejemplo, tap100i0) y el bridge reenvía tramas entre esos taps y un uplink físico (por ejemplo, eno1) o un bond (bond0).

El bridge es Capa 2. El enrutamiento es Capa 3. Los problemas de red en Proxmox ocurren cuando la gente difumina esa línea. Un bridge puede transportar tráfico VLAN etiquetado, pero no “rutea VLANs”. Si tu VM está en VLAN 30 y el puerto del switch aguas arriba no está en trunk para VLAN 30, tu VM no está “mal configurada”. Está aislada por diseño.

Disposiciones típicas de bridges en Proxmox

• Uplink simple con bridge: vmbr0 con bridge-ports eno1. La IP del host está en vmbr0. Las VMs comparten el mismo dominio L2.
• Bridge con soporte VLAN: vmbr0 con bridge-vlan-aware yes, y cada NIC de VM especifica una etiqueta VLAN.
• Red enrutada o NAT: un bridge separado (p. ej. vmbr1) es interno; el host hace NAT hacia vmbr0. Bueno para laboratorios, no es mi primera opción en producción salvo que quieras aislamiento intencional.
• Uplink en bond: bond0 es un puerto de vmbr0. Configurar mal el modo de bonding respecto al switch es un generador clásico de interrupciones.

Los modos de fallo suelen ser aburridos

Cuando las VMs no tienen Internet, el problema suele ser uno de estos:

• Gateway por defecto incorrecto (invitado) o ruta por defecto equivocada (host) si estás haciendo NAT/enrutamiento.
• Desajuste de VLAN (etiqueta VM vs bridge vs trunk del switch).
• Regla de firewall que descarta tráfico de reenvío.
• Bridge conectado a la NIC física equivocada (sí, en serio).
• Filtrado por MAC / seguridad de puerto aguas arriba que rechaza múltiples MACs en un puerto.
• Desajuste de MTU o PMTUD bloqueado.
• nftables/iptables o bridge-nf-call-iptables haciendo filtrado sorpresa.

Broma #1: Un bridge de Linux es como una pizarra en una sala de reuniones: todos asumen que está correcta hasta que realmente leen lo que hay escrito.

Hechos interesantes y contexto histórico (útil, no trivia)

1. El bridging en Linux existe en el kernel desde hace décadas, y los diseños iniciales asumían “reenvío L2 simple”. Las configuraciones modernas apilan VLANs, hooks de firewall y offloads encima.
2. La red de Proxmox hereda convenciones de Debian: lo que configuras en /etc/network/interfaces sigue siendo la fuente de verdad para muchas implementaciones, incluso con herramientas más nuevas disponibles.
3. Las etiquetas VLAN no son “metadatos”, son parte de la trama Ethernet. Si un puerto de switch es solo de acceso, las tramas etiquetadas suelen descartarse sin ceremonia.
4. Los modos de bonding no son intercambiables. 802.3ad (LACP) requiere una configuración LACP coincidente en el switch; active-backup no. Mezclarlos puede parecer “internet inestable” en lugar de una falla limpia.
5. Los valores por defecto de STP en el bridge importan. Habilitar STP puede prevenir bucles, pero también puede introducir retrasos de reenvío que parecen fallos aleatorios de DHCP justo después de cambios de enlace.
6. “El host tiene internet” prueba menos de lo que crees. El host puede estar enrutable de forma distinta (otra VLAN, interfaz diferente, política de firewall distinta) que las VMs.
7. La seguridad de puerto es común en redes corporativas. Los switches pueden limitar el número de MAC aprendidas en un puerto. La virtualización viola esa suposición por diseño.
8. Los desajustes de MTU son tolerables para ICMP, letales para TCP cuando PMTUD está bloqueado. La gente interpreta esto como “el DNS está roto” porque las solicitudes web se cuelgan.
9. Los hooks de bridge netfilter fueron controvertidos porque difuminan las fronteras L2/L3. Son potentes, pero hacen que el flujo de paquetes no sea evidente a menos que sepas dónde están los hooks.

Tareas prácticas: comandos, qué significa la salida y qué decidir

Estas son tareas reales que puedes ejecutar en un nodo Proxmox. Cada una da una señal. El truco es tratar las salidas como puntos de decisión, no como “información”.

Task 1: Check host routes (prove que el host tiene una ruta por defecto sensata)

cr0x@server:~$ ip route
default via 192.0.2.1 dev vmbr0 proto static
192.0.2.0/24 dev vmbr0 proto kernel scope link src 192.0.2.10

Qué significa: la ruta por defecto del host es vía vmbr0 a 192.0.2.1. Si la ruta por defecto apunta a otra parte (interfaz equivocada, ausente), tu host puede tener aún algo de conectividad por enrutado de políticas, pero tu ruta “normal” está rota.

Decisión: si falta o es incorrecta la ruta por defecto, arregla la red del host primero. No toques las VMs aún.

Task 2: Inspect bridge membership (¿el uplink está realmente en vmbr0?)

cr0x@server:~$ bridge link
2: eno1 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> master vmbr0
5: tap100i0 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> master vmbr0

Qué significa: eno1 está esclavizada a vmbr0. Si no ves tu NIC física/bond con master vmbr0, tus VMs están puenteadas a ninguna parte.

Decisión: si el uplink no es un puerto del bridge, corrige /etc/network/interfaces (o la configuración de red del nodo) y recarga la red con cuidado.

Task 3: Confirm vmbr0 configuration and VLAN awareness

cr0x@server:~$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
  address 192.0.2.10/24
  gateway 192.0.2.1
  bridge-ports eno1
  bridge-stp off
  bridge-fd 0
  bridge-vlan-aware yes
  bridge-vids 2-4094

Qué significa: la IP está en vmbr0, no en eno1. VLAN-aware está habilitado, permitiendo que el tráfico etiquetado atraviese.

Decisión: si VLAN-aware está desactivado pero etiquetas NICs de VM, o bien actívalo o bien quita etiquetas y usa VLAN de acceso en el switch. Elige uno. Mezclar intenciones crea interrupciones.

Task 4: Verify the VM NIC is attached to vmbr0 and has a VLAN tag (Proxmox view)

cr0x@server:~$ qm config 100 | sed -n 's/^net0:/net0:/p'
net0: virtio=DE:AD:BE:EF:10:00,bridge=vmbr0,tag=30,firewall=1

Qué significa: La VM 100 usa vmbr0, etiqueta VLAN 30, y el firewall de Proxmox está habilitado para esa NIC.

Decisión: si el bridge es incorrecto, arréglalo aquí. Si firewall=1, debes considerar la política de firewall como un sospechoso de primera clase.

Task 5: Confirm the VM sees a link and has an IP (inside the guest)

cr0x@server:~$ qm guest exec 100 -- ip -br addr
1: lo               UNKNOWN        127.0.0.1/8 ::1/128
2: ens18            UP             192.0.2.50/24 fe80::dcad:beff:feef:1000/64

Qué significa: la interfaz ens18 está UP con IPv4 192.0.2.50/24.

Decisión: si no hay IP, deja de culpar a vmbr0 y arregla DHCP/configuración estática en el invitado (o cloud-init).

Task 6: Check the guest’s default route (the most common “no internet” cause)

cr0x@server:~$ qm guest exec 100 -- ip route
default via 192.0.2.1 dev ens18
192.0.2.0/24 dev ens18 proto kernel scope link src 192.0.2.50

Qué significa: la ruta por defecto apunta a 192.0.2.1.

Decisión: si el gateway por defecto es incorrecto (o falta), corrige la red del invitado o el alcance DHCP. No toques el bridge aún.

Task 7: Quick reachability ladder: ARP → gateway ping → external IP ping → DNS

cr0x@server:~$ qm guest exec 100 -- bash -lc 'ip neigh; ping -c2 -W1 192.0.2.1; ping -c2 -W1 1.1.1.1; getent hosts example.com'
192.0.2.1 dev ens18 lladdr aa:bb:cc:dd:ee:ff REACHABLE
PING 192.0.2.1 (192.0.2.1) 56(84) bytes of data.
64 bytes from 192.0.2.1: icmp_seq=1 ttl=64 time=0.421 ms
64 bytes from 192.0.2.1: icmp_seq=2 ttl=64 time=0.389 ms

PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=3.12 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=3.08 ms

93.184.216.34  example.com

Qué significa: la VM tiene resolución de vecinos L2, L3 hacia el gateway, L3 hacia Internet y resolución DNS funcionando.

Decisión: si algún paso falla, ahora sabes en qué capa investigar. No te saltes pasos, porque “el DNS está roto” suele ser solo “no hay ruta”.

Task 8: Inspect ARP and forwarding database on the host (who learned whose MAC)

cr0x@server:~$ ip neigh show dev vmbr0 | head
192.0.2.1 lladdr aa:bb:cc:dd:ee:ff REACHABLE
192.0.2.50 lladdr de:ad:be:ef:10:00 STALE

cr0x@server:~$ bridge fdb show br vmbr0 | head
aa:bb:cc:dd:ee:ff dev eno1 master vmbr0
de:ad:be:ef:10:00 dev tap100i0 master vmbr0

Qué significa: el bridge aprendió la MAC de la VM en tap100i0 y la MAC del gateway en eno1. Si ves la MAC del gateway aprendida en un tap (o no aparece), tienes un bucle, cableado incorrecto o desajuste de VLAN.

Decisión: si el aprendizaje FDB es incorrecto, céntrate en el etiquetado VLAN, los puertos del bridge y la configuración del switch físico.

Task 9: Check whether Proxmox firewall is enabled and dropping forwarding

cr0x@server:~$ pve-firewall status
Status: enabled/running

cr0x@server:~$ nft list ruleset | sed -n '1,120p'
table inet filter {
  chain forward {
    type filter hook forward priority filter; policy drop;
    ct state established,related accept
    iifname "vmbr0" oifname "vmbr0" accept
  }
}

Qué significa: la política de forward es DROP por defecto (común), con una aceptación específica para tráfico intra-bridge. Si estás haciendo NAT (vmbr1 → vmbr0), necesitas forwards explícitos.

Decisión: si el ruleset descarta el reenvío, ajusta las reglas del firewall PVE o desactiva temporalmente el firewall para confirmar que es la causa (luego vuelve a activarlo con la política correcta).

Task 10: Validate bridge netfilter sysctls (the “why is my bridge being firewalled?” trap)

cr0x@server:~$ sysctl net.bridge.bridge-nf-call-iptables net.bridge.bridge-nf-call-ip6tables net.bridge.bridge-nf-call-arptables
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-arptables = 0

Qué significa: los frames bridged IPv4/IPv6 se envían a los hooks de iptables/nftables. Eso puede ser correcto, o puede ser un triturador accidental de paquetes si pensabas “bridge = switch = sin firewall”.

Decisión: si no filtras intencionalmente tráfico bridged, considera desactivar estos hooks. Si filtras, audita las reglas cuidadosamente y documenta.

Task 11: Check MTU end-to-end (VM, bridge, uplink)

cr0x@server:~$ ip -br link show vmbr0 eno1
vmbr0            UP             00:11:22:33:44:55 <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
eno1             UP             00:11:22:33:44:55 <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500

cr0x@server:~$ qm guest exec 100 -- ip -br link show ens18
ens18            UP             de:ad:be:ef:10:00 <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500

Qué significa: MTU coincide en 1500. Si la VM tiene MTU 1500 pero el uplink es 9000 (o viceversa), puedes obtener conectividad parcial extraña dependiendo del tráfico.

Decisión: elige una estrategia MTU y aplícala de forma consistente: 1500 en todas partes, o jumbo frames en todas partes incluyendo los puertos del switch aguas arriba. El medio-jumbo es una gran forma de desperdiciar una tarde.

Task 12: Detect “it pings but TCP dies” with a DF ping

cr0x@server:~$ qm guest exec 100 -- ping -c2 -M do -s 1472 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1472(1500) bytes of data.
1472 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=3.24 ms
1472 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=3.18 ms

--- 1.1.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms

Qué significa: la MTU de camino al menos 1500 funciona. Si obtienes “Frag needed and DF set”, tienes un desajuste de MTU o un túnel en el camino.

Decisión: si el ping con DF falla, arregla el MTU o permite PMTUD (ICMP too-big) a través de los firewalls. No “arregles” reduciendo MSS a ciegas a menos que controles el entorno y documentes el hack.

Task 13: Check for MAC address limits / port security symptoms (from host perspective)

cr0x@server:~$ journalctl -k --since "30 min ago" | egrep -i 'mac|flood|storm|blocked|bond|link' | tail -n 20
Dec 26 09:21:07 server kernel: vmbr0: port 2(eno1) entered blocking state
Dec 26 09:21:07 server kernel: vmbr0: port 2(eno1) entered forwarding state

Qué significa: los logs del kernel no te dirán directamente “tu switch está aplicando seguridad de puerto”, pero los cambios frecuentes de estado de puerto o flapping se verán.

Decisión: si sospechas seguridad de puerto, habla con el equipo de redes. Tu host Proxmox no es un endpoint con una sola MAC; es una fábrica de MACs. Configura el switch en consecuencia.

Task 14: Packet capture on vmbr0 and on the tap (prove VLAN tagging and DHCP)

cr0x@server:~$ tcpdump -eni vmbr0 -c 10 '(arp or (udp port 67 or 68) or icmp)'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on vmbr0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
08:15:11.120001 de:ad:be:ef:10:00 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request
08:15:11.220112 aa:bb:cc:dd:ee:ff > de:ad:be:ef:10:00, ethertype IPv4 (0x0800), length 342: 192.0.2.1.67 > 192.0.2.50.68: BOOTP/DHCP, Reply

Qué significa: ves petición y respuesta DHCP. Si las peticiones DHCP salen de la VM pero no vuelven respuestas, la VLAN aguas arriba, el relay o el firewall está mal. Si ves tramas etiquetadas cuando esperabas sin etiquetar (o al revés), encontraste el desajuste.

Decisión: las capturas de paquetes terminan discusiones. Úsalas temprano cuando el equipo esté atascado en “debería funcionar”.

Task 15: Validate NAT configuration (if you built a private vmbr1)

cr0x@server:~$ ip -br addr show vmbr1
vmbr1            UP             10.10.10.1/24

cr0x@server:~$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

cr0x@server:~$ nft list ruleset | sed -n '1,200p' | egrep -n 'nat|masquerade|postrouting|forward' | head -n 20
42: table ip nat {
55:   chain postrouting {
58:     oifname "vmbr0" ip saddr 10.10.10.0/24 masquerade

Qué significa: vmbr1 existe, el reenvío está activado y hay una regla de masquerade para NATear tráfico saliendo por vmbr0.

Decisión: si los invitados en vmbr1 no tienen Internet, NAT es un sospechoso principal. O lo arreglas o dejas de usar NAT y empleas VLANs/enrutamiento adecuado como una red adulta.

Task 16: Check Proxmox-specific network device naming and bonds

cr0x@server:~$ cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
MII Status: up
Active Aggregator Info:
        Aggregator ID: 1
        Number of ports: 2
Slave Interface: eno1
MII Status: up
Slave Interface: eno2
MII Status: up

Qué significa: el bond es LACP (802.3ad) y ambos esclavos están up. Si el bond muestra “Number of ports: 1” inesperadamente, o los esclavos están flapeando, probablemente la configuración LACP del switch no coincide con la tuya.

Decisión: si el modo de bonding y la configuración del switch no están alineados, no “tunes”. Alinea. Para producción, o haces LACP correctamente en ambos extremos o te quedas con active-backup por simplicidad.

Errores comunes: síntoma → causa raíz → solución

Esta es la parte que le reenvías a tu yo del futuro.

1) Síntoma: El host tiene Internet, las VMs no pueden alcanzar el gateway

Causa raíz: VM conectada al bridge equivocado, o el bridge no tiene puerto uplink físico, o un desajuste de etiqueta VLAN impide la vecindad L2.

Solución: verifica que qm config NIC use bridge=vmbr0; verifica con bridge link que la NIC física sea master vmbr0; verifica la configuración VLAN de extremo a extremo (etiqueta VM, bridge VLAN-aware, trunk/access en el switch).

2) Síntoma: La VM puede hacer ping al gateway, no puede hacer ping a IP externa

Causa raíz: falta de ruta más allá del gateway (gateway del invitado equivocado), ACL aguas arriba, o NAT/enrutamiento mal configurado si la VM está en un bridge privado.

Solución: revisa la ruta por defecto del invitado; si es diseño NAT, verifica ip_forward y la masquerade; confirma que el gateway aguas arriba haga ruta de retorno al subred de la VM (si está enrutable).

3) Síntoma: La VM puede hacer ping a 1.1.1.1 pero el DNS falla

Causa raíz: servidores DNS inaccesibles, resolv.conf equivocado, systemd-resolved apuntando al stub equivocado, o interceptación DNS corporativa + reglas de firewall.

Solución: verifica getent hosts, revisa /etc/resolv.conf en el invitado, asegúrate de que UDP/TCP 53 esté permitido y que el DHCP entregue los resolvedores correctos para esa VLAN.

4) Síntoma: DHCP caduca en la VM, la IP estática funciona

Causa raíz: falta el trunk para esa VLAN, retraso STP al subir el enlace, problema de DHCP snooping/relay, o firewall bloqueando broadcasts DHCP.

Solución: tcpdump en vmbr0 para DHCP; habilita bridge-fd 0 a menos que necesites STP; coordina con el equipo de redes sobre snooping/relay; asegúrate de que el firewall de la VM no bloquee DHCP.

5) Síntoma: Algunas VMs funcionan, otras no, en el mismo host

Causa raíz: etiquetas VLAN por VM diferentes; firewall por VM diferente; conflicto de MAC; IP duplicada; o una VM está en otro bridge.

Solución: compara qm config entre VMs; busca IP duplicadas con arping o la tabla neighbor; audita ajustes de firewall a nivel de VM.

6) Síntoma: Funciona para pings pequeños, HTTPS se cuelga o va lento

Causa raíz: desajuste MTU o PMTUD bloqueado; a veces comportamientos raros de checksum offload con ciertos drivers/firmware de NIC.

Solución: prueba con ping DF; alinea MTU; permite ICMP too-big; si sigue raro, prueba deshabilitar GRO/LRO/TSO en la NIC del host como diagnóstico.

7) Síntoma: La conectividad muere tras habilitar el Firewall de Proxmox

Causa raíz: política por defecto DROP en la chain forward, faltan reglas allow, o hooks de bridge netfilter activados con reglas inesperadas.

Solución: revisa reglas nftables; ajusta reglas del firewall PVE; mantén una línea base mínima “allow established + allow vmbrX forwarding” y construye desde ahí.

8) Síntoma: Las VMs pierden conectividad cuando otro host se conecta, o durante una migración

Causa raíz: seguridad de puerto aguas arriba limitando conteo de MAC, o switch no esperando múltiples MACs detrás de un solo puerto, o hashing de LACP con flujos asimétricos.

Solución: configura el puerto de switch para virtualización (permitir múltiples MACs, desactivar seguridad estricta de puerto o aumentar los límites), verifica LACP en ambos extremos, considera active-backup si el equipo de redes no soporta bien LACP.

Tres micro-historias corporativas (anónimas, plausibles, técnicamente precisas)

Micro-historia 1: El incidente causado por una suposición equivocada

El equipo heredó un pequeño clúster Proxmox de un proyecto que “nunca llegó a producción”. Lo trasladaron a un rack de producción, enchufaron dos puertos 10GbE a un par de switches top-of-rack y montaron bond0 en 802.3ad porque “es la forma profesional”. Los switches tenían puertos configurados como puertos de acceso independientes con una VLAN estándar. Nadie lo dijo al equipo de virtualización. Tampoco al equipo de redes, porque todos asumieron que era obvio.

El host tenía conectividad intermitente. Las VMs estaban peor: a veces resolvían DNS pero no podían descargar paquetes; a veces el ping al gateway funcionaba; a veces ARP parecía stale. Olía a enlace ISP inestable, que siempre es una mentira tentadora porque te permite dejar de pensar.

El punto de inflexión fue una captura en el uplink mostrando ráfagas de retransmisiones y luego silencio, correlacionado con mensajes de negociación LACP que nunca se estabilizaban. En el host, /proc/net/bonding/bond0 mostraba una interfaz “up” con un slave activo, luego cambiaba. La suposición equivocada fue pensar que LACP es inofensivo si el switch no lo soporta. No es inofensivo; es un protocolo de negociación que espera un compañero.

Lo arreglaron cambiando el bond a active-backup temporalmente, restaurando la estabilidad en minutos, y luego planificaron con el equipo de redes desplegar un port-channel LACP adecuado. La revisión del incidente fue corta y algo dolorosa: el sistema se comportó exactamente como se configuró. Los humanos fueron la parte impredecible.

Micro-historia 2: La optimización que salió mal

Un ingeniero preocupado por el rendimiento notó mayor uso de CPU en los nodos Proxmox en horas pico. Las interrupciones de red subieron. También hubo picos de latencia en una VM API muy concurrida. Decidió “optimizar la red” habilitando jumbo frames en el uplink del hipervisor y en vmbr0. La red de almacenamiento ya usaba jumbo, así que parecía coherente.

Cambiaron MTU a 9000 en vmbr0 y en las NICs físicas. El host parecía bien. Las VMs empezaron a reproducir comportamientos extraños: los pings ICMP funcionaban, pero los handshakes TLS se atascaban. Los paneles de monitorización eran una pieza de arte moderno de fallos parciales. El ingeniero supuso que el cambio de MTU no podía ser responsable porque “paquetes más grandes reducen overhead”. Eso es cierto solo si todo el camino está de acuerdo.

Los puertos del switch aguas arriba seguían a 1500. Peor aún, el firewall de red estaba configurado para descartar mensajes ICMP fragmentation-needed. PMTUD no pudo hacer su trabajo, así que las sesiones TCP colgaban al intentar enviar segmentos mayores. El DNS parecía intermitente porque los reintentos del cliente se retrasaban y los timeouts se malatribuyeron.

La solución no fue heroica: volver a 1500 en vmbr0 y en las vNICs de las VMs, y luego planificar jumbo frames correctamente con validación extremo a extremo y política ICMP alineada. La lección es antigua: la optimización sin medición es solo cambio. A veces cambio costoso.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Otra organización ejecutaba nodos Proxmox en múltiples sitios, cada uno con vendors de switch y layouts VLAN ligeramente diferentes. Tenían una regla simple: cada nodo Proxmox debe tener una única red de gestión “conocida buena” en vmbr0 sin etiquetar, y cada red de VM debe estar etiquetada con VLANs explícitas en un bridge con soporte VLAN. Sin excepciones, sin puertos de acceso “temporales”.

Suena pedante. También significó que cuando un sitio reportó “VMs sin Internet”, el equipo verificó inmediatamente trunks y etiquetas VLAN en lugar de reescribir configuraciones de red. La IP de gestión del host permaneció accesible, porque no montaba encima del mismo lío etiquetado que las redes de tenants.

Durante un reemplazo de switch, un puerto trunk fue configurado por error como access VLAN 10 en lugar de trunk. El síntoma apareció al instante: todas las VMs en VLAN 30 en ese nodo perdieron conectividad, pero el nodo seguía accesible por gestión. La captura mostró tramas etiquetadas saliendo de vmbr0 y desapareciendo en el puerto de acceso. El diagnóstico duró minutos, no horas.

La práctica aburrida fue la separación de responsabilidades: conectividad de gestión estable, VLANs explícitas para invitados y una checklist estándar tras cambios de red. No es glamoroso. Es como evitas tocar la alarma fuera de horas por una tecla mal puesta en la plantilla del switch.

Broma #2: Lo único más persistente que una VLAN mal etiquetada es una invitación a reunión sobre la VLAN mal etiquetada.

Listas de verificación / plan paso a paso

Paso a paso: Arreglar “La VM no tiene internet” sin empeorar la situación

1. Elige una VM afectada y úsala como canario. No cambies configuraciones al azar en todos los invitados a la vez.
2. Dentro de la VM: verifica IP, subred, gateway, DNS. Confirma ip route y getent hosts.
3. Desde la VM: haz ping al gateway, haz ping a IP externa, resuelve un nombre DNS. Registra exactamente qué falla.
4. En el host: confirma que vmbr0 tiene el puerto uplink y los ajustes VLAN correctos.
5. Revisa el estado del firewall: estado del firewall Proxmox, flag firewall de la NIC de la VM, política forward en nftables.
6. Confirma la vecindad L2: tabla neighbor del host y entradas FDB del bridge para la MAC de la VM y la del gateway.
7. Realiza una captura dirigida: tcpdump en vmbr0 para ver flujo ARP/DHCP/ICMP; confirma etiquetas si procede.
8. Revisa MTU: verifica MTU consistente; ejecuta ping DF hacia Internet.
9. Solo entonces cambia configuración, una dimensión a la vez: VLAN, regla de firewall, ruta, NAT, MTU.
10. Valida y documenta el estado final funcionando: configuración del bridge, expectativas del puerto del switch y política de etiquetado de VMs.

Patrones “conocidos buenos” para vmbr0

Patrón A: Red de acceso sin etiquetar para host y VMs (bueno para laboratorios pequeños; limitado para multi-tenant):

cr0x@server:~$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
  address 192.0.2.10/24
  gateway 192.0.2.1
  bridge-ports eno1
  bridge-stp off
  bridge-fd 0

Patrón B: Bridge con soporte VLAN y redes de invitados etiquetadas (lo que recomiendo cuando tienes redes reales):

cr0x@server:~$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
  address 192.0.2.10/24
  gateway 192.0.2.1
  bridge-ports eno1
  bridge-stp off
  bridge-fd 0
  bridge-vlan-aware yes
  bridge-vids 2-4094

Patrón C: Red privada de VMs con NAT (usar con moderación, documentar fuertemente):

cr0x@server:~$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
  address 192.0.2.10/24
  gateway 192.0.2.1
  bridge-ports eno1
  bridge-stp off
  bridge-fd 0

auto vmbr1
iface vmbr1 inet static
  address 10.10.10.1/24
  bridge-ports none
  bridge-stp off
  bridge-fd 0

Para el Patrón C, aún necesitas reglas de forwarding y NAT. Si no puedes explicarlas al siguiente ingeniero on-call en menos de un minuto, estás construyendo una interrupción, no una red.

Checklist operacional tras cambios (el que la gente omite)

• ¿Puede el host alcanzar el gateway, resolver DNS y obtener paquetes?
• ¿Puede una VM en cada VLAN alcanzar su gateway, una IP externa y resolver DNS?
• ¿Las entradas ARP están estables (no constantemente incompletas)?
• ¿Un ping DF a 1472 bytes funciona hacia una IP externa?
• ¿La política del firewall de Proxmox está documentada (qué se permite, qué es DROP por defecto)?
• ¿Está registrada la configuración del puerto del switch (access vs trunk, VLANs permitidas, límites de MAC, LACP)?

Una cita sobre fiabilidad (idea parafraseada)

Idea parafraseada, atribuida a W. Edwards Deming: “No puedes mejorar lo que no mides”.

Preguntas frecuentes (FAQ)

1) ¿Por qué el host tiene Internet pero las VMs no?

Porque el host y las VMs pueden no compartir la misma ruta de red. El host puede estar sin etiquetar en vmbr0 mientras las VMs están etiquetadas, o las reglas de firewall pueden tratar el tráfico reenviado de forma distinta al tráfico local del host.

2) ¿La IP del host debe estar en eno1 o en vmbr0?

En vmbr0, en el diseño puenteado común. Pon eno1 en modo manual y hazlo puerto del bridge. Asignar IP a eno1 mientras también lo bridgées es una configuración clásica de “más o menos funciona hasta que deja de funcionar”.

3) ¿Necesito “bridge-vlan-aware yes” si no uso etiquetas VLAN?

No. Si todo está sin etiquetar y el puerto del switch es de acceso, mantenlo simple. Activa VLAN awareness solo cuando realmente etiquetes NICs de invitados o necesites trunks.

4) Mi VM tiene IP, pero no puede salir. ¿Cuál es la comprobación única más rápida?

Revisa la ruta por defecto de la VM: ip route. Si el gateway por defecto es incorrecto o falta, nada más importa hasta que se arregle eso.

5) ¿Es seguro habilitar el Firewall de Proxmox?

Sí, si entiendes sus políticas por defecto y dónde se aplica (Datacenter, Nodo, VM/NIC). Se vuelve inseguro cuando alguien lo habilita con un DROP por defecto y sin reglas de forwarding, y luego se va el fin de semana.

6) ¿Cuándo debo usar NAT para el acceso a Internet de las VMs?

Cuando deliberadamente quieres una red privada no enrutable para las VMs y aceptas que el host Proxmox se convierta en router/firewall. Para entornos productivos con múltiples VMs, las VLANs y el enrutamiento adecuado suelen ser más claros y fáciles de depurar.

7) ¿Por qué veo peticiones DHCP en tcpdump pero no respuestas?

Normalmente por problemas de trunk VLAN (VLAN permitida equivocada), DHCP snooping/relay mal configurado o reglas de firewall que bloquean broadcasts/UDP. Si la petición sale de la VM y aparece en vmbr0, el lado del invitado está bien.

8) ¿Un desajuste de MTU puede realmente causar “sin internet”?

Sí, de manera engañosa. Tráfico pequeño (pings, cierto DNS) puede funcionar mientras TCP se queda colgado. Usa pings DF y alinea MTU extremo a extremo, o permite los mensajes ICMP de PMTUD.

9) ¿Debo desactivar offloads (GRO/LRO/TSO) en la NIC?

No por defecto. Pero como diagnóstico, puede aislar interacciones extrañas de driver/firmware. Si desactivar offloads “arregla” el problema, trata eso como una pista: actualiza firmware/drivers y valida las características del switch en lugar de convivir con un workaround permanente.

10) ¿Cuál es la forma más limpia de manejar múltiples redes en Proxmox?

Una red de gestión estable (a menudo sin etiquetar), más bridges con soporte VLAN para redes de invitados con etiquetas explícitas por NIC de VM. Mantén la configuración de los puertos del switch documentada y consistente entre nodos.

Conclusión: pasos siguientes para evitar repeticiones

Cuando las VMs Proxmox no tienen Internet, casi nunca es “misterio de la virtualización”. Es una descoordinación predecible entre lo que la VM envía, lo que vmbr0 reenvía y lo que acepta la red aguas arriba. El camino más rápido a la resolución es dejar de tratarlo como magia y empezar a tratarlo como una tubería.

Haz lo siguiente:

• Estandariza tu patrón de bridge: elige sin etiquetas o VLAN-aware+y etiquetado. No ejecutes ambos por accidente.
• Escribe las expectativas del switch: trunk/access, VLANs permitidas, límites de MAC, modo LACP. Si no está escrito, es folklore.
• Mantén una VM canaria con configuración de red conocida y un script de pruebas simple (ping al gateway, ping IP externa, lookup DNS, ping DF).
• Audita la postura del firewall: conoce dónde existe un DROP por defecto y asegura que las reglas de forwarding coincidan con tu diseño (bridgeado, enrutado o NAT).
• Haz del MTU una decisión de política, no una perilla. 1500 en todas partes está bien. Jumbo frames en todas partes está bien. “En medio” es donde viven los incidentes.

Si quieres un único consejo práctico: captura paquetes cuanto antes. Nada pone fin a un debate como ver tramas que salen y no vuelven.