Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins

VLANs en Linux con nmcli es una de esas cosas que parece sencilla hasta que necesitas configurar trunk + access ports + VLANs tagged en el bridge + DHCP por VLAN. Después de configurar VLANs en 6 deployments diferentes, esta guía documenta el setup que recomiendo: NetworkManager con perfiles separados por VLAN, integración con systemd-networkd como fallback, DHCP por VLAN con dnsmasq, y el troubleshooting típico cuando la VLAN está creada pero el tráfico no fluye (mtu, trunk port mal configurado, native VLAN).

Si necesitas segmentar tu red con VLANs en Linux, esta guía te lleva de cero a funcionando.

---

El plan: cuatro VLANs en una sola sesión

Imagina que tienes un servidor Linux con una sola NIC ethernet conectada a un switch gestionado. Hoy lo apagas, configuras cuatro VLANs 802.1Q (servidores, usuarios, iot y dmz) en 20 minutos, reinicias y todo vuelve con sus IPs y rutas intactas. Esta guía hace exactamente eso, copiando y pegando bloques sin perder tiempo en teoría que ya cubrimos en la guía completa de VLANs 2026. Aquí la promesa es la contraria: cero relleno, una receta validada de punta a punta con nmcli, el módulo 8021q del kernel y verificación real con tcpdump.

Si llegas desde el post de bonding + VLANs con nmcli y systemd-networkd, vas a notar que acá todo va sobre una sola interfaz física: sin LACP, sin bond, sin bridge. La razón es que el 70% de los homelabs y servidores chicos arrancan con un único uplink al switch, y agregar bond antes de tiempo es una optimización prematura.

Prerrequisitos en cinco chequeos

Antes de tocar nmcli, verifica cinco cosas. Saltarse alguna es la causa del 80% de los tickets “tengo VLAN pero no anda”.

1. El módulo 8021q está disponible. El kernel de Linux tiene soporte 802.1Q desde siempre, pero varias distros minimalistas lo dejan como módulo sin auto-cargar. modinfo 8021q te lo confirma; si no aparece, sudo modprobe 8021q lo activa en caliente y echo "8021q" | sudo tee /etc/modules-load.d/8021q.conf lo deja persistente.
2. El puerto del switch está en trunk. El error clásico: configurar la VLAN en Linux sin tocar el switch y pasar dos horas debugueando DNS. En Cisco el equivalente es show interfaces trunk; en UniFi, Mikrotik y Aruba el panel muestra puertos tagged vs untagged. Sin trunk del otro lado, los paquetes tagged se descartan silenciosamente.
3. NetworkManager controla la interfaz. nmcli device status lista las interfaces. Si tu distro usa systemd-networkd puro (servidor Debian minimal sin NetworkManager), nmcli no aplica y tienes que ir a /etc/systemd/network/ con archivos .netdev y .network. Esta guía asume NetworkManager activo, que es el caso en Fedora, RHEL, Ubuntu desktop y Debian con GNOME.
4. Version de NetworkManager 1.30+. La sintaxis moderna vlan.parent y vlan.id funciona desde 1.30. En 1.50+ (octubre 2024) tienes propiedades autoconnect-priority para manejar orden de subida. En 1.52+ (febrero 2025) se agregó IPVLAN. No importa si tienes 1.56 o 1.58: los comandos son los mismos.
5. Plan de direccionamiento anotado. Sin esto empiezas a inventar IPs sobre la marcha y nunca cierras. En esta guía voy a usar esta tabla, anótala en un comentario del archivo .nmconnection:

VLAN ID	Nombre	Subred	Gateway	Tipo de direccionamiento
10	servidores	10.10.10.0/24	10.10.10.1	estático
20	usuarios	10.20.20.0/24	10.20.20.1	DHCP
30	iot	10.30.30.0/24	10.30.30.1	estático
40	dmz	10.40.40.0/24	10.40.40.1	estático

Paso 1: cargar el módulo y verificar NIC

El primer comando es defensivo. Si el módulo 8021q ya está cargado, modprobe no hace nada (es idempotente). Si no lo está, lo carga y de paso te confirma que el kernel reconoce la funcionalidad VLAN.

# Cargar el módulo 8021q en caliente
sudo modprobe 8021q
# Persistirlo para que sobreviva reboots (systemd)
echo "8021q" | sudo tee /etc/modules-load.d/8021q.conf
# Verificar que NetworkManager ve la NIC física y no hay rarezas
nmcli device status
# Salida esperada: enp1s0 figura como "connected" con conexión "Wired connection 1"
# DEVICE  TYPE      STATE         CONNECTION
# enp1s0  ethernet  connected     Wired connection 1
# lo      loopback  unmanaged     --
# Anotar el nombre real de la NIC (enp1s0, eth0, eno1 según distro)
# En este ejemplo seguimos con enp1s0

Si nmcli device status muestra tu NIC como unmanaged, NetworkManager no la está controlando y nmcli con add type vlan fallará silenciosamente. Solucionalo con sudo nmcli device set enp1s0 managed yes y, si sigues en RHEL/Fedora, verifica que /etc/NetworkManager/NetworkManager.conf tenga managed=true en la sección [main] (o que la MAC de tu NIC esté en keyfile).

Paso 2: crear las cuatro VLANs en orden

Cada VLAN es un profile de NetworkManager. Un profile es un archivo en /etc/NetworkManager/system-connections/ (texto, formato keyfile, legible). Crear cuatro perfiles toma un solo for en bash; ajustar a mano te hace perder foco.

# VLAN 10 servidores: IP estática, gateway propio
sudo nmcli con add 
  type vlan 
  con-name vlan10-servidores 
  ifname enp1s0.10 
  vlan.parent enp1s0 
  vlan.id 10 
  ipv4.method manual 
  ipv4.addresses 10.10.10.10/24 
  ipv4.gateway 10.10.10.1 
  ipv4.dns 1.1.1.1,8.8.8.8 
  ipv6.method ignore 
  connection.autoconnect yes 
  connection.autoconnect-priority 10
# VLAN 20 usuarios: DHCP (la IP la entrega el servidor DHCP de la VLAN)
sudo nmcli con add 
  type vlan 
  con-name vlan20-usuarios 
  ifname enp1s0.20 
  vlan.parent enp1s0 
  vlan.id 20 
  ipv4.method auto 
  ipv6.method ignore 
  connection.autoconnect yes 
  connection.autoconnect-priority 20
# VLAN 30 iot: estática, sin acceso a internet (gateway intencionalmente en otra VLAN)
sudo nmcli con add 
  type vlan 
  con-name vlan30-iot 
  ifname enp1s0.30 
  vlan.parent enp1s0 
  vlan.id 30 
  ipv4.method manual 
  ipv4.addresses 10.30.30.10/24 
  ipv4.gateway 10.40.40.1 
  ipv4.dns 1.1.1.1 
  ipv4.routes "192.168.0.0/16 10.40.40.1" 
  ipv6.method ignore 
  connection.autoconnect yes 
  connection.autoconnect-priority 30
# VLAN 40 dmz: estática, expuesta al firewall/router
sudo nmcli con add 
  type vlan 
  con-name vlan40-dmz 
  ifname enp1s0.40 
  vlan.parent enp1s0 
  vlan.id 40 
  ipv4.method manual 
  ipv4.addresses 10.40.40.10/24 
  ipv4.gateway 10.40.40.1 
  ipv4.dns 1.1.1.1 
  ipv6.method ignore 
  connection.autoconnect yes 
  connection.autoconnect-priority 40

Por qué autoconnect-priority distinto: cuando el server arranca y NetworkManager decide qué interfaces subir primero, las prioridades evitan que la VLAN “principal” (servidores) quede esperando mientras usuarios levanta DHCP. Las más críticas primero, las auxiliares después. No es obligatorio pero hace el boot más ordenado y los logs más legibles.

Sobre vlan.id 30 con gateway en otra VLAN: ese patrón permite que el tráfico de IoT pase por la DMZ antes de salir al firewall. Útil cuando quieres meter un IDS entre IoT y el resto sin tocar el switch.

Paso 3: activarlas y verificar subinterfaces

Activar las VLANs no requiere reiniciar la máquina. Con nmcli connection up cada profile toma vida propia. Verificar que el kernel creó los devices enp1s0.10, .20, .30 y .40 es la forma rápida de saber si algo falló.

# Subir las cuatro VLANs sin reiniciar nada
sudo nmcli connection up vlan10-servidores
sudo nmcli connection up vlan20-usuarios
sudo nmcli connection up vlan30-iot
sudo nmcli connection up vlan40-dmz
# ¿El kernel creó los devices?
ip -d link show | grep -E "enp1s0.[0-9]+"
# Salida esperada (una línea por VLAN):
# 5: enp1s0.10@enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
# 6: enp1s0.20@enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
# 7: enp1s0.30@enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
# 8: enp1s0.40@enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
# ¿Las IPs están asignadas?
ip -4 -br addr show | grep enp1s0
# enp1s0       UP             192.168.1.50/24
# enp1s0.10    UP             10.10.10.10/24
# enp1s0.20    UP             10.20.20.42/24   ← la entregó el DHCP
# enp1s0.30    UP             10.30.30.10/24
# enp1s0.40    UP             10.40.40.10/24

El flag -d en ip link show es la clave: muestra el protocolo (vlan protocol 802.1Q) y el ID (vlan id 10). Si el ID no aparece, la VLAN se creó como “device genérico” y el switch la ignora.

Paso 4: probar tráfico end-to-end con tcpdump

Si todo lo anterior salió bien pero el tráfico no fluye, el 90% de las veces el problema es del lado del switch. El test definitivo es capturar con tcpdump en la interfaz física (no en la VLAN) para ver si los paquetes están saliendo con la etiqueta 802.1Q correcta.

# Terminal 1: capturar tráfico tagged de la VLAN 10
sudo tcpdump -nei enp1s0 vlan 10 -c 5
# Terminal 2: hacer ping al gateway desde la VLAN 10
ping -I 10.10.10.10 10.10.10.1
# Si tcpdump muestra "vlan 10" en cada paquete y el ping responde,
# tu VLAN está funcionando. Si tcpdump NO muestra nada, el problema es
# físico (cable, puerto, NIC) o el switch está en access, no en trunk.
# Test más agresivo: capturar TODO el tráfico tagged para ver qué pasa
sudo tcpdump -nei enp1s0 'vlan' -c 20
# Salida esperada: tramas con formato "vlan 10", "vlan 20", etc.
# Si ves tramas Ethernet normales sin etiqueta, el switch está
# enviándolas untagged y tu Linux las descarta.

Troubleshooting común en este punto: si tcpdump ve paquetes tagged con la VLAN correcta pero la respuesta nunca vuelve, revisa que el gateway exista del otro lado (otro router, firewall u OPNsense en la subred). El gateway que pusiste en ipv4.gateway tiene que estar realmente accesible vía el switch trunk.

Paso 5: hacer todo persistente (sobrevive reboot)

Las conexiones que creaste con nmcli con add se guardan automáticamente en /etc/NetworkManager/system-connections/ como archivos .nmconnection. Lo que falta es confirmar que esa persistencia funciona después de un reinicio y ajustar el orden de subida.

# Ver los archivos en disco
ls -l /etc/NetworkManager/system-connections/ | grep vlan
# vlan10-servidores.nmconnection
# vlan20-usuarios.nmconnection
# vlan30-iot.nmconnection
# vlan40-dmz.nmconnection
# Ver el contenido de uno (las claves están en connection.autoconnect)
sudo cat /etc/NetworkManager/system-connections/vlan10-servidores.nmconnection
# Forzar la recarga del daemon para que tome cualquier modificación manual
sudo nmcli connection reload
# Probar la persistencia SIN reiniciar: bajar la interfaz padre y subir
sudo ip link set enp1s0 down
sleep 2
sudo ip link set enp1s0 up
sudo nmcli connection up vlan10-servidores
# Las VLANs vuelven solas gracias a autoconnect-priority

Si te aparece un .nmconnection con autoconnect=false, cambialo con sudo nmcli con mod vlan10-servidores connection.autoconnect yes. El default de nmcli con add ES yes, pero si en algún momento tocaste el archivo a mano, se puede haber perdido.

Los cinco errores que rompen una VLAN nmcli

Después de configurar VLANs en producción y leer preguntas en foros durante años, hay un set de errores que se repiten en el 95% de los casos. Te los dejo con el síntoma exacto y el fix de una línea.

1. El puerto del switch está en access, no en trunk. Síntoma: ip link muestra la subinterface enp1s0.10 con IP, pero no hay tráfico. Fix del lado Linux no hay: el fix es configurar trunk con VLANs 10, 20, 30, 40 tagged en el switch.
2. VLAN ID fuera de rango. nmcli acepta 1-4094. Los IDs 0 y 4095 están reservados por IEEE 802.1Q (802.1Q-2014 § 9.4). Si pasas vlan.id 0 o vlan.id 4095, NM acepta pero el kernel rechaza la creación del device.
3. Múltiples default gateways. Tienes VLAN 10 con gateway 10.10.10.1 y VLAN 30 con gateway 10.30.30.1. Linux solo respeta uno y la otra VLAN queda sin ruta default. Solución: una sola VLAN con gateway (la “administrativa”) y rutas estáticas para el resto.
4. 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. Con nmcli con mod vlanXX 802.mtu 1496 lo dejas compatible con un solo tag. Para QinQ (802.1ad) necesitas 1492.
5. NetworkManager no controla la interfaz. Tu NIC figura como unmanaged en nmcli device status. Causa típica: instalaste systemd-networkd y NetworkManager quedó como fallback, o tienes /etc/NetworkManager/conf.d/ bloqueando la MAC. Fix: sudo nmcli device set enp1s0 managed yes.

Cuándo NO usar nmcli

Hay tres escenarios donde nmcli te complica en vez de simplificar. Saber identificarlos te ahorra horas.

• Servidor Debian puro con systemd-networkd: si tu distro no instala NetworkManager (Debian server minimal, Alpine, imágenes cloud oficiales), las VLANs se configuran con archivos .netdev y .network en /etc/systemd/network/. La sintaxis es distinta ([NetDev] Name=enp1s0.10, [Network] VLAN=enp1s0.10, VLANId=10).
• Switches L2 sin gestión: el típico switch de 5 puertos hogareño no soporta VLANs. Todo el post aplica solo a switches gestionados (managed) con soporte 802.1Q.
• Contenedores LXC en Proxmox: Proxmox maneja las VLANs a nivel del bridge vmbr0 con la opción VLAN aware. Si configuras VLANs dentro del guest con nmcli, terminas con doble etiquetado y nada funciona.

Para el caso de Proxmox + VLANs, conviene leer la guía de VLANs con OPNsense que cubre la segmentación desde el lado del firewall, no del guest.

Resumen en comandos

Si quieres guardar este post en un Markdown aparte, la receta mínima es esta:

1. sudo modprobe 8021q + persistir en /etc/modules-load.d/8021q.conf.
2. nmcli device status confirma que la NIC física está managed.
3. nmcli con add type vlan con-name <name> ifname <iface.vid> vlan.parent <iface> vlan.id <n> ipv4.method manual ipv4.addresses <ip/cidr> ipv4.gateway <gw> por cada VLAN.
4. nmcli con up <name> activa cada subinterface sin reiniciar.
5. ip -d link show | grep vlan verifica que el kernel creó los devices con protocolo 802.1Q.
6. tcpdump -nei <iface> vlan <n> confirma tráfico end-to-end.

Para entornos más complejos (bond + VLAN + bridge + HA), el siguiente paso es mirar la guía de bonding con nmcli y systemd-networkd y planificar LACP entre el server y el switch.

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux
• Guía Definitiva para Sysadmins: Configuración de Bonding de Interfaces de Red en Linux