Introducción

Esta práctica de ASIR sustituye un servidor Ubuntu que hacía de firewall por pfSense, segmentando la red en tres zonas con reglas propias en vez de dejar todo el tráfico en una única red plana.

Topología de red

La idea de fondo es la habitual en segmentación de red: la DMZ aloja lo que tiene que ser accesible desde fuera, la LAN no debería ser alcanzable desde la DMZ, y todo el tráfico entre zonas pasa por reglas explícitas del firewall en vez de circular libremente.

Instalación

pfSense se instaló desde ISO en una máquina virtual de VirtualBox con tres interfaces de red: una para la WAN y dos internas (DMZ y LAN). Tras la instalación y el primer reinicio hay que retirar la ISO manualmente para que arranque desde disco. La configuración web se hace desde una máquina Ubuntu Desktop dentro de la propia DMZ, entrando a http://192.168.1.1 con las credenciales por defecto (admin / pfsense) para completar el asistente inicial.

Interfaces: de LAN por defecto a DMZ y LAN reales

pfSense asigna nombres genéricos a las interfaces por defecto, y no siempre coinciden con lo que se necesita: la interfaz que quería usar como DMZ aparecía como “LAN”, y la que quería usar como LAN real no aparecía todavía. Lo primero fue renombrar y dar IP estática a la que sería la DMZ, y después añadir la interfaz restante (em2) como LAN, con dirección 192.168.3.1/24:

Configuración de la interfaz renombrada a DMZ con IP estática 192.168.1.1/24

DHCP: dinámico para la LAN, estático para el servidor

Configuré DHCP dinámico en ambas zonas internas: pool 192.168.1.10–192.168.1.245 en la DMZ y 192.168.3.10–192.168.3.245 en la LAN, comprobado conectando un cliente Ubuntu Desktop a cada red y verificando que la IP asignada respetaba el rango del pool.

Para el servidor Apache de la DMZ, sin embargo, un DHCP dinámico no sirve — necesita una IP que no cambie nunca. Así que localicé su MAC y le asigné una reserva estática (192.168.1.2, fuera del rango del pool dinámico, con hostname ApacheJesus y gateway 192.168.1.1). Verificado desde el propio servidor:

Verificación desde el servidor Apache de que la IP estática 192.168.1.2 se asignó correctamente

Antes de pasar a exponerlo hacia fuera, comprobé que el Apache respondía correctamente desde dentro de la propia DMZ y que el dashboard de pfSense mostraba las tres interfaces (WAN, LAN, DMZ) operativas.

Acceso público al Apache: port forwarding, no IP privada

Aquí tomé una decisión deliberada: en vez de simular el acceso “desde la WAN” conectando directamente a la IP privada del servidor (que es lo que hacen muchos planteamientos de esta práctica), quería que el acceso fuera real — alguien con una IP pública llega a la IP pública del firewall, y es pfSense quien redirige el tráfico al Apache de la DMZ mediante NAT.

Para que esto funcione hay que desmarcar antes, en la interfaz WAN, dos casillas de “Reserved Networks”: “Block private networks and loopback addresses” (la que de verdad impide que el port forward funcione) y “Block bogon networks”. Con eso resuelto, la regla de NAT queda así:

Regla de Port Forward: WAN TCP puerto 80 hacia la DMZ, NAT a 192.168.1.2 puerto 80

Al crear el port forward, pfSense genera automáticamente la regla de firewall correspondiente en la WAN — sin ella, el NAT no serviría de nada porque el tráfico se bloquearía antes de llegar a redirigirse:

Regla de firewall en WAN creada automáticamente al configurar el port forward

Con la regla en marcha, un cliente en la red “pública” simulada del laboratorio visita la IP del firewall directamente — sin conocer ni necesitar la IP privada real del Apache — y pfSense se encarga de redirigir el tráfico:

Cliente accediendo a la IP del firewall y viendo la página del servidor Apache de la DMZ

Reglas de firewall entre zonas

Con el acceso público resuelto, quedaban las dos reglas que sí hacían falta en este escenario (sin VLANs ni más servicios expuestos, el resto de reglas típicas de esta práctica son opcionales):

La regla que bloquea explícitamente el tráfico con origen en la DMZ hacia la LAN vive en la pestaña DMZ de las reglas de firewall (no en la LAN, que es donde uno esperaría mirar primero):

Reglas de firewall en la pestaña DMZ: el tráfico con origen DMZ hacia las subredes LAN queda bloqueado

Y para comprobar que el acceso desde la WAN a la DMZ estaba realmente restringido a HTTP y no a “lo que sea que llegue por el puerto 80”, hice ping (ICMP, no HTTP) desde un cliente hacia la IP del Apache en la DMZ:

Ping desde un cliente hacia la DMZ mostrando Destination Host Unreachable, confirmando que solo el tráfico HTTP tiene permitido pasar

Destination Host Unreachable en vez de un simple timeout confirma que es el firewall el que está rechazando activamente el paquete — el servidor solo responde por HTTP, tal y como está pensado, no por cualquier protocolo que le llegue.

Portal cautivo

Como añadido opcional, implementé un portal cautivo para que los empleados de la LAN tengan que autenticarse antes de tener acceso a internet.

Los pasos, en orden:

  1. DNS Resolver: lo habilité en el menú correspondiente, y añadí un Host Override — una entrada DNS personalizada para la LAN.
  2. DNS forwarders: configuré los DNS de pfSense a los de Google (Sistema → Ajustes generales) para que la resolución funcionara correctamente de cara a los clientes.
  3. Reglas de firewall en la LAN: una regla permite el paso hacia el propio firewall por el puerto 53 (DNS), y otra bloquea el resto de tráfico hacia ese puerto para no dejarlo abierto de más.
  4. Zona del portal cautivo: la creé desde Servicios → Portal cautivo, configurada para que, tras autenticarse, el usuario acceda a internet y además se le redirija a la página del Moodle de informática del instituto Albarregas.
  5. Grupo y usuario: creé un grupo (portal_cautivo) con el privilegio User-Services: Captive Portal login, y añadí un usuario (empleado) como miembro:

Usuario empleado añadido al grupo portal_cautivo con el privilegio de login del portal cautivo

Antes de autenticarse, cualquier cliente de la LAN se encuentra bloqueado sin acceso a internet:

Navegador mostrando el aviso de que hay que iniciar sesión antes de poder acceder a internet

Y en vez de dejar la página de login por defecto, le puse un logo y un fondo personalizados:

Página de login del portal cautivo personalizada con logo y fondo propios

Al autenticarse con empleado / 1234, el firewall deja pasar el tráfico y redirige a la página de Moodle configurada. Desde Estado → Portal cautivo se puede confirmar en cualquier momento qué usuarios están conectados desde la LAN en ese instante.

Conclusión

Se completaron todos los pasos no opcionales de la práctica, y además el portal cautivo opcional. Lo más interesante para mí no fue tanto seguir la guía de configuración de pfSense, sino las decisiones de diseño alrededor: hacer el acceso público por NAT real en vez de simularlo con IP privada, y comprobar con ping que las reglas de aislamiento entre DMZ y LAN funcionaban de verdad y no solo “sobre el papel”.