VLANs en Linux con nmcli: Guía Completa 2026

octubre 12, 2026 Alfonso Moreno | Sysadmin Senior 24 Visitas 14 min de lectura

Segmentar la red con VLANs 802.1Q dejó de ser un lujo empresarial hace rato. En un homelab con Proxmox, OPNsense, UniFi o MikroTik, separar el tráfico de servidores, IoT, invitados y gestión es una de las prácticas de seguridad más baratas que existen: un cable, varios segmentos lógicos, y un firewall que decide qué pasa entre ellos. Un dispositivo IoT comprometido (un enchufe, una cámara barata) queda contenido en su VLAN sin acceso al resto.

La pregunta real para un sysadmin moderno ya no es si usar VLANs, sino cómo configurarlas en Linux sin pelearse con nmcli, networkd, systemd-networkd o los scripts de Netplan de Ubuntu. Esta guía recorre las tres formas soportadas en 2026 (NetworkManager, netplan + networkd, e ifupdown clásico), con ejemplos de configuración para trunk (múltiples VLANs por interfaz) y acceso (una VLAN por interfaz), y los gotchas que aparecen cuando tu switch no negocia correctamente la VLAN nativa o tu trunk se rompe después de un reboot.

TL;DR — Lo que vas a tener al final

Tiempo de setup: 30 minutos por interfaz trunk, 2 horas para configurar 3–4 VLANs en un homelab típico
Requisitos: Linux con NetworkManager o netplan, un switch administrable (managed) con soporte 802.1Q, cable Ethernet entre switch y servidor
Resultado: Trunk con N VLANs en una interfaz, segmentos de red aislados con su propio rango DHCP, comunicación selectiva entre VLANs vía firewall
Troubleshooting típico: VLAN nativa mal configurada rompe el trunk (solución: en Linux la nativa suele ser untagged, configurar igual en el switch o usar una VLAN de gestión dedicada), nmcli no levanta la subinterfaz tras reboot (solución: connection.autoconnect yes y connection.autoconnect-priority 10), networkd y NetworkManager pelean por la interfaz (solución: uno solo de los dos — usualmente networkd en servidores headless, NM en desktop)

Por qué VLANs en 2026 (y por qué nmcli)

Segmentar la red con VLANs 802.1Q dejó de ser un lujo empresarial hace rato. En un homelab con Proxmox, OPNsense o UniFi, separar tráfico de servidores, IoT, invitados y gestión es una de las prácticas de seguridad más baratas que existen: un cable, varios segmentos lógicos, y un firewall que decide qué pasa entre ellos. La pregunta real para un sysadmin moderno ya no es si usar VLANs, sino cómo configurarlas en Linux sin pelearse con la distro de turno.

Aquí es donde nmcli (NetworkManager) gana frente a systemd-networkd, ifupdown o netplan: está en prácticamente toda distro moderna (RHEL, Fedora, Debian, Ubuntu, openSUSE, Arch), maneja persistencia automática, y desde la versión 1.52 (febrero 2025) trae soporte serio para escenarios que antes requerían scripts a medida: IPVLAN, VLAN sobre bond, DNS enrutado, IPv6-only preferred. La 1.56 (febrero 2026) y 1.58 (julio 2026) consolidaron el resto del camino.

Esta guía es 100% nmcli puro. Si ya cubriste bonding + systemd-networkd en el post de 2024 sobre network bonding y VLANs, aquí vas a profundizar en el subconjunto VLAN: creación estática y DHCP, VLAN sobre bond, Q-in-Q (802.1ad), y los errores que rompen el switch sin avisar.

Conceptos en 30 segundos: 802.1Q, tag, trunk y native VLAN

Una VLAN es una etiqueta de 12 bits (1-4094) que se inserta en cada trama Ethernet. Los IDs 0 y 4095 están reservados. Cuando el switch ve la etiqueta, sabe a qué VLAN lógica pertenece ese paquete. Esto te deja meter varios segmentos de red por un solo cable físico (trunk) o inalámbrico (SSID con tagging).

Access port: puerto de switch en modo acceso, sin etiqueta. Tráfico de una sola VLAN.
Trunk port: puerto del switch que transporta múltiples VLANs etiquetadas (tagged).
Native VLAN: la VLAN por la que viaja tráfico sin etiqueta en un trunk. Por defecto suele ser la 1; buena práctica es moverla a una VLAN huérfana para reducir superficie de ataque VLAN hopping.
PVID: VLAN ID que el puerto asigna al tráfico entrante sin etiqueta.

En Linux, cuando creas una subinterface con nmcli, el kernel crea un dispositivo eth0.10 que mete la etiqueta 802.1Q en cada trama que sale y la saca en cada trama que entra. La interfaz padre (eth0) sigue siendo el pipe físico, y todas las VLANs comparten ese pipe con sus tags respectivos.

Prerrequisitos: módulo 8021q y un switch que entienda VLANs

Antes de tirar comandos, verifica dos cosas: que el kernel tenga cargado el módulo 8021q y que el switch del otro lado esté en modo trunk para esa boca. Si configuras VLANs en Linux pero el puerto del switch está en modo access con VLAN 1 por defecto, los paquetes tagged van a salir descartados y vas a perder horas debugueando DNS.

# Verificar que el módulo 8021q está disponible
modinfo 8021q | head -5
# Si no está cargado, cargarlo
sudo modprobe 8021q
# Persistir el módulo entre reboots (Debian/Ubuntu)
echo "8021q" | sudo tee /etc/modules-load.d/8021q.conf > /dev/null
# En RHEL/Fedora, verificar que NetworkManager controla la interfaz
nmcli device status

¿Por qué importa cargar el módulo? El kernel de Linux trae soporte 802.1Q desde siempre, pero algunas distros minimalistas (contenedores LXC, imágenes cloud, Alpine) lo compilan como módulo y no lo cargan por defecto. Si ves el error Cannot find device "eth0.10" después de un nmcli connection up, es porque el módulo no estaba cargado cuando NetworkManager intentó crear la subinterface. Una vez cargado, persistilo en /etc/modules-load.d/ (systemd) o /etc/modules (Debian clásico) para que el próximo reboot no te ponga en la misma situación.

Crear una VLAN con nmcli: estática y DHCP

La forma moderna (NetworkManager 1.50+) usa propiedades explícitas vlan.parent y vlan.id. La forma legacy acepta alias dev y id. Ambas funcionan, pero la primera es la que vas a ver en RHEL 9 / 10 docs.

# Identificar la interfaz física que va a ser trunk
nmcli device status | grep -E "DEVICE|ethernet"
# Salida típica:
# DEVICE  TYPE      STATE         CONNECTION
# enp1s0  ethernet  connected     enp1s0
# Crear VLAN 10 sobre enp1s0 con IP estática
sudo nmcli connection add 
  type vlan 
  con-name vlan10 
  ifname enp1s0.10 
  vlan.parent enp1s0 
  vlan.id 10 
  ipv4.method manual 
  ipv4.addresses 192.168.10.1/24 
  ipv4.gateway 192.168.10.254 
  ipv4.dns 1.1.1.1
# Activar
sudo nmcli connection up vlan10

Esto crea la subinterface enp1s0.10, le pega la etiqueta 802.1Q con VLAN ID 10, y le asigna IP estática. La conexión queda persistente en /etc/NetworkManager/system-connections/vlan10.nmconnection, así que sobrevive reboots. Verifica que la interfaz está activa con ip -d addr show enp1s0.10 (el flag -d muestra el protocolo VLAN y el ID).

Si prefieres DHCP, el bloque se simplifica:

sudo nmcli connection add 
  type vlan 
  con-name vlan20 
  ifname enp1s0.20 
  vlan.parent enp1s0 
  vlan.id 20 
  ipv4.method auto
sudo nmcli connection up vlan20

Troubleshooting común es que la VLAN “anda” en el sentido de que Linux ve la subinterface con IP, pero no hay tráfico end-to-end. El 90% de las veces el problema está en el switch: el puerto está en access con VLAN 1, no en trunk. Si tienes acceso al switch, verifica show interfaces trunk (Cisco) o el panel de puertos tagged/untagged del switch gestionado.

Tabla comparativa: NetworkManager y soporte VLAN

Versión	Fecha	Cambio relevante para VLAN
1.46	Feb 2024	Mejoras en ethernet y tagging; base de Q-in-Q
1.50	Oct 2024	Estabilidad y correcciones de propiedades bond-port
1.52	Feb 2025	IPVLAN devices, IPv6-only preferred, DNS enrutado
1.54	Sep 2025	Forwarding IPv4 per-device, mejoras Wi-Fi 6E
1.56	Feb 2026	Reaplicar `bond-port.vlans`, HSR, MPTCP laminar
1.58	Jul 2026	IPv6-only networks, hardening Wi-Fi y certificados

El cambio más relevante para sysadmins que vienen de la 1.40 es la 1.56: bond-port.vlans ahora se puede reaplicar en caliente sin tumbar la interfaz. Antes, si querías cambiar qué VLANs pasaban por un puerto del bond, tenías que down + modify + up, con ventana de pérdida de tráfico. Hoy, nmcli connection modify bond0-port bond-port.vlans "10,20,30" aplica el cambio sin desconexión.

VLAN sobre bond, sobre bridge y Q-in-Q (802.1ad)

El caso típico en un servidor Proxmox es tener dos NICs en bond (LACP) y querer pasar VLANs por encima. NetworkManager lo soporta, pero con dos caveats que la doc oficial repite:

# 1. El bond NO debe tener fail_over_mac=follow.
#    Si lo tiene, la VLAN virtual no puede copiar el MAC del nuevo puerto
#    activo y manda tráfico con la MAC vieja.
nmcli connection modify bond0 bond.options "mode=802.3ad,miimon=100,fail_over_mac=none"
# 2. El bond no debe buscar IP por DHCP/IPv6 autoconf en el parent.
#    Si DHCP falla, el bond puede caerse y tumbar todas las VLANs.
nmcli connection modify bond0 ipv4.method disable ipv6.method ignore
# 3. Crear VLAN sobre el bond (no sobre la NIC física)
sudo nmcli connection add 
  type vlan 
  con-name vlan10-bond 
  ifname bond0.10 
  vlan.parent bond0 
  vlan.id 10 
  ipv4.method manual 
  ipv4.addresses 10.10.10.1/24

La segunda regla (DHCP deshabilitado en el bond) es la que más sysadmins se saltean y luego se preguntan por qué la VLAN se cae cada 30 minutos. NetworkManager considera el bond “sin IP útil” si deshabilitas ambos métodos, lo que es exactamente lo que quieres: las VLANs llevan sus propias IPs.

Si necesitas Q-in-Q (etiqueta 802.1Q adentro de otra etiqueta 802.1Q, también llamado 802.1ad o “stacking”), la sintaxis es:

# VLAN 10 base sobre enp1s0
nmcli connection add type vlan con-name vlan10 dev enp1s0 vlan.id 10
# VLAN 20 anidada sobre enp1s0.10 con protocolo 802.1ad
nmcli connection add 
  type vlan 
  con-name vlan10.20 
  dev enp1s0.10 
  id 20 
  vlan.protocol 802.1ad
nmcli connection up vlan10
nmcli connection up vlan10.20

Q-in-Q es útil cuando el proveedor upstream ya te entrega tráfico etiquetado (VLAN del ISP) y tú quieres multiplexar tus propios segmentos adentro de esa VLAN. Cada trama lleva dos tags: el externo (del proveedor) y el interno (tuyo). En el wire se ve enp1s0.10.20. No todas las distros lo activan por defecto en el kernel; si ip link add link enp1s0.10 name enp1s0.10.20 type vlan id 20 protocol 802.1ad falla con “operation not supported”, compilaste un kernel sin CONFIG_VLAN_8021AD.

Troubleshooting: los cinco errores que rompen una VLAN

Después de configurar VLANs en producción durante años, hay un set de errores que se repiten en el 95% de los casos. Los listo en orden de frecuencia.

El puerto del switch no está en trunk. Síntoma: Linux ve la subinterface con IP, ping al gateway falla, tcpdump muestra ARP requests que salen pero nada vuelve. Fix: configurar trunk con VLANs tagged en el switch.
VLAN ID fuera de rango. nmcli acepta IDs 1-4094. ID 0 y 4095 están reservados por IEEE. Si pasas vlan.id 0, NetworkManager acepta pero el kernel rechaza la creación del dispositivo.
Múltiples default gateways en distintas subinterfaces. Si tienes VLAN 10 y VLAN 20 ambas con gateway, Linux solo respeta una y la otra queda sin ruta default. Solución: una sola VLAN con gateway (la “administrativa”) y rutas estáticas para las otras (ip route add 192.168.20.0/24 via 192.168.20.254 dev enp1s0.20).
MTU 1500 con QinQ o VXLAN. Cada tag 802.1Q suma 4 bytes; dos tags suman 8. Si tu MTU es 1500, el paquete se fragmenta o se cae. Subilo a 1504 (single tag) o 1508 (QinQ).
El bond hace failover y la VLAN no se entera. Si tu bond tiene fail_over_mac=follow, el switch aprende la nueva MAC pero la VLAN sigue mandando con la vieja. Por eso la regla de la sección anterior.

Para diagnosticar en vivo, tres comandos cubren el 80% de los casos:

# ¿Está la subinterface creada?
ip -d link show enp1s0.10
# ¿Tiene IP asignada?
ip -d addr show enp1s0.10
# ¿Llegan packets tagged? (asumiendo VLAN 10)
sudo tcpdump -nei enp1s0 vlan 10 -c 20
# ¿NetworkManager la considera activa?
nmcli connection show vlan10 | grep -E "STATE|802-1Q"

Si tcpdump no muestra nada tagged, el problema es físico (cable, puerto del switch, NIC). Si muestra paquetes pero la IP no sale, el problema es lógico (gateway, rutas, firewall).

Seguridad: VLAN hopping y por qué la native VLAN 1 es peligrosa

Por defecto, los switches vienen con VLAN 1 como native VLAN y todos los puertos en esa VLAN. Eso significa que un atacante con acceso físico a un puerto del switch puede inyectar tráfico sin etiquetar (untagged) en VLAN 1 y pivotar a otros segmentos. Hay dos ataques clásicos:

Switch spoofing: el atacante configura su NIC para hablar DTP (Dynamic Trunk Protocol) y negociar trunk con el switch. Si el switch tiene DTP activo (que es el default en Cisco), le entrega trunk con todas las VLANs.
Double tagging: el atacante manda tramas con dos tags 802.1Q. La primera (la native VLAN 1) la saca el switch al reenviar; la segunda (la VLAN objetivo) queda intacta y el paquete llega al segmento objetivo.

Mitigaciones que nmcli puede aplicar del lado Linux y que el switch debe reforzar:

# 1. Mover la native VLAN a una ID que no uses (ej. 999)
nmcli connection modify enp1s0 vlan.flags "0"
nmcli connection modify vlan10 vlan.id 999   # si necesitas una "trash" VLAN
# 2. En el switch: deshabilitar DTP en puertos de acceso
#    (Cisco: switchport mode access; MikroTik: desactivar dynamic trunk)
# 3. En el switch: configurar la native VLAN como unused
#    (Cisco: switchport trunk native vlan 999)
# 4. Limitar VLANs permitidas en trunk (prune)
#    (Cisco: switchport trunk allowed vlan 10,20,30)

¿Por qué importa esto en 2026? Porque los homelabs modernos (Proxmox, OPNsense, UniFi, Mikrotik) son cada vez más comunes, y un escape de VLAN en una red segmentada equivale a bypass total del firewall. La regla operativa: VLAN 1 nunca debe llevar tráfico de usuario; solo gestión del switch.

Cuándo NO usar nmcli para VLANs

Hay escenarios donde nmcli no es la mejor opción, y conviene saberlo antes de forzarlo:

Servidor headless Debian puro con systemd-networkd: si tu distro usa networkd y no instalaste NetworkManager (típico en servidores Debian minimalistas), las VLANs se configuran con archivos .netdev + .network en /etc/systemd/network/. La sintaxis es distinta (VLAN=vlan10, Name=enp1s0.10).
Switches L2 de 5 puertos sin gestión: si tu switch no es managed, no soporta VLANs y todo este artículo no aplica.
Contenedores LXC en Proxmox: Proxmox maneja VLANs en el bridge (vmbr0 con VLAN aware), no en el guest. Si configuras VLANs dentro del guest con nmcli, vas a tener doble etiquetado y nada va a funcionar.
Necesidad de VXLAN o EVPN: si lo que necesitas es segmentación a nivel 3 (overlay) en lugar de L2, mira VXLAN o VXLAN-EVPN con FRR. nmcli los puede crear pero la orquestación es otro mundo.

Conclusión y próximos pasos

Configurar VLANs en Linux con nmcli es una de las tareas que parece simple hasta que te toca debuguear una a las 3 AM porque el switch de arriba no tenía trunk. Los pasos mínimos:

Verificar módulo 8021q y trunk en el switch.
Crear conexión con nmcli connection add type vlan vlan.parent <iface> vlan.id <ID>.
Asignar IP (estática o DHCP).
Activar con nmcli connection up vlanXX.
Verificar con ip -d addr show y tcpdump -nei <iface> vlan <ID>.

Si estás armando un homelab, este flujo se conecta directo con la guía de Proxmox + OPNsense que cubrimos antes: las VLANs que definas acá son las mismas que vas a rutear en OPNsense. La seguridad nativa (VLAN 1 huérfana, DTP apagado, trunk pruning) vale tanto para un Cisco de 48 puertos como para un UniFi de 8.

¿Te animás a una segunda parte sobre bond + VLAN + bridges en HA, o prefieres ver VXLAN sobre nmcli primero?

Preguntas frecuentes

¿Por qué VLANs en Linux con nmcli: Guía Completa 2026 es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con VLANs en Linux con nmcli:?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con VLANs en Linux con nmcli:?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar VLANs en Linux con nmcli: y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a VLANs en Linux con nmcli:?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.