Homelab SOC #11 - Configuración inicial de OPNsense: Preparando el Firewall para el laboratorio
En el capítulo anterior incorporamos OPNsense como firewall del laboratorio y configuramos las interfaces WAN y LAN para separar la red interna del acceso a Internet.
También verificamos que el servidor DHCP funcionaba correctamente y que Kali Linux obtenía conectividad sin inconvenientes a través del firewall.
Aunque el laboratorio ya es funcional, todavía queda un paso fundamental: personalizar la configuración inicial de OPNsense para adaptarla a la arquitectura que construiremos durante el resto de la serie.
En este capítulo recorreremos el asistente de configuración inicial (Setup Wizard), definiendo parámetros como el nombre del firewall, servidores DNS, dominio interno, zona horaria y otras opciones que servirán como base para los próximos capítulos.
Objetivo de este capítulo
La pregunta que responderemos será:
¿Cómo realizar la configuración inicial de OPNsense para dejar preparado el firewall antes de comenzar a implementar servicios de seguridad?
Al finalizar este capítulo tendremos:
- Firewall correctamente identificado.
- DNS configurados.
- Dominio interno definido.
- Zona horaria configurada.
- Convención de nombres para todos los equipos del laboratorio.
- Base preparada para incorporar Suricata y el resto de los servicios.
Estado actual del laboratorio
Después de completar la instalación del capítulo anterior, la infraestructura presenta la siguiente arquitectura.
Internet
│
NAT de VirtualBox
10.0.2.0/24
│
WAN (DHCP)
OPNsense
LAN 192.168.1.1
│
Red Interna LAN-SOC
│
┌───────────────┴────────────────┐
│ │
Kali Linux Próximos equipos
192.168.1.188 Windows · Debian · Ubuntu
Durante las pruebas pudimos comprobar que:
- OPNsense obtiene conectividad hacia Internet mediante la interfaz WAN.
- El servidor DHCP entrega direcciones IP automáticamente.
- Kali Linux recibe una dirección IP válida.
- Existe comunicación entre la LAN y el Firewall.
- La interfaz Web responde correctamente.
En este punto ya contamos con un firewall completamente operativo.
Ahora comenzaremos a personalizarlo para adaptarlo a la arquitectura definitiva del Homelab SOC.
Accediendo al Dashboard
Toda la administración de OPNsense puede realizarse desde su interfaz Web.
Desde Kali Linux abrimos el navegador y accedemos a:
https://192.168.1.1
Introducimos las credenciales configuradas durante la instalación.
Una vez autenticados aparecerá el Dashboard principal.
Desde allí accederemos al asistente de configuración.
System
→ Configuration
→ Wizard
¿Por qué utilizar el Setup Wizard?
Aunque prácticamente toda la configuración puede realizarse manualmente desde los distintos menús de OPNsense, el asistente inicial permite establecer rápidamente los parámetros básicos del sistema.
Entre ellos encontramos:
- Identificación del Firewall.
- Configuración regional.
- Servidores DNS.
- Interfaces de red.
- Contraseña del administrador.
Esto nos proporciona un punto de partida consistente antes de comenzar a implementar reglas de firewall, IDS/IPS, VPN o servicios adicionales.
General Information
La primera pantalla del asistente corresponde a la configuración general del sistema.
Aquí definiremos la identidad que tendrá nuestro firewall dentro del laboratorio.
En mi caso utilicé la siguiente configuración.
| Parámetro | Valor |
|---|---|
| Hostname | soc-fw |
| Domain | homelab.local |
| Language | English |
| Timezone | America/Lima |
| DNS Server 1 | 1.1.1.1 |
| DNS Server 2 | 8.8.8.8 |
| Override DNS | Desactivado |
| Enable Resolver | Activado |
| Enable DNSSEC Support | Activado |
| Harden DNSSEC Data | Activado |
Estandarizando los nombres del laboratorio
Aproveché esta configuración inicial para definir una convención de nombres que utilizaré durante toda la serie.
En lugar de asignar nombres diferentes a cada máquina virtual, todos los equipos seguirán un mismo patrón.
| Equipo | Hostname |
|---|---|
| Firewall OPNsense | soc-fw |
| Wazuh Manager | soc-wazuh |
| Ubuntu Server | soc-ubuntu |
| Windows 11 | soc-win11 |
| Kali Linux | soc-kali |
Mantener una nomenclatura consistente facilita enormemente la administración del laboratorio y hace que los registros generados por Wazuh, Suricata y el propio firewall resulten mucho más fáciles de interpretar.
Este tipo de estandarización es una práctica habitual en infraestructuras empresariales, especialmente cuando el número de servidores comienza a crecer.
¿Por qué utilizar un dominio interno?
Aunque este laboratorio no dispone todavía de un servidor DNS propio ni de un Active Directory, decidí utilizar el dominio:
homelab.local
Esto permitirá que todos los equipos compartan una misma identidad lógica dentro de la infraestructura.
Más adelante, cuando incorporemos nuevos servicios como Active Directory o DNS interno, esta nomenclatura facilitará la integración de todos los componentes sin necesidad de realizar cambios importantes.
¿Por qué utilizar .local?
En un laboratorio aislado no existe ningún inconveniente en utilizar un dominio interno como homelab.local.
Sin embargo, en entornos de producción suele recomendarse utilizar un subdominio perteneciente a un dominio real de la organización, evitando posibles conflictos con tecnologías como Multicast DNS (mDNS).
Para los fines educativos de este Homelab, homelab.local resulta una opción sencilla y fácil de recordar.
Hasta este punto ya hemos definido la identidad del firewall y preparado los parámetros generales del sistema.
Configuración de la interfaz WAN
La siguiente pantalla del asistente corresponde a la configuración de la interfaz WAN, es decir, la interfaz encargada de proporcionar conectividad hacia Internet.
En nuestro laboratorio esta interfaz se encuentra conectada al adaptador NAT de VirtualBox, por lo que la dirección IP será asignada automáticamente mediante DHCP.
La configuración utilizada fue la siguiente.
| Opción | Valor |
|---|---|
| Disable WAN | ❌ Desactivado |
| Type | DHCP |
| MAC Spoofing | Vacío |
| MTU | Vacío |
| MSS | Vacío |
| DHCP Hostname | Vacío |
| Block RFC1918 Private Networks | ❌ Desactivado |
| Block Bogon Networks | ✅ Activado |
A simple vista parecen opciones sencillas, pero cada una tiene un propósito específico.
¿Por qué utilizar DHCP?
Como la interfaz WAN está conectada al servicio NAT de VirtualBox, no es necesario configurar una dirección IP estática.
Cada vez que la máquina virtual inicia, VirtualBox asigna automáticamente una dirección dentro del segmento:
10.0.2.0/24
Generalmente obtendremos una dirección similar a:
10.0.2.15
Esta configuración simplifica el laboratorio y nos permite concentrarnos en los componentes de seguridad sin preocuparnos por la conectividad hacia Internet.
¿Por qué no configurar MTU o MSS?
Durante el asistente aparecen varias opciones relacionadas con el tamaño de los paquetes.
MTU
MSS
En este laboratorio decidí mantener ambos valores por defecto.
Modificar estos parámetros suele ser necesario únicamente cuando existen enlaces especiales, como:
- VPN.
- PPPoE.
- MPLS.
- Enlaces con encapsulación adicional.
- Infraestructuras WAN complejas.
Como nuestro firewall se conecta directamente al NAT de VirtualBox, no existe ninguna necesidad de realizar estos ajustes.
¿Qué son las redes RFC1918?
Una de las opciones que más suele llamar la atención es:
Block RFC1918 Private Networks
Esta opción impide que la interfaz WAN acepte tráfico proveniente de direcciones IP privadas.
Las redes privadas definidas por la RFC1918 son:
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
En un entorno empresarial conectado directamente a Internet, esta opción debería permanecer habilitada, ya que normalmente ningún paquete procedente de la WAN debería utilizar direcciones privadas.
Sin embargo, nuestro laboratorio presenta una situación diferente.
La WAN no está conectada directamente a Internet.
Está conectada al NAT proporcionado por VirtualBox.
Por este motivo decidí desactivar esta opción.
Si mantuviéramos habilitado el bloqueo de redes RFC1918, OPNsense descartaría automáticamente el tráfico procedente del NAT de VirtualBox, ya que precisamente utiliza direcciones privadas del segmento 10.0.2.0/24.
Al desactivar esta opción permitimos que el firewall pueda comunicarse correctamente con la red proporcionada por el hipervisor.
¿Qué son las Bogon Networks?
La siguiente opción disponible es:
Block Bogon Networks
A diferencia de las direcciones RFC1918, las redes Bogon corresponden a bloques de direcciones que actualmente no deberían existir en Internet.
Entre ellas encontramos:
- Redes reservadas.
- Espacios aún no asignados.
- Rangos experimentales.
- Direcciones inválidas.
Mantener esta opción activada permite que el firewall descarte automáticamente tráfico sospechoso procedente de direcciones que, en condiciones normales, nunca deberían aparecer en la WAN.
Por este motivo decidí conservar la configuración por defecto.
Estado de la WAN
Con esta configuración conseguimos que OPNsense:
- Obtenga automáticamente una dirección IP.
- Tenga acceso a Internet.
- Utilice el gateway proporcionado por VirtualBox.
- Mantenga protegido el acceso WAN frente a direcciones Bogon.
Hasta este momento no fue necesario realizar ninguna configuración adicional.
La interfaz WAN quedó completamente operativa desde el primer inicio.
Después de aplicar estos cambios, el firewall mantuvo conectividad hacia Internet sin inconvenientes, permitiendo posteriormente descargar actualizaciones, instalar complementos y acceder a servicios externos.
Configuración de la interfaz LAN
La siguiente pantalla del asistente permite configurar la red interna del laboratorio.
Aquí es donde normalmente definiríamos el segmento IP que utilizarán todos los equipos protegidos por el firewall.
Inicialmente OPNsense propone la siguiente configuración.
LAN
192.168.1.1/24
Mi objetivo final para este laboratorio es utilizar el segmento:
10.0.100.0/24
ya que coincide con el diseño planteado desde los primeros capítulos del Homelab SOC.
Sin embargo, decidí no modificar todavía esta configuración.
¿Por qué no cambiar aún la LAN?
Durante este punto del laboratorio únicamente tengo conectado un equipo:
Kali Linux
Este equipo ya había recibido correctamente una dirección IP mediante DHCP utilizando el segmento por defecto:
192.168.1.0/24
Cambiar inmediatamente la red LAN habría implicado perder la conectividad con el firewall y tener que reconfigurar manualmente el cliente antes de continuar con las pruebas.
Preferí validar primero que toda la infraestructura funcionara correctamente y dejar el cambio definitivo del direccionamiento para un capítulo posterior.
En laboratorios es habitual querer modificar toda la arquitectura desde el primer momento.
Sin embargo, realizar demasiados cambios simultáneamente dificulta identificar el origen de los problemas cuando algo deja de funcionar.
Primero conviene validar que todo opera correctamente y después introducir cambios de forma controlada.
Deployment Type
La siguiente pantalla del asistente corresponde a Deployment Type.
Aquí OPNsense ofrece varias opciones orientadas a escenarios empresariales más complejos, como entornos con múltiples enlaces WAN, integración con servicios de directorio o despliegues de VPN IPsec.
Para este laboratorio decidí mantener una configuración sencilla y desactivar todas estas opciones.
La configuración utilizada fue la siguiente.
| Opción | Valor | Motivo |
|---|---|---|
| Optimize for Multi-WAN | ❌ Desactivado | El laboratorio dispone únicamente de una conexión WAN. |
| Automatic DHCP/DNS Registration | ❌ Desactivado | No existe un servidor DNS interno ni un Active Directory. |
| Optimize for IPsec | ❌ Desactivado | El laboratorio todavía no implementa túneles VPN mediante IPsec. |
¿Por qué desactivar Multi-WAN?
Una de las funcionalidades más interesantes de OPNsense es la posibilidad de trabajar con múltiples enlaces WAN.
Esto permite construir escenarios como:
- Balanceo de carga entre dos proveedores de Internet.
- Alta disponibilidad.
- Failover automático.
- Distribución del tráfico según políticas.
Sin embargo, nuestro laboratorio dispone únicamente de una conexión WAN proporcionada por el NAT de VirtualBox.
Por tanto, habilitar esta optimización no aportaría ningún beneficio.
Registro automático en DHCP y DNS
Otra opción disponible es:
Automatic DHCP/DNS Registration
Cuando esta característica está habilitada, OPNsense registra automáticamente los equipos que obtienen una dirección IP mediante DHCP dentro del resolvedor DNS interno.
Esta funcionalidad resulta especialmente útil en infraestructuras donde existe:
- Active Directory.
- DNS interno.
- Equipos unidos a dominio.
- Resolución automática de nombres.
En el estado actual del laboratorio todavía no contamos con ninguno de estos servicios.
Por ello decidí mantenerla desactivada.
Más adelante, si el laboratorio evoluciona incorporando un Windows Server con Active Directory, probablemente volveré sobre esta configuración para evaluar su utilización.
¿Por qué no utilizar IPsec?
La última opción corresponde a la optimización para conexiones VPN mediante IPsec.
IPsec es uno de los protocolos más utilizados para establecer túneles seguros entre:
- Sedes corporativas.
- Centros de datos.
- Oficinas remotas.
- Usuarios conectados mediante VPN.
Como este laboratorio se encuentra centrado inicialmente en la monitorización y detección de amenazas, decidí dejar esta funcionalidad para una etapa posterior.
Cuando llegue el momento de construir escenarios de acceso remoto o comunicaciones entre diferentes sedes, esta opción cobrará mucho más sentido.
Definiendo la contraseña del administrador
La siguiente pantalla del asistente permite establecer la contraseña del usuario root.
Aunque durante la instalación ya tuvimos la posibilidad de modificarla, este es un buen momento para verificar que el firewall no conserva las credenciales predeterminadas.
Nunca es recomendable mantener las credenciales por defecto en ningún dispositivo de infraestructura, incluso cuando se trata de un laboratorio.
Adoptar buenas prácticas desde el principio facilita trasladar posteriormente esos conocimientos a entornos de producción.
Finalizando el asistente
La última pantalla simplemente resume todas las configuraciones realizadas durante el proceso.
Después de revisarlas seleccionamos:
Finish
Y posteriormente:
Apply
OPNsense aplicará automáticamente los cambios realizados.
En algunos casos determinados servicios pueden reiniciarse durante unos segundos.
Una vez finalizado el proceso regresaremos nuevamente al Dashboard principal.
Verificando el funcionamiento
Una vez completado el asistente realicé varias comprobaciones para asegurarme de que toda la infraestructura continuaba funcionando correctamente.
Los resultados fueron los siguientes.
✅ OPNsense obtiene conectividad hacia Internet mediante la interfaz WAN.
✅ La red LAN continúa entregando direcciones IP mediante DHCP.
✅ Kali Linux recibe automáticamente una dirección IP.
✅ Existe conectividad entre Kali Linux y el Firewall.
✅ La interfaz Web permanece accesible.
Estas validaciones confirman que la configuración inicial fue aplicada correctamente y que el firewall se encuentra listo para asumir un papel central dentro del laboratorio.
Estado actual del laboratorio
Después de este capítulo la arquitectura queda representada de la siguiente manera.
Internet
│
NAT VirtualBox
10.0.2.0/24
│
WAN (DHCP)
soc-fw
OPNsense Firewall
LAN 192.168.1.1
│
Red Interna LAN-SOC
│
┌────────────────┴─────────────────┐
│ │
soc-kali Próximos equipos
192.168.1.188 soc-win11 · soc-ubuntu
soc-wazuh
Aunque todavía utilizamos el segmento 192.168.1.0/24, este será sustituido en los próximos capítulos por la red definitiva del laboratorio:
10.0.100.0/24
Una vez incorporados todos los componentes, esta será la red donde convivirán los servidores y estaciones de trabajo monitorizados por el SOC.
Con la configuración inicial completada, OPNsense ya actúa como el punto central de comunicación entre Internet y la red interna del laboratorio.
A partir de este momento podremos comenzar a aplicar políticas de seguridad, inspeccionar tráfico y registrar toda la actividad que atraviese el firewall.
¿Qué sigue?
Hasta ahora el Homelab SOC es capaz de:
- Monitorizar equipos Windows y Linux mediante Wazuh.
- Centralizar eventos de seguridad en un único servidor.
- Proteger el perímetro mediante OPNsense.
Sin embargo, todavía existe una pieza fundamental para cualquier Centro de Operaciones de Seguridad: la inspección del tráfico de red.
En el próximo capítulo incorporaremos Suricata, transformando nuestro firewall en un sistema IDS/IPS capaz de analizar paquetes en tiempo real, detectar amenazas y generar alertas que posteriormente podrán integrarse con Wazuh para su correlación.
Con ello el laboratorio dejará de observar únicamente el comportamiento de los equipos para comenzar también a vigilar todo lo que circula por la red.
Lo aprendido
En este capítulo completamos la configuración inicial de OPNsense utilizando el asistente integrado, estableciendo los parámetros que servirán como base para el resto del laboratorio.
Además de definir la identidad del firewall, configuramos los servidores DNS, la conectividad WAN, la red LAN y revisamos distintas opciones orientadas a escenarios empresariales, comprendiendo en qué situaciones resulta conveniente habilitarlas y cuándo es preferible mantenerlas desactivadas.
Más allá de la configuración técnica, este proceso permitió establecer una estructura coherente para toda la infraestructura, definiendo una convención de nombres común y preparando el entorno para la incorporación de nuevos componentes.
Durante las pruebas finales apareció un comportamiento interesante: aunque el firewall tenía conectividad directa hacia Internet, los equipos ubicados detrás de la red LAN no podían acceder a servicios externos.
Después de revisar la configuración se identificó que la interfaz WAN había quedado deshabilitada durante el proceso de reasignación de interfaces.
Esto provocaba que OPNsense pudiera comunicarse hacia Internet desde el propio sistema, pero no aplicara correctamente el flujo esperado para los clientes internos:
- Gateway WAN.
- Reglas asociadas a la interfaz.
- Traducción de direcciones (NAT).
Una vez habilitada nuevamente la interfaz WAN, los clientes de la red LAN recuperaron la conectividad hacia Internet.
Este pequeño incidente refleja una situación muy común durante la administración de firewalls: una configuración aparentemente correcta a nivel de sistema no siempre significa que el tráfico de los clientes esté siendo procesado correctamente.
La validación debe realizarse desde diferentes puntos de la arquitectura, comprobando tanto el propio firewall como los equipos ubicados detrás de él.
Con OPNsense plenamente operativo, el Homelab SOC continúa evolucionando hacia una arquitectura cada vez más cercana a la utilizada en organizaciones reales, donde el firewall no solo protege el perímetro, sino que también se convierte en una fuente esencial de telemetría para el análisis y la detección de amenazas.