1.1 Antes de empezar

La idea de este documento es crear una pequeña infraestructura de red haciendo uso de un firewall (o cortafuegos) basado en pfSense. Con ello vamos a ver cómo funciona el sistema de creación de reglas de filtrado de tráfico para un equipo que estará dentro de la red LAN detrás de dicho firewall.

El esquema de infraestructura real quedaría de la siguiente manera, dependiendo de cómo realicemos la instalación y las posibilidades que tengamos con nuestro proveedor de internet:

• 1ª opción: el pfSense actúa como conexión directa a internet. Para ello estará conectado a un router neutro, cable-modem, ONT o lo habremos configurado como nuestro ISP nos indique. Por lo tanto pfSense tendrá IP pública a internet y actuará como firewall directo.

• 2ª opción: haciendo doble NAT, detrás del router de nuestro proveedor de Internet. Para que todo funcione de manera correcta, en el router del proveedor deberemos hacer una redirección de puertos para que todas las conexiones vayan a la IP del servidor pfSense.

1.2 Requisitos

Esta simulación se puede realizar de dos maneras:

• haciendo uso de hardware dedicado.

• usando máquinas virtuales.

La manera más sencilla es realizarlo haciendo uso de máquinas virtuales con un virtualizador como es Virtualbox, por lo que se explicará esta modalidad.

2.1 Detalles de la máquina virtual

Por otro lado, a la máquina virtual se le van a añadir dos interfaces de red:

• El primer adaptador de red será de tipo “Adaptador puente”, ya que en el sistema haremos que sea la interfaz que actuará como “WAN”.

• El segundo adaptador de red se creará de tipo “Red interna” y le pondremos el nombre de “LAN”, que hará esas funciones en nuestra infraestructura.

Dadas las explicaciones previas, una vez creada la máquina virtual nuestra infraestructura virtual quedaría de la siguiente manera:

Visto este dibujo, la máquina virtual que actuará como PC dentro de la LAN le tendremos que modificar el adaptador virtual para que sea de tipo “Red interna” y escribiremos “LAN”, por lo que ambas máquinas estarán conectadas mediante un “switch virtual”.

El resto de parámetros de la máquina virtual, como se trata de una para pruebas, será:

• 8 GB de disco duro

• 1GB de memoria RAM

2.2 Instalación

Tras poner el CD de instalación en la máquina virtual y arrancar veremos un pequeño menú como muestra la siguiente captura de pantalla:

El menú contará con un sistema de cuenta atrás y si no se selecciona nada entrará en la primera opción por defecto. Se podrá ver cómo el sistema arranca y detecta el hardware y al finalizar nos mostrará un menú con las opciones:

• Install: Instalar pfSense

• Rescue Shell: Lanza una terminal para poder recuperar una instalación que esté dando problemas

• Recover config.xml: recupera el fichero de configuración config.xml de una instalación previa.

Tras seleccionar la opción de instalar, nos aparecerá un menú para seleccionar la distribución del teclado y a continuación el tipo de partición que queremos utilizar:

• Auto (ZFS): Sistema de particionado con el sistema de ficheros ZFS. Es el sistema por defecto, aunque ZFS puede consumir más RAM.

• Auto (UFS) BIOS: si nuestro sistema usa BIOS.

• Auto (UFS) UEFI: si nuestro sistema usa UEFI.

• Manual: Nos permite particionar de manera manual, para expertos.

• Shell: Abre una consola y podremos realizar el particionado a mano.

Al seleccionar la opción “Auto (ZFS)”, el sistema nos permitirá crear un particionado en modo:

• stripe: sin redundancia, usando el disco duro instalado.

• mirror: haciendo uso del sistema RAID1

• raid10: hacer uso de un sistema RAID1+0

• raidz1: redundancia con un disco de paridad

• raidz2: redundancia con dos disco de paridad

• raidz3: redundancia con tres disco de paridad

Tras terminar, nos preguntará si queremos abrir una terminal en el sistema recién instalado. Le diremos que no y que reinicie el sistema. Nos tendremos que asegurar de quitar la ISO de la máquina virtual para que arranque desde el disco duro en lugar del CD.

3.1 Primer arranque

Tras realizar la instalación y reiniciar, en el primer arranque desde el disco duro aparecerá un pequeño asistente que comprobará el hardware, detectará los interfaces de red que tenemos y nos realizará una serie de preguntas:

• Si es necesario configurar VLANs.

• De los interfaces existentes, cuál es el WAN.

• De los interfaces existentes, cuál es el LAN.

Dependiendo del direccionamiento de red en el que nos encontremos, es posible que haya que configurar la LAN virtual de nuestra infraestructura de red virtualizada.

3.2 Menú de configuración desde consola

Tal como se ha comentado, el menú cuenta con distintas opciones de administración.

Como se puede ver en la imagen previa, aparecen 16 posibles opciones a elegir, entre las que destacaremos:

1. Assign interfaces: Para poder reconfigurar a qué red pertenecen los interfaces que tiene nuestro firewall (si es WAN, LAN, … ).

2. Set interfaces IP address: Para poder modificar la IP de los interfaces que tiene nuestro firewall.

3. Reset webConfigurator password: Cambiar la contraseña de acceso.

4. Reset to factory defaults: Restaurar el servidor a los valores de “fábrica”, es decir, resetea todas las configuraciones propias realizadas.

5. Reboot: Reinicia el servidor.

6. Halt: Apaga el servidor.

7. Ping host: Realiza un ping al equipo indicado.

8. Shell: Nos abre una consola en el sistema para poder realizar modificaciones mediante comandos.

9. pfTop: Nos muestra un listado de las conexiones establecidas en tiempo real.

10. Enable Secure Shell (sshd): Habilita el servidor SSH para poder realizar conexiones. Por defecto, sólo podremos conectarnos desde la LAN.

11. Restart PHP-FPM: Reinicia el servicio del interfaz web.

3.3 Interfaz web de configuración

El acceso a la interfaz web de configuración por defecto sólo está disponible desde la red LAN, por lo que accederemos desde la máquina virtual dentro de la LAN abriendo un navegador y apuntando a la IP por defecto de la LAN “https://192.168.1.1” (o la que hayamos puesto si hemos configurado la LAN). Tendremos que aceptar el certificado de seguridad (ya que es auto-firmado) y nos aparecerá la web de login.

Los credenciales por defecto son:

• username: admin

• password: pfsense

El usuario “admin” de la web tendrá la misma contraseña que el usuario root por consola.

Cuando nos logueamos por primera vez nos aparecerá la primera página del asistente de configuración de pfsense, que nos guiará a través de nueve pasos donde podremos hacer una configuración básica de pfSense. Los pasos serán los siguientes:

0. Bienvenida al asistente: página de inicio.

1. Soporte de Netgate: detrás de pfSense hay una empresa, Netgate, que ofrece sus servicios de soporte de pago para pfSense.

2. Información general: configuración básica del servidor:

   • hostname: nombre del servidor.

   • domain: nombre del dominio al que pertenece el servidor.

   • DNS Server: servidores DNS externos al que mandar las peticiones.

3. Servidor de tiempo: configurar la zona horaria y el servidor NTP.

4. Configurar interfaz WAN: Dependiendo de cómo sea la infraestructura real, podremos configurar el interfaz WAN con IP pública estática, por DHCP, por PPPoE, … Por defecto está en DHCP. Si estamos tras doble NAT, habría que desactivar la opción “RFC1918 Networks”.

5. Configurar interfaz LAN: La IP de pfSense en el direccionamiento LAN. Por defecto es 192.168.1.1 con una máscara “/24”.

6. Cambio de contraseña del admin: Para poner una contraseña más segura.

7. Recargar la configuración: Si se ha realizado algún cambio, recargará la configuración.

4.1 Ciclo de vida de una conexión

A continuación se explica cómo actúa pfSense al recibir un paquete de una nueva conexión:

• El paquete, como parte de una nueva conexión, llega a un interfaz.

• Se comprueban las reglas de filtrado en orden descendiente contra el paquete.

• Cuando existe coincidencia, se ejecuta la acción de la regla de filtrado.

• Se para las comprobaciones de las reglas.

• Si no ha existido una coincidencia tras comprobar todas las reglas, el paquete es bloqueado por defecto.

4.2 Reglas creadas por defecto

Tras la instalación de PfSense podemos ir a “Firewall → Rules” y ahí aparecen los interfaces que están configurados actualmente y en los que se pueden crear reglas de filtrado. Los interfaces que existirán en nuestra infraestructura serán:

• Floating: No es una interfaz al uso. Es para crear reglas de filtrado especiales que se pueden saltar el orden y/o aplicar a todos los interfaces. Es mejor no utilizarlo salvo que sepamos qué estamos haciendo y hayamos leído detenidamente la documentación sobre ello.

• WAN: Bloquea todos los paquetes.

• LAN: Existen varias reglas creadas por defecto que permiten tráfico:

  

• Permite el acceso a la IP de la LAN del pfsense al puerto 80 y 443 para poder administrarlo vía web. Esta regla está especialmente creada para que no se pueda eliminar desde este apartado, ya que el borrarla podría suponer no poder configurar pfSense vía web.

• Permite cualquier tráfico de tipo IPv4

• Permite cualquier tráfico de tipo IPv6

Las últimas dos reglas explicadas previamente permiten que el tráfico pueda salir de la LAN hacia internet y así se permita navegar por internet. Si se crease una nueva red LAN (para una red wifi, DMZ, …) estas reglas no estarían creadas, por lo que desde esa nueva LAN no se podría acceder a ninguna otra red, por lo que habría que crear reglas que permitieran el tráfico.

4.3 Crear regla de denegación

Tal como se ha comentado, por defecto desde la LAN se permite acceder a cualquier red, por lo que podemos hacer ping a cualquier equipo de Internet. Como ejemplo se va a crear una regla que impedirá el acceso a un servidor de Internet. Esta regla servirá de ejemplo para poder realizar cualquier otra regla que sea necesaria.

La regla se va a crear en el interfaz LAN, ya que queremos limitar el tráfico cuyo origen es esa red. Para crear la regla existen dos botones de creación:

• Añadir la regla al principio de la lista: como su propio nombre indica, creará la regla al principio de la lista en la que aparecen todas las reglas que ya están creadas.

• Añadir la regla al final de la lista: en este caso creará la lista al final de todas las reglas.

No importa dónde se cree la nueva regla, ya que se podrá modificar después su posición. Al crear la regla, tendremos que tener en cuenta los siguientes apartados:

• Action: Qué queremos hacer con la regla: pass, block o reject.

• Disabled: Para deshabilitar la regla. Suele ser buena idea deshabilitar temporalmente las reglas que no se necesiten en lugar de borrarlas, por si nos hemos confundido y hay que recuperarlas.

• Interface: El interfaz sobre la que se va a crear la regla.

• Familia de dirección: Si queremos aplicar la regla sobre IPv4, IPv6 o ambas.

• Protocolo: Protocolo de la conexión: TCP, UDP, ICMP, Any…

• Source: Origen de la conexión. Si es “Any” será desde cualquier equipo de la red elegida. Podremos elegir un único equipo u otras opciones.

• Destination: El destino de la conexión. Si es “Any” será a cualquier equipo. Podremos elegir un equipo u otras opciones.

• Extra options: Opciones extra y avanzadas para la regla (limitar número de conexiones, modificar el gateway de salida, … ).

• Description: Suele ser recomendable añadir una descripción a las reglas para identificar el servicio o el servidor sobre el que se aplica.

Para el ejemplo se va a bloquear todo el tráfico desde la LAN, al servidor 1.1.1.1 (servidor DNS de la empresa Cloudflare). La regla quedaría:

4.4 Orden de las reglas

Tal como se ha identificado en el ciclo de vida de las conexiones, el orden de las reglas es muy importante, ya que en el momento en el que el tráfico entra sobre el interfaz se comprobará si coincide con las reglas en orden descendente.

Por lo tanto, si existe una regla muy general que permite el tráfico y después una muy específica de bloqueo, es bastante probable que la regla específica de bloqueo no llegue a entrar en funcionamiento, ya que el tráfico coincidirá con la regla general que permite dicho tráfico.

Teniendo en cuenta la regla creada en el apartado anterior, vamos a analizar cuál es el comportamiento dependiendo del orden en el que se sitúa:

• Al final del todo:

  

  Teniendo en cuenta las reglas creadas sobre el interfaz LAN en este orden, la regla de bloqueo al servidor 1.1.1.1 no entrará nunca en funcionamiento. El tráfico cuyo origen sea la LAN coincidirá siempre con la regla que le permite ir a cualquier parte, por lo que al coincidir con esa regla no se analizará ninguna más.

• Al comienzo de las reglas:

  

  En este caso la regla más específica de denegación se ha puesto al principio, por lo que si el tráfico coincide con esta hará lo que indica la regla, bloquear el tráfico al servidor 1.1.1.1. Si no coincide, se seguirán analizando el resto de reglas, y en este caso se permitirá el resto de tráfico.

Es de vital importancia tener en cuenta el orden de las reglas, analizarlo con cuidado y realizar las pruebas oportunas para confirmar que lo que se pretende hacer es lo que termina sucediendo.

5.1 Modificando la infraestructura creada

Dado que se va a crear una red nueva, deberemos realizar cambios en la máquina virtual de nuestro servidor pfSense. La nueva infraestructura será la siguiente:

Tal como se puede apreciar al compararlo con la infraestructura anterior, se ha creado una nueva red interna, por lo que al pfSense se le tendrá que activar una nueva interfaz de tipo “Red interna” y le daremos el nombre de DMZ.

Virtualbox no nos permite realizar esta modificación “en caliente”, por lo que habrá que apagar la máquina virtual de pfSense. Algunos sistemas profesionales de virtualización sí que permiten hacer algunas modificaciones hardware en las máquinas virtuales sin tener que apagarlas, y dependiendo del sistema operativo, se dará cuenta de dichos cambios y por lo tanto no será necesario realizar un apagado.

Tenemos que crear otra máquina virtual que actuará a modo de servidor en la red DMZ, por lo que en su configuración la configuraremos también como “Red interna” en DMZ.

5.2 Modificación de la configuración en pfSense

Tal como se ha visto, tras la instalación de pfSense aparece un pequeño asistente de configuración que nos lleva a través de unos pasos que nos permitirá realizar la configuración de una infraestructura basada en una red con parte WAN y LAN.

En caso de tener más interfaces de red durante la instalación, o a posteriori como sucede ahora, no se configurarán y por tanto queda en nuestra mano realizar dicha configuración.

6.1 Usos habituales de las VPN

Aunque el sistema de VPN se puede utilizar de muchas maneras (incluso en una misma sede, para securizar aún más el acceso entre distintas LANs), los usos más habituales de VPN son los siguientes:

6.2 Características de las VPNs

Existen diferencias entre las distintas tecnologías a la hora de crear VPNs, pero todos ellos suelen contar con las siguientes características:

6.3 OpenVPN como servidor VPN en PfSense

OpenVPN es un sistema Servidor-Cliente para realizar infraestructuras VPN. PfSense cuenta con la opción para crear nuestro servidor OpenVPN a través de un asistente (wizard) o a través de todas las opciones que podemos modificar. El interfaz web que tiene PfSense no es más que una manera sencilla de crear el fichero de configuración que después usará por debajo para crear el Servidor.

Entre las opciones que podemos configurar están:

• Server mode: Tipo de Servidor que queremos crear, las opciones son:

  • Peer to Peer: Para realizar conexiones entre sedes. Existen dos maneras de realizar la autenticación:

    • Mediante Certificados (SSL/TLS)

    • Clave compartida

  • Remote Access: El sistema utilizado para equipos remotos que se quieren conectar a la oficina. En este caso existen tres métodos de autenticación:

    • Mediante certificados (SSL/TLS)

    • Usuario y contraseña: PfSense cuenta con una base de datos interna de usuarios pero también se puede realizar una conexión contra un Active Directory externo y usar la autenticación contra él.

    • Combinado: Certificados junto con usuario y contraseña

• Protocol: Protocolo por el que irá la información del túnel (UDP o TCP).

• Device mode: Tipo de conectividad. El tipo “tun” (capa 3) es el más compatible y el único que se puede utilizar en teléfonos móviles.

• Interface: Interfaz en el que se pondrá a la escucha el servidor VPN. Normalmente en WAN.

• Local port: Puerto en el que se pondrá a la escucha el servidor VPN.

• Description: Siempre es bueno añadir una descripción al servidor, ya que nuestra infraestructura puede contar con varios.

Teniendo en cuenta estas opciones, habrá que configurar las siguientes opciones:

• Cryptographic Settings: Estas son las opciones que se tendrán en cuenta a la hora de cifrar la información que viajará por el túnel. En caso de hacer uso de certificados, habrá que crear en el PfSense en “System → Cert Manager” el certificado raíz en “CAs” (CA, de Autoridad Certificadora) y el certificado del servidor en “Certificates”.

Tras esto, están las opciones que tienen que ver con el direccionamiento del propio túnel y el direccionamiento a la red remota en el apartado Tunnel Settings:

• IPv4 Tunnel Network: Cuál será el direccionamiento que se creará en cada nodo cuando el túnel se establezca.

• Redirect IPv4 Gateway: Forzar a que todo el tráfico generado en el cliente (no sólo el que se dirige a los equipos de la oficina) vaya por el túnel. Suele ser muy utilizado ya que así se simula al 100% el estar en la oficina.

• IPv4 Local network(s): Las redes a las que se podrá conectar el cliente cuando el túnel se establezca.

• IPv4 Remote network(s): En caso de ser una VPN “Peer to Peer”, las redes remotas a las que se podrá conectar el Servidor (las que están en el cliente).

Tal como se puede ver, son bastantes opciones de configuración las que deberemos tener en cuenta a la hora de crear un Servidor VPN, por lo que tenemos que tener muy clara cuál es la infraestructura que tenemos y cuál es la infraestructura que queremos conseguir creando la VPN. Antes de crear el sistema deberemos realizar la toma de requisitos y analizar las opciones para elegir el mejor sistema que se adecúe a nuestra infraestructura.

7.1 IPs balanceadas o “IPs HA”

Las IPs balanceadas (también denominadas “IPs HA” o “IPs de alta disponibilidad”) son IPs que pueden estar configuradas en un servidor y en cualquier momento moverse a otro servidor.

En el caso de PfSense, estas IPs se crean en “Firewall → Virtual IPs” y deben ser de tipo CARP. Estarán en funcionamiento en el servidor Activo, y serán las IPs en las que los servicios estén escuchando y que actuarán como GW para los equipos en cada LAN. Si el servidor activo cae, el pasivo se dará cuenta a través del interfaz SYNC y en ese momento decidirá ponerse como activo y por tanto levantará las IPs HA.

7.2 Servicios en infraestructura Activo - Pasivo

Algunos servicios de red no pueden estar en más de un servidor en la misma red, ya que entrarían en conflicto, tal como sucede con DHCP. Por ello, en las infraestructuras “Activo - Pasivo” los servicios sólo están funcionando en el servidor Activo, mientras que en el pasivo están apagados.

7.3 A tener en cuenta

Dado que la infraestructura en HA difiere de la infraestructura con un único servidor, hay ciertos cambios a tener en cuenta en la nueva infraestructura:

• Al dar DHCP en las redes LAN, el “default gateway” que se otorga debe ser la IP HA de cada LAN.

• Al hacer NAT, hay que modificar para que la IP en salida sea la HA.

Servicios extra