Desplegar un cortafuegos gratuito con OPNsense en máquina virtual Proxmox. Configuración de redes LAN, DMZ y WAN (para acceso a Internet).
- Descripción del proyecto de despliegue de cortafuegos OPNsense.
- Configurar switch gestionable con VLAN.
- Configuración de red en Proxmox.
- Crear máquina virtual OPNsense en Proxmox.
- Instalar y configurar OPNsense.
- Configuración inicial de OPNsense.
- Revisión de interfaces LAN, WAN, DMZ en OPNsense.
- Configuración de reglas de acceso y NAT.
- Configuración de NAT Reflection (Hairpin NAT / NAT Loopback) en OPNsense.
Descripción del proyecto de despliegue de cortafuegos OPNsense
En este estudio de caso vamos a desplegar el cortafuegos gratuito OPNsense, virtualizado sobre un servidor Proxmox que cuenta con un adaptador de red, para simular enlaces troncales donde, por un mismo adaptador, viajarán varias «redes». Para lograrlo, usaremos Router-on-a-Stick mediante VLAN. Aunque el tráfico de Internet (WAN) y el de la red local (LAN) irán por el mismo cable, se separará en VLAN. Además, crearemos una red DMZ interna para alojar futuros servidores web, aislándolos físicamente del resto de nuestra red.
Topología y direccionamiento
- Proxmox (Host): 1 sola tarjeta de red física.
- VLAN 99 (WAN): conexión hacia el router de nuestro proveedor de Internet (
192.168.1.1). - VLAN 10 (LAN): red local corporativa (
192.168.10.0/24). - Red DMZ: red virtual aislada (
192.168.20.0/24) para futuros servidores (ej. Nginx). - Equipo de gestión:
pcgestionconectado a la LAN (192.168.10.10). - Switch gestionable: con soporte de estándar 802.1Q (VLAN), con IP de gestión
192.168.10.2. Dispone de las siguientes interfaces con su cable de conexión al dispositivo correspondiente:
| Interfaz | Modo | VLAN | Direccionamiento | Dispositivo |
| GigabitEthernet1/0/1 | Access | 99 | 192.168.1.0/24 | WAN-Router |
| GigabitEthernet1/0/2 | Access | 10 | 192.168.10.0/24 | LAN (equipos de la red corporativa) |
| GigabitEthernet1/0/5 | Trunk | 10, 99 | 192.168.10.200 VLAN 10 192.168.10.0/24 VLAN 10 192.168.1.1 VLAN 99 | Proxmox (la gestión reside en la misma red que la LAN) |

El cortafuegos OPNsense se desplegará en máquina virtual, por lo que necesitaremos un sistema de virtualización. En este estudio de caso usaremos Proxmox. En los siguientes enlaces indicamos cómo desplegar Proxmox en equipos físicos:
- Desplegar servidor de virtualización gratuito con Proxmox VE.
- Convertir equipo Linux Debian en hipervisor de virtualización Proxmox VE.
Para la WAN disponemos de un router proporcionado por el proveedor de Internet, que no podemos reconfigurar a modo bridge, ni cambiar su direccionamiento 192.168.1.0/24. Por ello, en este estudio de caso, contemplaremos esta posibilidad. No modificaremos la configuración actual del router, únicamente lo conectaremos a una interfaz del switch gestionable (a la 1), que configuraremos con la VLAN 99 (WAN). En este caso, cualquier petición que se reciba de Internet y se quiera mapear/redireccionar a un equipo de la red interna (sea LAN o sea DMZ), en el router añadiremos un NAT por cada puerto, siempre con destino a la misma IP, la del cortafuegos OPNsense:

En el router, añadiremos un NAT por cada puerto a redireccionar, pero siempre con la misma IP de destino. Para el estudio de caso, la IP de la «pata» del cortafuegos con la WAN será la 192.168.1.254.
El router será un simple «reenviador» del NAT al cortafuegos, que es el que realmente haga el NAT final, como veremos más adelante.
Configurar switch gestionable con VLAN
Debido a que el servidor Proxmox solo tiene un cable, necesitamos que el switch le envíe el tráfico etiquetado mediante el estándar 802.1Q (VLAN). Asumimos, en este estudio de caso, que el puerto 1 del switch va hacia nuestro router de Internet (WAN), el puerto 2 hacia nuestro PC de gestión (LAN) y el puerto 5 hacia el servidor Proxmox.
Accedemos a la consola de nuestro switch (normalmente por SSH) y configuramos las interfaces y las VLAN:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 |
enable configure terminal ! Creamos las VLAN en la base de datos vlan 10 name LAN exit vlan 99 name WAN exit ! Configuramos el puerto del router de Internet (Acceso WAN) interface GigabitEthernet1/0/1 description Router-WAN switchport mode access switchport access vlan 99 spanning-tree portfast edge exit ! Configuramos el puerto para pcgestion, LAN interface GigabitEthernet1/0/2 description LAN switchport mode access switchport access vlan 10 spanning-tree portfast edge exit ! Configuramos el puerto del servidor Proxmox (Troncal / Trunk) ! Por este cable viajarán ambas redes etiquetadas interface GigabitEthernet1/0/5 description proxmox1-interfaz1 switchport mode trunk switchport trunk allowed vlan 10,99 switchport trunk native vlan 10 exit end write memory |
En la configuración de la interfaz 5 donde va conectado el Proxmox, incluimos:
switchport trunk native vlan 10
Para que:
- El tráfico de gestión de Proxmox (que sale sin etiquetar del
vmbr0) entra al switch, se le asigna la VLAN 10 y así podremos seguir administrándolo desde el pc de gestión. - El tráfico de la WAN del OPNsense (que sale con la etiqueta 99 desde su tarjeta de red virtual) entra al switch, el switch ve la etiqueta, y lo manda directo al router de Internet.
Configuración de red en Proxmox
Prepararemos Proxmox para que «entienda» estas etiquetas (VLAN) y, además, crearemos el «switch virtual» para nuestra futura DMZ.
Accedemos a la interfaz web de Proxmox y a System – Network. Seleccionamos el puente principal (habitualmente con el nombre vmbr0), que está vinculado a la tarjeta de red física y pulsamos en «Edit»:

Marcamos la casilla VLAN aware. Esto permite a Proxmox extraer las redes del cable físico.

Crearemos la red DMZ aislada en vmbr3, para ello hacemos clic en Create – Linux Bridge

Y establecemos los siguientes valores:
- Name:
vmbr3 - IPv4/CIDR: lo dejamos en blanco (el direccionamiento lo hará OPNsense).
- Bridge ports: lo dejamos en blanco. Al no asignar ninguna tarjeta física, creamos un switch que solo existe en la memoria del servidor, ideal para una DMZ segura.
- Comment:
DMZ - Autostart: lo marcamos.
- Gateway: lo dejamos en blanco.
- VLAN aware: lo desmarcamos.
Pulsamos en «Create»:

Y, para aplicar los cambios, pulsamos en Apply Configuration:

Nota importante sobre cómo maneja Proxmox las VLAN: si se viene de otros hipervisores como VMware, puede resultar extraño que en este paso no estemos creando explícitamente una red WAN (VLAN 99) y una red LAN (VLAN 10). Gracias a que hemos marcado el vmbr0 como «VLAN aware», hemos convertido a este puente en un switch troncal virtual. No necesitamos crear las sub-redes en el servidor host; será la propia máquina virtual de OPNsense la que, al conectarse a este puente, «etiquetará» su propio tráfico. Esto mantiene la configuración de red de nuestro hipervisor más limpia.
Crear máquina virtual OPNsense en Proxmox
Descargaremos el fichero ISO de OPNSense desde su web oficial:

Pasaremos el fichero ISO descargado a almacenamiento local, a ISO Images, del nodo Proxmox donde queramos desplegarlo:

Creamos la máquina virtual en Proxmox, para ello, desde el nodo Proxmox, pulsamos con el botón derecho del ratón y, en el menú emergente, elegimos «Create VM»:

Introducimos un nombre para la mv, por ejemplo «opnsense»:

Establememos el fichero ISO, en ISO image, subido anteriormente al storage local, en Type indicamos «Linux» y en Version indicamos «6.x – 2.6 Kernel»:

Indicamos los siguientes datos:
- Machine: Default (i440fx).
- BIOS: Default (SeaBIOS).
- SCSI Controller: VirtIO SCSI single.
- Qemu Agent: lo marcamos, aunque para que funcione habría que instalar el paquete en Linux.

Elegimos el Storage donde se creará la máquina virtual, el tamaño del disco (por ejemplo 32GB) y el Bus/Device SCSI con SCSI Controller VirtIO SCSI single:

Elegimos la CPU (Sockets, Cores, Type (x86-64-v2), etc. Esto puede variar en función del procesador de que disponga el servidor físico:

Elegimos la memoria RAM virtual que se asignará a la mv:

Elegimos el adaptador de red vmbr0, con VLAN Tag 99 (le indicamos a Proxmox que aisle esta tarjeta para que todo el tráfico que entre o salga de ella quede etiquetado con el 99 para el switch) y desmarcaremos «Firewall»:

Desmarcaremos «Start after created» y pulsaremos en «Finish» para crear la mv:

Antes de arrancar la mv, cuando esté creada, le añadiremos el resto de adaptadores de red, desde Hardware – Add – Network Device:

el segundo adaptador de red para la DMZ. Para añadir un segundo adaptador de red a la mv, la seleccionaremos, pulsaremos en «Hardware» y en «Add», seleccionaremos «Network Device»:

Indicando los siguientes datos para el adaptador 2 de la LAN:
- Bridge:
vmbr0(Nos conectamos al mismo cable físico que la WAN). - VLAN Tag: vacío (como en el switch hemos configurado la VLAN 10 como nuestra VLAN nativa para no perder el acceso a Proxmox, no debemos etiquetar esta tarjeta virtual. Al enviarlo sin etiqueta, el switch lo introducirá automáticamente en la VLAN 10).
- Firewall: Desmarcado.

De la misma forma, agregamos el tercer adaptador de red, para laDMZ:
- Bridge:
vmbr3(Nos conectamos al switch virtual interno que creamos antes). - VLAN Tag: en blanco. Como este switch es puramente virtual y dedicado solo a la DMZ, no necesitamos usar etiquetas.
- Firewall: desmarcado.

Instalar y configurar OPNsense
Iniciaremos la mv de opnsense y, desde la consola, instalaremos OPNsense accediendo con usuario installer y contraseña opnsense.

Indicamos el idioma/zona

Marcamos «Install (ZFS)»:

Marcamos «stripe»:

Marcaremos el disco duro virtual da0 QEMU HARDDISK:

Pulsaremos «YES»:

Elegiremos «Root Password»:

Estableceremos una contraseña para el usuario root:

Marcaremos «Complete Install»:

Una vez instalado OPNsense, pulsaremos en «Reboot now»:

Arrancará el sistema OPNsense, en este arranque, como ya está instalado, iniciaremos sesión con usuario root y contraseña establecida anteriormente.

Nos mostrará un menú, configuraremos las interfaces de red, para ello introduciremos «1» (Assign interfaces):

OPNsense nos mostrará los tres adaptadores de red, pero con su propia nomenclatura (vtnet0, vtnet1 y vtnet2) y las correspondientes MAC. Para identificarlas correctamente, desde el shell de Proxmox, ejecutaremos:
|
1 |
ip a |
Que nos devolverá todos los adaptadores y sus MAC. También podemos consultar las MAC desde la consola web de Proxmox, seleccionando la máquina OPNsense y pulsando en «Hardware»:

En este caso, asignamos las tarjetas WAN (vtnet0), LAN (vtnet1), DMZ (vtnet2). Nos solicitará el nombre de la interfaz WAN, que en este caso es «vtnet0»:

Nos solicitará el nombre de la interfaz LAN, en este caso es «vtnet1»:

Y el nombre para la tercera intefaz, que en este caso será vtnet2. Nos solicitará el nombre para otra interfaz más, pulsaremos INTRO sin introducir nada. Nos mostrará las tres interfaces a asignar/crear en OPNsense:
- WAN -> vtnet0
- LAN -> vtnet1
- OPT1 -> vtnet2
Introduciremos «y» y pulsaremos INTRO para establecer esta configuración:

A continuación, seleccionamos la opción 2 (Set interface IP address):

Vamos a establecer la siguiente configuración de red para cada interfaz:
- LAN: le asignamos la IP
192.168.10.1/24. Al resto de preguntas respondemos en blanco o «n». Esta será la puerta de enlace para la red LAN y será también la IP de acceso a la gestión web del cortafuegos.

A la pregunta de si queremos habilitar DHCP en la LAN, si queremos este servicio de asignación de configuración de red automático, responderemos «y», indicando la dirección inicial de asignación DHCP (por ejemplo 192.168.10.100) y la final (192.168.10.200).

Responderemos «n» a la pregunta de cambiar HTTPS a HTTP, responderemos «y» a generar nuevo certificado auto-firmado y responderemos «n» a restaurar acceso a GUI por defecto:

Volveremos a acceder a la opción 2 (Set interface IP address) y estableceremos al configuración para la interfaz WAN (3):
- WAN: la configuramos por DHCP (o IP estática si así tenemos configurado el router del proveedor de Internet).

- DMZ: le asignamos la IP
192.168.20.1/24(no hace falta DHCP si nuestros futuros servidores web usarán IP estáticas.

Configuración inicial de OPNsense
Revisaremos que el PC de gestión esté conectado al puerto del switch con la VLAN 10, en este caso, al puerto 5. Y, si es preciso, estableceremos una IP de la red 192.168.10.0/24 al pc de gestión (si no la tiene áun). Con esto, el PC de gestión tendrá visibilidad con el cortafuegos OPNsense.
Accederemos a la gestión web de OPNsense abriendo un navegador y accediendo a la URL:
https://192.168.10.1
Nos solicitará usuario y contraseña, introduciremos el usuario root y la contraseña que hemos establecido en el proceso de instalación:

Iniciaremos el asistente de configuración inicial, pulsando en «Next»:

Estableceremos algunos datos para el OPNsense, como:
- Hosntame: opnsense
- Domain: proyectoa.local
- Language: Spanish
- Timezone: Europe/Madrid
- DNS Servers: 8.8.4.4, 1.1.1.1

De momento, en Network [WAN] dejaremos seleccionado «DHCP»:

En Network [LAN] revisaremos que tiene la IP que hayamos indicado en el proceso de configuración anterior (en este caso, la IP 192.168.10.1):

En Deployment type dejaremos las opciones de defecto:

Y la contraseña de root, que podemos cambiar o dejar la que hayamos indicado en la instalación:

Aplicaremos los cambios y finalizaremos el asistente inicial:

Revisión de interfaces LAN, WAN, DMZ en OPNsense
Es conveniente revisar que las interfaces LAN, WAN y DMZ están correctamente configuradas en OPNsense.
Desde el menú «Interfaces» – «LAN», comprobaremos que está habilitada (Enabled) y que tiene la IP correcta:


La DMZ que viene nombrada como OPT1, le estableceremos «DMZ» en la descripción, para identificarla correctamente:

Y en la WAN estableceremos una IP de la red del router, en este caso la 192.168.1.254:

Para indicar al cortafuegos OPNsense cuál es la IP del router (gateway) para la conexión a Internet, definiremos un gateway en System – Gateways – Configuration:

Pulsando en añadir e indicando:
- Name: GW_ROUTER.
- Interface: WAN.
- Address Family: IPv4.
- IP Address: 192.168.1.1.
- Description: Puerta de enlace Router.

Una vez añadida la puerta de enlace (gateway), la asignaremos en «IPv4 gateway rules» a la interfaz WAN del OPNsense:

Configuración de reglas de acceso y NAT
Para permitir que nuestra LAN navegue por Internet, para aislar la DMZ para que sea segura (Zero Trust), y para crear un «túnel» (NAT) para que un futuro servidor web en la DMZ sea accesible desde el exterior, seguiremos los siguientes pasos.
Outbound NAT (Salida a Internet para todas las redes)
El NAT de salida (SNAT) es lo que permite que las IP privadas de nuestra LAN (192.168.10.x) y DMZ (192.168.20.x) se camuflen bajo nuestra IP pública para salir a Internet. Para crear este NAT, accederemos a: Firewall – NAT – Outbound:

Por defecto, OPNsense viene configurado en Automatic outbound NAT rule generation. Podemos dejar esta opción marcada y OPNsense detectará nuestras redes LAN y DMZ, creando las reglas de traducción automáticamente de forma invisible.

O bien podemos optar por la opción Hybrid outbound NAT rule generation (automatically generated rules are applied after manual rules), que es más flexible, pues creará reglas de NAT de salida automáticas y también podremos crear las propias nuestras:

Reglas de acceso de la red LAN (navegación a Internet)
Si queremos que los equipos de LAN puedan navegar sin restricciones hacia Internet y hacia la DMZ, accederemos a Firewall – Rules – LAN:

Revisaremos que ya existe (la crea automáticamente OPNsense) una regla para permitir esto:
- Default allow LAN to any rule: la que permite el acceso desde la LAN a cualquier otra red (WAN, DMZ).
En caso de no existir, tendríamos que crearla. Y, lo ideal, en un entorno de producción, es reducir el ámbito de esta regla, no es conveniente tener un «any» en origen y un «any» en destino, ni en direccionamientos ni en puertos. En este caso, como estamos en pruebas, dejaremos la regla de defecto.

Reglas de acceso de la red DMZ (aislar)
Un servidor web alojado en la DMZ debe poder salir a Internet (para descargar actualizaciones de Linux, por ejemplo), pero jamás debe poder iniciar una conexión hacia nuestra red LAN privada. Si un hacker compromete el servidor web, se quedará atrapado en la DMZ.
Estableceremos esta seguridad desde Firewall – Rules – DMZ, creando dos reglas.
Regla 1: Bloquear tráfico hacia la LAN
- Haz clic en el botón + (Add) en la parte superior derecha.
- Action: Block
- Interface: DMZ
- Protocol: Any
- Source: DMZ net
- Destination: LAN net
- Description: Bloquear trafico de DMZ hacia LAN
- Haz clic en Save.
Regla 2: Permitir tráfico hacia Internet
- Haz clic de nuevo en + (Add).
- Action: Pass
- Interface: DMZ
- Protocol: Any
- Source: DMZ net
- Destination: any
- Description: Permitir trafico de DMZ a Internet
- Haz clic en Save y luego en Apply Changes.
Un ejemplo de reglas de acceso en la DMZ, para aislarla lo máximo posible, cumpliendo el principio de mínimo privilegio. Se limita tanto la salida hacia Internet (únicamente desde los equipos de la DMZ específicos que lo requieran), como el acceso a otras redes. Y el acceso a Internet también se limita en puertos, únicamente los puertos necesarios (80, 443, alguno más de acceso a servidores de MySQL, etc.):

NAT de entrada si tenemos servidor web u otro tipo de servicios que lo requieran
Si en nuestra red DMZ tenemos algún servidor web o bien, si necesitamos redirigir/mapear algún puerto de Internet a la LAN (por ejemplo un acceso RDP a un equipo de la LAN), necesitaremos configurar NAT de entrada en el cortafuegos, dado que es el que recibe las peticiones del router, antes de presentarlas a los equipos de la organización.
Para crear una regla de NAT de entrada en OPNsense, accederemos a Firewall – NAT – Destination NAT y pulsaremos en añadir una nueva regla de Destination NAT:

Por ejemplo, para hacer NAT desde Internet a un servidor web de nuestra organización, introduciremos los siguientes datos:
- Interface: WAN.
- Version: IPv4.
- Protocol: TCP.
- Destination Address: WAN address.
- Destination Port: HTTP (80).
- Redirect Target IP: 192.168.1.135. Esta IP será el servidor interno de destino del tráfico del puerto indicado (el 80 en este caso).
En el NAT anterior, estamos dirigiendo todo el tráfico que venga desde el router, por el puerto 80 al servidor web interno 192.168.1.135.

Clonaremos la regla de NAT anterior del puerto 80, para añadir la del puerto 443, si así lo necesitamos:


Como en el resto de servicios, si hemos hecho cambios, para aplicarlos pulsaremos en «Apply»:

OPNsense automáticamente crea las reglas de acceso asociadas a estos NAT, así que no hay que hacer nada más.
Configuración de NAT Reflection (Hairpin NAT / NAT Loopback) en OPNsense
Cuando un host de una red interna (por ejemplo la LAN) intenta acceder a un servicio web alojado en otra red interna (por ejemplo la DMZ) utilizando un nombre de dominio (FQDN) que resuelve a la dirección IP pública de la organización, el tráfico no fluye de manera natural. Para que el cortafuegos intercepte esta petición y la devuelva hacia la red interna correcta sin que el tráfico salga al proveedor de Internet, es necesario activar la característica de NAT Reflection.
En OPNsense, esta configuración se realiza desde Firewall > Settings > Advanced. Dentro de la sección Network Address Translation, habilitaremos las siguientes directivas:
- Reflection for port forwards: permite al motor del firewall (pf) interceptar el tráfico originado internamente que va dirigido a la IP de la interfaz WAN. Al detectarlo, aplica automáticamente las reglas de DNAT (Destination NAT / Port Forwarding) para redirigirlo al servidor interno correspondiente.
- Reflection for 1:1: aplica exactamente la misma lógica de redirección, pero diseñada para los mapeos estáticos de NAT 1:1 (donde una IP pública dedicada se traduce íntegramente a una IP privada específica).
- Automatic outbound NAT for Reflection: esta es la opción más crítica para evitar problemas de enrutamiento asimétrico. Al marcarla, obligamos al cortafuegos a aplicar también SNAT (Source NAT) al tráfico rebotado. De este modo, el servidor de la DMZ percibe que la petición original proviene de la IP interna del propio cortafuegos (su puerta de enlace) en lugar de la IP original del cliente LAN. Esto garantiza que el paquete de respuesta regrese obligatoriamente a través del firewall, permitiendo que este deshaga la traducción y entregue el tráfico correctamente al equipo que inició la sesión.

En entornos de producción, en lugar de usar NAT Reflection, una buena práctica es utilizar Split Horizon DNS, consistente en crear un registro en el servidor DNS interno para que ese dominio resuelva directamente a la IP privada de la DMZ cuando se consulta desde la LAN. De esta forma, no hay que «forzar» NAT innecesarios.