VLANs con OPNsense: separar servidores, usuarios, invitados e IoT

agosto 3, 2026 Alfonso Moreno | Sysadmin Senior 91 Visitas 8 min de lectura

Cuando un termostato barato comparte red con tu NAS, el riesgo deja de ser teórico. Esta guía muestra cómo dividir el homelab en VLANs con OPNsense, qué reglas de firewall escribir y qué trampas evitar al conectar un switch gestionable.

TL;DR — Lo que vas a tener al final

Tiempo de setup: 30-60 minutos para las primeras VLANs.
Requisitos: Switch gestionable 802.1Q, NICs Ethernet.
Resultado: VLANs funcionales, failover en bonding, DHCP por VLAN.
Troubleshooting: ip link show, bridge vlan show, tcpdump -e -i eth0.

1. Por qué segmentar el homelab con VLANs

Una red plana en casa —todo en 192.168.1.0/24— es cómoda hasta que un dispositivo IoT se vuelve loco, un invitado enchufa un portátil infectado o una cámara trae un firmware con telnet abierto. Segmentar convierte esos problemas en ruido: lo que pasa en la VLAN de invitados se queda en la VLAN de invitados, y el resto de la red ni se entera.

OPNsense, basado en FreeBSD y pf, está pensado para este trabajo. Soporta 802.1Q de fábrica, expone las VLANs como interfaces virtuales y permite escribir reglas por VLAN o por alias. La documentación oficial describe la configuración como un caso natural: una VLAN por función, todas llegando al firewall por un único trunk etiquetado.

El esquema típico que montaremos separa cuatro mundos:

VLAN ID	Nombre	Función	Ejemplo de subred
10	LAN	Equipos de confianza, administración	10.10.10.0/24
20	SERVERS	NAS, hypervisor, servicios	10.10.20.0/24
30	GUEST	WiFi de invitados	10.10.30.0/24
40	IOT	Luces, enchufes, cámaras, termostatos	10.10.40.0/24

Estas subredes son solo ejemplos. Lo importante es que cada VLAN tenga su propio rango, ningún equipo comparta segmento con otra función, y que el trunk entre OPNsense y el switch lleve todas las VLANs etiquetadas.

2. Requisitos hardware y de firmware

Tres piezas tienen que estar a la altura: el switch, las tarjetas de red del firewall y, si hay APs WiFi, los puntos de acceso.

Switch gestionable (L2+). Tiene que soportar 802.1Q, VLAN por puerto, modo trunk y, si quieres redundancia, LACP. Modelos típicos de homelab: TP-Link Omada, MikroTik CRS, UniFi, Mikrotik hEX/CRS. Un switch no gestionable no sirve.
NICs en OPNsense. Cualquier Intel i210/i211/i350 o chipset moderno funciona. Las tarjetas de Realtek dan más guerra con VLANs y Netmap; si vas a activar Suricata más adelante, mira el siguiente artículo de la serie.
Punto de acceso compatible. Para tener varias SSIDs en VLANs distintas (SSID “Casa” en LAN, “Invitados” en GUEST) el AP tiene que soportar VLAN tagging por SSID, algo estándar en UniFi, Omada o MikroTik cAP.
Cableado. Un único latiguillo Cat 5e o Cat 6 entre OPNsense y el switch lleva todas las VLANs. No hace falta un cable por VLAN.

3. Crear las VLANs en OPNsense

La guía oficial VLAN and LAGG Setup de docs.opnsense.org marca tres pasos: opcionalmente crear un LAGG, añadir las VLANs como dispositivos y asignarlas a interfaces.

3.1 Crear el LAGG (opcional pero recomendado)

Un LAGG (link aggregation) con LACP no es obligatorio en un homelab pequeño, pero es una buena abstracción: te permite añadir otro cable más adelante sin tocar la configuración de las VLANs. En Interfaces ‣ Devices ‣ LAGG añade una nueva entrada con el nombre lagg0, selecciona dos interfaces físicas (por ejemplo igc0 e igc1) y el protocolo lacp. Las interfaces miembro deben estar sin asignar antes de crear el LAGG.

3.2 Añadir las VLANs

En Interfaces ‣ Devices ‣ VLAN se crean las interfaces virtuales. Para nuestro esquema:

Parent	VLAN tag	Description
lagg0	10	vlan0.10_LAN
lagg0	20	vlan0.20_SERVERS
lagg0	30	vlan0.30_GUEST
lagg0	40	vlan0.40_IOT

La nomenclatura interface_vlan_description ayuda mucho en diagnósticos. Tras guardar, las VLANs aparecen como dispositivos nuevos.

3.3 Asignar y configurar las interfaces

En Interfaces ‣ Assignments se asigna cada VLAN a una interfaz lógica. La interfaz padre (lagg0) debe quedarse sin asignar salvo que necesites tocar la velocidad del link manualmente. Para cada nueva interfaz (opt1, opt2, opt3, opt4) define:

IPv4 Configuration Type: Static
IPv4 address: la subred correspondiente con máscara /24
Bloquear tráfico bogon y redes privadas si no quieres que esa VLAN salga a internet
Disable Gateway: activado, salvo en la VLAN que tenga el upstream

4. Configurar el switch gestionable

El switch debe repetir las VLANs del firewall: mismas IDs, mismo nombre, misma membresía. La regla de oro: el puerto hacia OPNsense es trunk con todas las VLANs taggeadas y sin VLAN nativa; los puertos hacia los PCs son access con una sola VLAN untagged; los puertos hacia APs son trunk mixto (una VLAN untagged para gestión del AP y varias taggeadas para las SSIDs).

Ejemplo resumido para un TP-Link Omada con VLAN 10 (LAN), 20 (SERVERS), 30 (GUEST) y 40 (IOT):

Puerto	Modo	PVID	Tagged	Untagged
1 (a OPNsense)	Trunk	1	10,20,30,40	—
2 (a NAS)	Access	20	—	20
3 (a PC)	Access	10	—	10
4 (a AP salón)	Trunk	10	30,40	10
5 (a switch secundaria)	Trunk	1	10,20,30,40	—

El switch secundario repite la tabla en su uplink. Importante: desactiva el envío de tramas tagged y untagged por la misma VLAN en el trunk del firewall, porque la documentación oficial advierte de que se filtran broadcasts y se ensucian las estadísticas.

5. DHCP por VLAN

Cada VLAN necesita su propio servidor DHCP porque son subredes distintas. En Services ‣ ISC DHCPv4 ‣ [interface] activas el servicio y configuras un rango que no se solape con las IPs estáticas que reserves.

Ejemplo de reservas estáticas (no DHCP) por VLAN:

VLAN	IP fija reservada	Uso
10 LAN	10.10.10.1	OPNsense (gateway)
20 SERVERS	10.10.20.1	OPNsense (gateway)
30 GUEST	10.10.30.1	OPNsense (gateway)
40 IOT	10.10.40.1	OPNsense (gateway)

El gateway de cada VLAN es la IP de OPNsense en esa VLAN, el DNS puede ser el propio OPNsense si tienes Unbound activo. Si quieres bloquear publicidad en toda la casa sin instalar nada en cada cliente, Pi-hole frente a AdGuard Home en 2026 compara las dos opciones más usadas.

6. Reglas de firewall: el orden importa

La reglas de OPNsense se procesan de arriba a abajo y la primera que casa gana. La política por defecto es “denegar todo lo no permitido” y eso es lo que queremos: que solo pase lo explícitamente autorizado.

6.1 LAN (VLAN 10): permiso casi total

Por defecto los equipos de confianza pueden hablar con casi todas las VLANs, pero no al revés. Reglas típicas en la interfaz LAN:

Permitir LAN → any (todo el tráfico saliente)
Permitir SSH y HTTPS a la IP de gestión de OPNsense
Bloquear LAN → GUEST e IOT (opcional, por paranoia)

6.2 SERVERS (VLAN 20): salida a internet, entrada muy controlada

Permitir SERVERS → internet (HTTP, HTTPS, DNS, NTP, actualizaciones)
Permitir DNS saliente para que Unbound pueda resolver
Permitir tráfico desde LAN a puertos concretos del NAS (SMB 445, WebDAV, etc.)
Denegar todo lo demás

6.3 GUEST (VLAN 30): solo internet, nada más

Permitir GUEST → internet (TCP 80, 443 y DNS por UDP/TCP 53)
Bloquear GUEST → cualquier RFC1918
Bloquear GUEST → GUEST (aislamiento de cliente)

El bloqueo de GUEST hacia redes privadas es la regla más importante: impide que un invitado escanee tu LAN o tu NAS.

6.4 IOT (VLAN 40): salida restringida y aislada

Permitir IOT → internet solo para los servicios que use cada dispositivo
Bloquear IOT → LAN, SERVERS, GUEST
Bloquear IOT → IOT (aislamiento por defecto)

La gracia de IOT es que esos dispositivos suelen hablar con un servidor en la nube del fabricante; con la regla adecuada permites solo ese FQDN si te animas con aliases y pfBlockerNG.

7. Diagnóstico cuando algo no encaja

Tres comandos en la consola de OPNsense (o desde SSH) valen más que veinte clics en la GUI:

# Ver el estado de las interfaces, incluyendo VLANs
ifconfig | grep -E '^(lagg|vlan|igc|em)'
# Comprobar la tabla ARP de una VLAN
arp -an -i vlan0.20
# Diagnosticar el trunk: ¿llegan tags?
tcpdump -nei igc0 vlan

Si una VLAN no levanta DHCP, revisa primero la regla del firewall: el tráfico de broadcast DHCP va por UDP 67/68 y muchas veces lo bloquea un default “block all” mal puesto.

8. Errores comunes al empezar

PVID y VLAN nativa mal configuradas en el trunk. El trunk hacia OPNsense no debe tener VLAN nativa; la documentación oficial avisa de que se filtran DHCP y RA.
Misma subred en varias VLANs. Si dos VLANs comparten rango, el enrutamiento no sabe a cuál enviar el tráfico y aparecen respuestas intermitentes.
Permitir IOT hacia LAN “solo para probar”. La prueba se queda y un día la bombilla decide escanear la red.
No bloquear GUEST hacia redes privadas. Cualquier invitado podrá ver tu NAS si no cierras esa puerta.
Olvidar el gateway de cada VLAN. Si la interfaz no tiene IP estática, los clientes no saben a quién mandar el tráfico inter-VLAN.

Si necesitas exponer un servicio a internet desde la VLAN SERVERS, mejor una DMZ con reglas estrictas y NAT; nada de abrir puertos directamente desde LAN.

Conclusiones

VLANs en OPNsense no son magia: tres sitios en la GUI (Devices, Assignments, Rules), un switch que entienda 802.1Q y un poco de disciplina con las subredes. Una vez montado, el homelab pasa de “todo en el mismo saco” a “cada cosa en su sitio”, y los problemas de seguridad pasan de catastróficos a molestos.

Preguntas frecuentes

¿Por qué VLANs con OPNsense: separar servidores, usuarios, invitados e IoT 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 con OPNsense: separar servidores,?

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 con OPNsense: separar servidores,?

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 con OPNsense: separar servidores, 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 con OPNsense: separar servidores,?

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.