Cómo The Social Dork construye un firewall doméstico con OPNsense

Gracias a The Social Dork | Ciberseguridad por compartir la configuración de un firewall doméstico con OPNsense en ZimaBoard 2. Una máquina virtual se encarga del enrutamiento y las políticas del firewall, un punto de acceso proporciona Wi-Fi y Pi-hole filtra el DNS de los clientes conectados. Mira la guía original de YouTube para ver la demostración completa.

Mira el video antes de leer: Este video de unos diez minutos es útil si quieres separar la puerta de enlace de red del punto de acceso inalámbrico. El creador explica la topología, inicia OPNsense en Zima Virtual Machine, asigna interfaces y DHCP y, después, comprueba un portátil conectado por Wi-Fi y su filtrado de DNS.

El objetivo demostrado es que un portátil se conecte a la red a través del nuevo firewall y use el filtro de DNS elegido. El video es una guía para conectar el primer cliente. La preocupación inicial por los dispositivos IoT vulnerables exigiría una mayor separación de la red y políticas de acceso; conectar los dispositivos a un único SSID nuevo no los aísla entre sí.

Decide qué funciones debe conservar la puerta de enlace existente

La explicación de la topología distingue tres funciones que un router todo en uno puede ocultar: la conexión del proveedor, el límite del firewall de enrutamiento y el acceso inalámbrico. Una conexión Ethernet puede alimentar el nuevo firewall, mientras que un servicio DSL o por cable sigue necesitando el módem o el equipo correspondiente del proveedor. Sustituir la función de enrutamiento no elimina ese requisito de conexión física.

En la configuración funcional del creador, el router doméstico existente alimenta el lado WAN del firewall y un punto de acceso se conecta a su lado LAN. Si la puerta de enlace ascendente también realiza la traducción de direcciones de red, se produce una doble NAT. Esto puede ser aceptable para una prueba inicial, pero puede complicar los servicios entrantes y la resolución de problemas. La disponibilidad del modo puente o de paso depende del equipo y del servicio del proveedor; confírmalo antes de cambiar la conexión de producción.

Anota los ajustes actuales de cara al proveedor antes de hacer el cambio. Un video que muestra una conexión Ethernet no permite determinar los requisitos de autenticación, VLAN o módem de tu proveedor de Internet. Conserva la configuración de la puerta de enlace anterior mientras pruebas la nueva ruta con un cliente. Así podrás distinguir un problema del servicio ascendente de un error en la nueva LAN.

Doble NAT describe dos fronteras de traducción enrutadas; es distinto de tener simplemente un punto de acceso aguas abajo. Si el dispositivo inalámbrico también sigue enrutando, puede introducir otra frontera y otro servicio DHCP. Confirma su modo de funcionamiento real y la ubicación de los cables, en lugar de determinar su función por la etiqueta del producto en la carcasa.

Asigna las interfaces virtuales a una frontera WAN y LAN real

The Social Dork descarga una imagen de instalación de OPNsense y la inicia en Zima Virtual Machine en ZimaBoard 2. Se trata de una demostración de un firewall virtualizado. El host sigue ejecutando ZimaOS, por lo que su configuración de red también forma parte del diseño, al igual que los ajustes de OPNsense dentro del invitado.

Para una implementación similar, asigna explícitamente cada interfaz virtual al puerto físico o a la red aislada del host previstos. Tener dos conectores de red no establece esa asignación automáticamente. Mantén la ruta orientada a la WAN separada de los servicios habituales del host y asegúrate de que el tráfico de los clientes de la LAN tenga que pasar por el firewall para llegar a la conexión ascendente. Si un cliente dispone de otra ruta que evita la máquina virtual, el firewall no puede aplicar políticas a ese tráfico.

Sigue las instrucciones de instalación de OPNsense y la guía de máquinas virtuales actuales para la imagen y la plataforma seleccionadas. Anota cómo acceder al host y a la consola de la máquina virtual antes de cambiar las interfaces. Un reinicio del host, un problema de almacenamiento o el apagado de la máquina virtual pueden interrumpir esta puerta de enlace, así que programa el mantenimiento teniendo en cuenta la conexión de la casa.

Define explícitamente el plan de interfaces

1. Identifica los puertos físicos del host y anota qué cable llega a la conexión ascendente.
2. Asigna la interfaz orientada a la WAN del invitado a la red ascendente prevista.
3. Asigna su interfaz orientada a la LAN a una red distinta aguas abajo.
4. Confirma que la ruta de administración y los servicios habituales del host no queden expuestos involuntariamente a través del lado WAN.
5. Conecta un cliente de prueba aguas abajo y comprueba cuál es su puerta de enlace predeterminada real antes de añadir otros dispositivos.

El nombre de una interfaz dentro del invitado puede no coincidir con la etiqueta impresa junto a un puerto físico. Usa la asignación de red del hipervisor y la consola del invitado para determinar la relación. Vuelve a comprobarla después de cambiar los adaptadores virtuales. El vídeo muestra una configuración funcional en la máquina del creador, pero no ofrece un inventario completo de todos los puentes del host ni de los ajustes de adaptador que puedas encontrar.

Asigna recursos al firewall y deja capacidad para ZimaOS y los demás servicios del host. La guía de virtualización de OPNsense actual indica un mínimo de 3 GB de RAM, un disco virtual mínimo recomendado de 8 GB y pautas de compatibilidad de red. Son requisitos iniciales, no una promesa de rendimiento. Los registros, las VPN, las funciones de inspección y otras cargas de trabajo pueden cambiar el margen necesario.

Este es un compromiso operativo de compartir una máquina: una actualización o un reinicio del host también puede dejar fuera de servicio la VM de la puerta de enlace. Decide cómo se iniciará la VM después del arranque y cómo la recuperarás si no se inicia. Disponer de acceso estable a la consola resulta especialmente útil cuando un ajuste de red incorrecto impide acceder a la interfaz web.

Deja que un único servicio DHCP administre cada red de clientes

El creador utiliza redes IPv4 ascendentes y descendentes diferentes: el lado ascendente usa direcciones 192.168.0.x y la LAN de los clientes usa direcciones 192.168.1.x. Son ejemplos del vídeo. Elige subredes que no se solapen y se adapten a tu red, en lugar de copiar direcciones que quizá ya estén en uso.

El punto de acceso proporciona la conexión inalámbrica, mientras que OPNsense asigna las concesiones DHCP a los clientes de la red descendente. El tutorial explica el modo AP y cómo desactivar el servicio DHCP del antiguo router inalámbrico. En equipos sin un modo AP específico, desactivar DHCP por sí solo no garantiza un funcionamiento transparente como punto de acceso: verifica los requisitos de conexión LAN a LAN y de enrutamiento/NAT del fabricante. Mantén accesible su dirección de administración sin que entre en conflicto con el rango DHCP.

Prueba la concesión resultante en un portátil. Debería recibir una dirección de la LAN prevista, la dirección LAN del firewall como puerta de enlace predeterminada y el servidor DNS previsto. Una asociación Wi-Fi correcta solo demuestra que funciona la conexión inalámbrica. La dirección, la puerta de enlace y el servidor DNS indican si el cliente se ha incorporado realmente a la nueva ruta de red.

Planifica por separado las direcciones fijas y el conjunto de concesiones

Lo siguiente es un plan LAN /24 ilustrativo, no una transcripción de las direcciones exactas del creador. Adáptalo a tus redes existentes. Reserva direcciones fijas para la infraestructura fuera del conjunto asignado dinámicamente y mantén la red ascendente distinta de la LAN descendente.

Si Pi-hole está realmente en otra subred o en una red virtual del host, usa su dirección real accesible y el enrutamiento y las políticas necesarios. La dirección del ejemplo no hace que el servicio aparezca en la LAN por sí sola. Una entrada DHCP indica a los clientes dónde enviar una solicitud; no establece la ruta ni inicia el servidor.

Después de cambiar DHCP, comprueba la concesión en el portátil en lugar de revisar solo la página de configuración del servidor. Confirma la dirección, la máscara, la puerta de enlace y las entradas DNS asignadas. Un cliente que aún tenga una concesión antigua puede hacer que una configuración nueva correcta parezca defectuosa. Una dirección o puerta de enlace inesperada también puede indicar que sigue activo otro servidor DHCP.

Usa la primera regla de permiso como prueba de conectividad

El creador empieza con una regla permisiva de salida para el único portátil de prueba y habla de impedir conexiones no solicitadas desde la WAN hacia la LAN. OPNsense utiliza filtrado con estado, por lo que las respuestas a una conexión permitida se gestionan mediante el estado de la conexión. La documentación de las reglas del cortafuegos de OPNsense explica cómo afectan a ese comportamiento la interfaz, la dirección y el orden de las reglas.

En el video también se abre la interfaz web desde su red privada aguas arriba. En tu propia implementación, limita el acceso administrativo a una ruta de administración de confianza y conserva una opción de recuperación por consola. La etiqueta WAN describe una función relativa a este firewall; un segmento privado de laboratorio aguas arriba y la internet pública son condiciones de exposición diferentes.

Para abordar la preocupación sobre los dispositivos IoT planteada al principio, crea redes distintas con equipos que las admitan y, después, define qué tráfico se permite entre ellas. Los dispositivos que intercambian tráfico dentro del mismo segmento local pueden comunicarse sin pasar por el firewall de enrutamiento. Para ver otro ejemplo práctico de decisiones sobre gateways y privacidad, consulta la configuración de firewall OPNsense de cachito labs.

Distingue la conectividad del aislamiento

Define el origen, el destino, el protocolo y el propósito previsto antes de añadir una regla. Una regla que demuestra que una laptop puede acceder a internet no constituye una política para todos los dispositivos de una casa. Para segmentar la red, usa redes distintas y una ruta de firewall entre ellas. Es posible que el tráfico intercambiado localmente dentro de un mismo segmento no llegue al gateway.

Cuando un cambio de regla parece no surtir efecto, prueba con una conexión nueva y ten en cuenta el estado de la conexión. La guía de reglas de OPNsense explica el procesamiento con estado. Los estados existentes pueden afectar a una nueva prueba, pero restablecerlos todos interrumpiría otras conexiones activas. Identifica el flujo de prueba específico antes de hacer un cambio de diagnóstico general.

Conecta Pi-hole mediante DHCP sin crear un bucle DNS

Casi al final, The Social Dork configura la dirección de Pi-hole como servidor DNS proporcionado por DHCP. Así, el proyecto de bloqueo de anuncios con Pi-hole y Tailscale mencionado antes se integra en la nueva red inalámbrica. OPNsense controla la ruta del tráfico enrutado; Pi-hole evalúa los nombres DNS solicitados a través de su servicio. Ambos componentes tienen responsabilidades distintas.

La guía de integración de OPNsense de Pi-hole describe la distribución directa mediante DHCP y el reenvío a través del firewall como configuraciones alternativas. Elige una ruta coherente y asegúrate de que los solucionadores no se reenvíen consultas entre sí en un bucle. Comprueba también que los clientes puedan acceder a la dirección de Pi-hole si está en otra red.

Elige una ruta de resolución y trázala de extremo a extremo

El video usa la dirección de Pi-hole proporcionada por DHCP para los clientes. La configuración de reenvío de la guía oficial enlazada es una alternativa. Si la eliges, asegúrate de que el servidor DNS ascendente de Pi-hole no reenvíe la solicitud directamente a la misma cadena de reenvío. Una ruta clara facilita mucho el diagnóstico cuando no se recibe respuesta.

El DNS también depende del transporte y del enrutamiento. Si el cliente y el solucionador están en redes distintas, comprueba la ruta y las reglas pertinentes para el puerto 53 de TCP/UDP. Si el resultado observado difiere de la configuración DHCP, revisa los anuncios de DNS de IPv6 y la configuración de DNS independiente del cliente. Poder acceder a la interfaz web de Pi-hole no es prueba suficiente.

Para filtrar el tráfico fuera de casa, consulta la guía paso a paso de Pi-hole y Tailscale. El acceso remoto al DNS, las políticas de la puerta de enlace local y la salida de todo el tráfico a Internet mediante una VPN son decisiones distintas. Prueba cada opción en la conexión donde realmente se vaya a usar.

Verifica toda la ruta antes de trasladar cada dispositivo

La demostración final cambia la red Wi-Fi del portátil y compara el mismo sitio web con y sin el filtrado configurado. Ilustra la ruta del cliente seleccionado, pero no demuestra que todos los sitios web estén libres de anuncios ni que todos los dispositivos estén aislados. Primero valida el acceso a Internet y el DNS; luego revisa los registros pertinentes del cortafuegos y de Pi-hole para relacionar cada resultado con el cliente previsto.

Antes de migrar a los integrantes del hogar, prueba la renovación de la concesión de un cliente, una conexión permitida y otra bloqueada deliberadamente entre redes separadas, si la segmentación forma parte de tu diseño. Exporta una configuración funcional del cortafuegos y confirma la ruta de recuperación. El resultado útil es un gateway cuyo enrutamiento, DHCP, filtrado y administración puedas explicar y mantener. Mira la guía completa de The Social Dork sobre el cortafuegos doméstico con OPNsense para conocer la topología original y la secuencia de configuración.

Usa una prueba de aceptación por etapas

1. Conéctate a la red inalámbrica prevista y revisa la nueva concesión del cliente.
2. Confirma la puerta de enlace predeterminada y, cuando corresponda, prueba una conexión permitida mediante dirección IP.
3. Resuelve un nombre de host permitido mediante el resolvedor seleccionado y localiza la consulta.
4. Busca un dominio en la política activa de Pi-hole y confirma la respuesta esperada.
5. Si configuraste la segmentación, prueba una conexión permitida y otra bloqueada a través del límite enrutado.
6. Vuelve a conectar el cliente o renueva su concesión y confirma que se restablezcan los ajustes previstos.
7. Durante una ventana de mantenimiento planificada, verifica el proceso de inicio del host y la máquina virtual del gateway antes de depender de él de forma continua.

Soluciona los problemas siguiendo el orden de la red

Usa los registros para responder una pregunta a la vez. La documentación sobre el registro del cortafuegos de OPNsense explica que un flujo con estado no necesariamente genera una nueva línea en el registro en tiempo real por cada paquete. La guía de diagnóstico del cortafuegos muestra el estado. Que el registro esté en silencio no demuestra por sí solo que no haya tráfico atravesado el cortafuegos.

Guarda una configuración funcional antes de hacer un cambio importante y ten preparado un plan claro para volver atrás. Durante las pruebas, mantén disponible por separado la conexión anterior; evita conectar accidentalmente las redes externa e interna por fuera del cortafuegos. Un plan de reversión útil restablece una configuración conocida de la pasarela y los clientes, en lugar de introducir dos enrutadores en conflicto en el mismo segmento de clientes.

Preguntas frecuentes

¿Puede ZimaBoard 2 sustituir por sí sola la radio Wi-Fi?

En este video, un punto de acceso independiente proporciona la conexión Wi-Fi. La placa aloja la pasarela virtualizada y los servicios relacionados. El enrutamiento y el acceso inalámbrico son funciones distintas.

¿Puedo quitar el módem del proveedor de Internet?

Solo si ya no necesitas el equipo para la conexión con tu proveedor. Las configuraciones DSL, de cable y específicas de cada proveedor quizá sigan necesitando el equipo de terminación original. Confirma los requisitos físicos y del servicio antes de sustituir una pasarela.

¿Una regla que permita el tráfico saliente aísla los dispositivos IoT?

No crea separación de red. Los dispositivos de un mismo segmento local pueden comunicarse sin pasar por el cortafuegos enrutado. Para aislarlos hacen falta redes distintas y una política probada entre ellas.

¿Debería ejecutar Pi-hole dentro de OPNsense?

El proyecto mostrado utiliza un servicio Pi-hole junto con el cortafuegos virtualizado y anuncia su dirección mediante DHCP. Lo importante es disponer de una ruta DNS accesible y estable; no des por sentado que instalar OPNsense también instala ese servicio.

¿Por qué necesita la máquina virtual del cortafuegos dos conexiones de red?

El diseño enrutado necesita una conexión hacia la red externa y otra independiente hacia la red interna. La asignación correcta de las conexiones de la máquina virtual al host establece ese límite. Ver dos nombres de adaptador no demuestra por sí solo que las redes estén aisladas.

¿Qué ocurre cuando se reinicia el host de ZimaOS?

El cortafuegos para invitados y otros servicios alojados pueden dejar de estar disponibles. Planifica el inicio y la recuperación de la máquina virtual y, después, verifícalos durante una ventana de mantenimiento. Si el hardware es compartido, el mantenimiento del host también afecta a la disponibilidad de la pasarela.

Conclusión

El montaje de The Social Dork es útil porque convierte una pasarela todo en uno en varias funciones fáciles de entender: conexión con el proveedor, enrutamiento virtualizado, acceso inalámbrico, asignación de direcciones y filtrado de DNS. La primera prueba satisfactoria con un portátil establece un punto de partida. Una pasarela doméstica bien mantenida también necesita límites de red verificados, una política adecuada para cada grupo de clientes y un método de recuperación.

Completa las comprobaciones con un solo cliente antes de migrar a toda la casa y, después, valida por separado cualquier segmentación adicional o el funcionamiento de la VPN. Ten a mano la guía en video de OPNsense, tu propio plan de interfaz y la documentación oficial vigente. El objetivo es tener una red cuyo funcionamiento puedas explicar, probar y restablecer.