https://www.bellera.cat/josep/pfsense/index_cs.

html

Caso-Estudio
Objetivos
Balanceo de carga de las ADSL
Las comunicaciones peer-to-peer (P2P)
FTP-Proxy Helper
DMZ (zona desmilitarizada)
Estados y diagnósticos

Objetivos
• Aislar física y lógicamente las redes dedicadas a servidores, profesorado, alumnos i
sin hilos (wireless). Seguridad de dentro a dentro.
• Regular las comunicaciones entre las distintas redes locales y de las redes locales a
Internet. Seguridad de dentro a dentro y de dentro a afuera.
• Aprovechar el caudal de las tres ADSL de que se dispone, a poder ser de forma
automática. Balanceo de carga.
• Aumentar la seguridad en los servicios que tenemos en Internet. Seguridad de afuera
a dentro.
• Poder tener una red sin hilos (wireless) abierta.

• Utilizar una solución abierta, de código libre.

• Utilizar un hardware de tamaño reducido, integrable en el armario de comunicaciones.

• Utilizar un hardware no basado en disco duro, que no requiera protección con un SAI
de apagado y puesta en marcha automáticos.
• Poder configurar todos los dispositivos de la red (ordenadores, impresoras, puntos de
acceso, ...) mediante DHCP estático, es decir, asignándoles una dirección IP en
función de su dirección MAC.
• Control del uso de aplicaciones P2P.

• Estandarizar y automatizar la configuración de los navegadores en lo que se refiere al

uso de servidores intermediarios (proxy) y la configuración de red de todas las
máquinas.
Esquemáticamente, el montaje ha quedado tal como muestra la figura (observa que tienen
que haber seis redes diferenciadas AAA, BBB, CCC, XXX, YYY i ZZZ):
Prácticamente todos los objetivos han sido sobradamente logrados, fuera de algunas
limitaciones que se han encontrado. pfSense tiene muchas funcionalidades, pero hay que
tener en cuenta que algunas son incompatibles entre ellas. Y, por tanto, hay que escoger cuál
es la mejor opción. Se explican a continuación las decisiones adoptadas.

Balanceo de carga de las ADSL

pfSense permite balanceo de carga con detección de fallo (fail-over), lo que resulta muy
interesante si se tiene más de una ADSL. Esta prestación permite pues equilibrar las cargas
de las ADSL y en caso de fallo de una de ellas redireccionar su tráfico hacia otra.
pfSense emplea para el balanceo el demonio (daemon) slbd. Como la mayoría de
balanceadores, su intención es mejorar la navegación por Internet y no entiende las
conexiones múltiples. Ello descarta su uso en accesos FTP. Por tanto, o se renuncia a
balanceo o se renuncia a FTP. O bien se monta otro pfSense sólo para FTP. Se decidió
renunciar al balanceo.
El balanceo se configura definiendo una pila (pool) donde se indica la IP pública de cada
ADSL (IP a monitorizar) y la IP privada por la que se accede a la ADSL. Entonces pfSense
comprueba periódicamente si la ADSL en cuestión está funcionando, haciéndole un ping. Se
necesita, por tanto, que la IP pública de la ADSL conteste a estos ping internos. De lo
contrario, pfSense no sabrá ver si la ADSL está activa.

Las comunicaciones peer-to-peer (P2P)

Otro de los quebraderos de cabeza de los administradores de red son las descargas
indiscriminadas empleando programas como Emule o Ares: ocupación del ancho de banda,
problemas de seguridad, ilegalidad, ...
Una solución drástica es hacer que las conexiones a Internet estén permitidas sólo hacia los
puertos (servicios) más usuales (80, 443, 21, 53, 119, ...) En
http://www.iana.org/assignments/port-numbers encontrarás la lista oficial de puertos.
La otra solución es emplear el regulador de caudal (traffic shaper) ALTQ que tiene pfSense y
poner los accesos P2P en la cola de prioridades. Es una solución que requiere un cierto
ajuste, pero es la más recomendable. Actualmente tiene la limitación que sólo se puede
emplear ALTQ entre una de las LAN y una de las WAN del cortafuegos (es decir, ALTQ en
pfSense no es multiWAN, pero se está trabajando para que lo sea ...)
En todo caso, tanto si se emplea una solución como otra, tiene que entrar en juego otra
prestación de pfSense: FTP-Proxy Helper.

FTP-Proxy Helper
Se trata de una funcionalidad de Packet Filter (PF), que permite que la propia máquina
(127.0.0.1) haga de intermediario (proxy) para las conexiones FTP. De esta manera queda
obviado el problema de que un cliente FTP opere con el servidor no sólo por el puerto 21 si
no también con un puerto dinámico, que está por encima del 1023 y que se confunde a la vez
con un acceso P2P.
Desgraciadamente FTP-Proxy Helper tampoco es multiWAN, lo que se traduce en que
siempre sale/entra por la puerta de enlace por defecto que tenga nuestro pfSense. Es por
ello que en el esquema anterior se puede ver que sólo ha sido activado para la red Alumnes,
al igual que ALTQ.
Si tienes más curiosidad a cerca de cómo funciona FTP-Proxy Helper visita
http://www.openbsd.org/faq/pf/ftp.html#client

DMZ (zona desmilitarizada)

En el esquema de más arriba se puede ver que no hay una DMZ (zona desmilitarizada)
propiamente dicha. Se ha renunciado a ella porqué implicaba un profundo cambio en la
estructura de servidores, se necesitaba una séptima tarjeta de red en el cortafuegos y otro
concentrador de red (switch) para la DMZ. A pesar de que no tener una DMZ no es una
situación ideal, la adopción de pfSense con la estructura propuesta es, sin duda, un
importante aumento de seguridad.
Estados y diagnósticos
pfSense tiene toda una serie de herramientas que permiten ver con todo detalle qué está
pasando o qué ha pasado. Estado de las conexiones, gráficos del uso de cada interfase
(históricos y en tiempo real), herramientas de diagnóstico, ... El administrador de red tiene
pues con pfSense las herramientas necesarias para poder tomar decisiones sobre el tráfico
de su red.

INSTALACIÓN pfSense.

Preparativos
Antes de la implantación definitiva de pfSense se tuvieron que hacer los siguientes cambios
en la red:
• Dividir el cableado existente en seis redes físicas. Ello se hizo pasando algunos cables
más del armario secundario al armario primario, instalando más concentradores
(switch) en ambos armarios y cambiando el conexionado de equipos en los armarios.
No hay más de dos concentradores encadenados (tal como estaba antes de los
cambios).
• Adoptar DHCP en todos los ordenadores clientes. Ello se hizo activando
provisionalmente DHCP en uno de los routers ADSL.
• Cambiar todos los procesos por lotes (archivos BAT y CMD en Windows, scripts de
shell en máquinas Unix/Linux) que empleaban direcciones IP locales, poniendo su
correspondiente nombre de máquina.
• Cambiar todos los puertos de impresora que estaban por dirección IP local, poniendo
su correspondiente nombre de máquina.
• Asegurarse que el DNS local resuelve correctamente todos los nombres de máquina.

• Asegurarse que el archivo hosts de las máquinas sólo contiene la línea: 127.0.0.1
localhost. Es decir, que no se emplea para resolver nombres de máquina, excepto
localhost.
• Cambiar la configuración proxy de los navegadores de Internet, poniendo la
configuración automática http://www.dominio.ejemplo/proxy.pac.
• Deshabilitar el acceso sin hilos de todas las impresoras que tienen esta funcionalidad,
dejando sólo el acceso por red cableada.
Hardware utilizado
Descarga de pfSense
Se puede ir a la web oficial www.pfsense.org, pero hay otros repositorios con configuraciones
ajustadas.
Así, en http://shopping.hacom.net/catalog/pub/pfsense/ se encuentran versiones preparadas
según la unidad que reconoce pfSense para la Compact Flash y según su tamaño.

Configuración base
Acceso a la interfase web
[System] [General Setup]
[System] [Advanced functions]
[Interfaces] [Assign]
[Interfaces] [LAN]
[Interfaces] [WAN]
[Interfaces] [WAN1]
[Interfaces] [WAN2]
[Interfaces] [Alumnes]
[Interfaces] [Wireless]
Guardar la configuración

Acceso a la interfase web

Desde un navegador de páginas web iremos a la dirección IP que hayamos puesto (en la
LAN del cortafuegos) durante la instalación:
http://192.168.XXX.1
Y nos validaremos con el usuario admin y la contraseña pfsense.
Cuando se entra por primera vez aparece un asistente, pero se puede saltar haciendo clic
sobre el logotipo de pfSense. Prefiero hacerlo así para ir familiarizándome con los menús ...
El configurador web está basado en un servidor web reducido llamado lighttpd. No sé si es
un problema de este servidor o de su configuración pero, a veces, te ves obligado a refrescar
la página para que se vea se vea bien o a repetir la acción de algún botón (por ejemplo el de
descarga de la configuración del cortafuegos en formato XML). Resulta algo incómodo pero
no tiene más importancia.
[System] [General Setup]
Iremos pues a [System] [General Setup] para ajustar la configuración básica de nuestro
cortafuegos:
[System] [Advanced Functions]
A continuación, si queremos acceso a la consola por SSH y/o hacer servir HTTPS hay que
ajustar cosas en [System] [Advanced functions]. El certificado de seguridad y la llave privada
para el acceso web no son imprescindibles pero sí recomendables, sobretodo si queremos
evitar el típico aviso sobre los certificados de cuando se entra en modo https. En
www.eclectica.ca/howto/ssl-cert-howto.php hay un buen tutorial sobre certificados SSL.
El usuario de acceso a la consola por SSH es siempre admin. El cambio del nombre del
usuario administrador vía web no afecta el del administrador vía SSH. Por contra, el cambio
de contraseña sí que afecta los dos modos de administración (SSH y web).
[Interfaces] [Assign]
Habrá que ir también a [Interfaces] [Assign] con el fin de asignar el resto de interfases
(recordemos que LAN y WAN ya se asignaron durante la instalación y configuración inicial).
En un primer momento, el sistema va denominando las interfases que asignamos como
Optional 1, Optional 2, Optional 3, Optional 4, ...
En los apartados que hay más adelante de configuración de cada una de las interfases
podremos darles un nombre a nuestro gusto (WAN1, WAN2, Wireless i Alumnes). La pantalla
que se muestra a continuación es ya la final de asignación de interfases:
[Interfaces] [LAN]
Terminamos por ajustar la configuración de la LAN asegurándonos que tenemos FTP-Proxy
Helper desactivado:

[Interfaces] [WAN]
Asignaremos a la WAN (puerta de enlace por defecto de nuestro cortafuegos) una IP estática
(192.168.AAA.2), indicaremos cuál es su puerta de salida (192.168.AAA.1, IP privada del
router ADSL) y le desactivaremos FTP-Proxy Helper. Observemos que empleamos como
máscara de esta red 29 bit (255.255.255.248), ya que tenemos un proxy en 192.168.AAA.3.
[Interfaces] [WAN1]
Activamos la interfase opcional 1, le ponemos por nombre WAN1, le asignamos una IP
estática (192.168.BBB.2), indicamos cuál es su puerta de salida (192.168.BBB.1, IP privada
del router ADSL) y le desactivamos FTP-Proxy Helper. Observemos que empleamos como
máscara de esta red 30 bit (255.255.255.252), de tal forma que entre esta interfase y el
router ADSL es imposible poner nada más.
[Interfaces] [WAN2]
Seguimos los mismos pasos (que para WAN1) para la interfase opcional 2, a la que
llamaremos WAN2, le asignamos una IP estática (192.168.CCC.2), indicamos cuál es su
puerta de salida (192.168.CCC.1, IP privada del router ADSL) y le desactivamos FTP-Proxy
Helper.
[Interfaces] [Alumnes]
La interfase opcional 4 es la de la LAN de Alumnes. Le pondremos la dirección estática
192.168.YYY.1, con máscara de 24 bit (255.255.255.0). No le tenemos que poner una puerta
de enlace, ya que son las reglas del cortafuegos las que definen a través de que WAN
(WAN, WAN1 o WAN2) va el tráfico. Además, aquí dejaremos activado FTP-Proxy Helper.

[Interfaces] [Wireless]
Finalmente, la interfase opcional 3 la destinaremos a la red sin hilos (wireless), con FTP-
Proxy Helper desactivado:
Guardar la configuración
Se aconseja ir a menudo a [Diagnostics][Backup/Restore][Remote] y guardar (download) la
configuración. Genera un archivo XML a guardar. Además, el nombre de este archivo queda
serializado con la fecha/hora, por lo que en caso de problemas puede ser muy útil recuperar
la última configuración buena conocida.
Piensa que el archivo XML puede contener información delicada (llaves privadas SSL,
contraseñas, estructura de nuestra red, ...) y conviene guardarlo en lugar seguro.
También hay que tener en cuenta que haciendo pruebas nos podemos encontrar con algunas
configuraciones de comportamiento errático por lo que, ante la duda, más vale recuperar la
configuración que sabemos que funcionaba correctamente.

Alias
[Firewall] [Aliases]
Puede ser un alias un puerto, un grupo de puertos, una dirección IP o un grupo de
direcciones IP, toda una red o un grupo de redes.
Los alias no sólo ahorran escritura al configurar las reglas del cortafuegos. También permiten
realizar cambios de forma mucho más fácil, al actuar como parámetros.
Un alias definido puede emplearse o no. Si un alias es empleado en alguna de las reglas del
cortafuegos, pfSense no permite eliminarlo. A continuación se dan una serie de alias como
ejemplo:

NAT (Network Address Translation)

Configuraremos NAT para las conexiones entrantes a nuestros servicios públicos y para les
conexiones salientes …
Aquí va una imagen
[Firewall] [NAT] [Port Forward]
[Firewall] [NAT] [Outbound]

[Firewall] [NAT] [Port Forward]

Aquí configuraremos el acceso a nuestros servidores desde el exterior (puertos y puerta de
enlace). Es lo que popularmente se llama como "abrir puertos" ...

Aquí va una Imagen

[Firewall] [NAT] [Outbound]

Aquí activaremos el NAT de salida avanzado (advanced outbound) para que pfSense no nos
genere automáticamente reglas de NAT saliente. De esta forma tomamos un control total
sobre el NAT saliente.
Definiremos todas las combinaciones posibles entre nuestras LAN (LAN, Alumnes i Wireless)
y nuestras WAN (WAN, WAN1 i WAN2), tal como muestra la figura:
Aquí va una imagen
Algunas de estas combinaciones no las emplearemos, debido a que las reglas de
cortafuegos no permitirán el tráfico que aquí está previsto. Ponemos, pero, todas las
combinaciones posibles para no tener problemas de NAT en el caso eventual de autorizar
tráfico inicialmente no previsto.

Reglas del cortafuegos

Estamos ahora en el corazón del cortafuegos. Aquí se decide qué conexiones se permiten y
cuáles no.
Tenemos que entender el cortafuegos como una caja con una serie de puertas de entrada.
Se trata de dejar o no dejar entrar (paquetes de información) por cada una de las puertas que
tenemos. Este concepto es muy importante, ya que si un paquete de información puede
entrar por una puerta querrá decir que saldrá (en principio) por cualquier otra. Por tanto, en lo
que se refiere a las salidas sólo nos ocuparemos de seleccionar cuál queremos. Nada más
que esto.
Cada puerta tiene pues sus reglas, que se ejecutan según el orden en que están puestas. De
la primera hacia la última de la lista. Digo "hacia la última" porque cuando un paquete de
información cumple una de las reglas se hace la acción que dice la regla y ya no se miran las
siguientes.
¿Y qué pasa si se llega a la última regla y ninguna de ellas se ajusta a nuestro paquete de
información? Pues que el paquete no pasa. Si no hay regla, el paquete es bloqueado.
¿Y qué acciones puede hacer una regla? Pues tres: dejar pasar (pass), bloquear (block) y
rechazar (reject). La diferencia entre bloquear y rechazar es importante. Si se bloquea,
simplemente se ignora el paquete de información que se está recibiendo. Si se rechaza, se
comunica al emisor que no se quiere el paquete. Por tanto, normalmente se bloquea. ¿Por
qué? Pues porqué bloquear es silencioso, es no hacer caso al emisor y nada más.
También podemos desactivar reglas. Las reglas desactivadas se ven "difuminadas" en la lista
de reglas. Ello resulta especialmente interesante cuando se precisa de reglas ocasionales.
Por ejemplo, para tareas de administración de la red.
Todos los ordenadores cliente emplean como configuración automática de proxy el archivo
www.dominio.ejemplo/proxy.pac capaz de detectar si el proxy está disponible o no. En
caso de no estar disponible, la navegación se hace de forma directa. El contenido del archivo
proxy.pac es:

function FindProxyForURL(url, host) {

// No emplear proxy desde 192.168.XXX/24

// Hace obsoletas las regles 3 y 4 de la LAN
isInNet(myIpAddress(), "192.168.XXX.0", "255.255.255.0")
{return "DIRECT";}

// No emplear proxy para nuestros dominios

if (shExpMatch(url,"*.dominio.ejemplo/*"))
{return "DIRECT";}
if (shExpMatch(url,"*.dominio.ejemplo:*"))
{return "DIRECT";}
if (shExpMatch(url,"*.dominio.ejemplo2/*"))
{return "DIRECT";}
if (shExpMatch(url,"*.dominio.ejemplo2:*"))
{return "DIRECT";}
if (shExpMatch(url,"*/localhost/*"))
{return "DIRECT";}
if (shExpMatch(url,"*/localhost:*"))
{return "DIRECT";}

// No emplear proxy para microsoft

if (isInNet(host, "207.46.0.0", "255.255.0.0"))
{return "DIRECT";}
if (isInNet(host, "64.4.0.0", "255.255.192.0"))
{return "DIRECT";}

// Emplear proxy en el resto de casos

// Si el proxy falla o no se encuentra, va directo
return "PROXY proxy.dominio.ejemplo:8080; DIRECT";
 }

Si se desea, se pueden configurar reglas destinadas a bloquear el acceso al proxy, con el fin
de forzar las conexiones de determinados clientes de forma directa. Por tanto, no hay que
perder de vista que proxy.pac y las reglas del cortafuegos actúan conjuntamente.
¡Vamos allá, pues! A las reglas de cada una de las seis interfases ...
[Firewall] [Rules] [LAN]
[Firewall] [Rules] [WAN]
[Firewall] [Rules] [WAN1]
[Firewall] [Rules] [WAN2]
[Firewall] [Rules] [Alumnes]
[Firewall] [Rules] [Wireless]

[Firewall] [Rules] [LAN]

Explicación de las reglas:
1. Se permite cualquier acceso desde la red LAN a la red Alumnes.
2. Se permite cualquier acceso desde la red LAN a la red Wireless.
3. Se permite cualquier acceso desde los servidores (en la red LAN) al servidor proxy, situado en
la red WAN (tareas de administración). Regla desactivada (obsoleta) porqué en proxy.pac ya se
dice que la LAN va directa.
4. Se bloquea para el resto de ordenadores de la red LAN el acceso al servidor proxy (situado en la
red WAN). De esta forma se fuerza la navegación directa, sin proxy (gracias a proxy.pac). Regla
desactivada (obsoleta) porqué en proxy.pac ya se dice que la LAN va directa.
5. Cualquier ordenador de la red LAN puede ir a la red WAN, siendo la puerta de enlace la IP
privada del router ADSL (192.168.AAA.1). En la práctica esto permite llegar al router ADSL
(por ejemplo, para hacerle ping).
6. Lo mismo que 5, pero para WAN1. Permite administrar el router ADSL (192.168.BBB.1).
7. Lo mismo que 5 y 6, pero para WAN2. Permite administrar el router ADSL (192.168.CCC.1).
8. www de la red LAN accede a Internet empleando el router 192.168.AAA.1.
9. mail de la red LAN accede a Internet empleando el router 192.168.BBB.1.
10.s207 de la red LAN accede a Internet empleando el router 192.168.BBB.1.
11.s18 de la red LAN accede a Internet empleando el router 192.168.CCC.1.
12.s204 de la red LAN accede a Internet empleando el router 192.168.BBB.1.
13.s206 de la red LAN accede a Internet empleando el router 192.168.AAA.1.
14.El resto de tráfico de la red LAN saldrá hacia Internet empleando el router
192.168.AAA.1.
[Firewall] [Rules] [WAN]
Explicación de las reglas:
1. La existencia de servidores Samba/CIFS (y, lo que es lo mismo, de servicios de
archivos de Windows) en la red LAN origina paquetes del examinador de equipos que
llegan a la puerta de enlace por defecto del cortafuegos. pfSense los bloquea
automáticamente como medida de seguridad. Estos bloqueos quedan reflejados en el
log del cortafuegos. Esta regla sólo tiene la finalidad de sustituir el comportamiento
estándar de pfSense y evitar así los logs.
2. Se permite el acceso (desde la red WAN) a www de la LAN en protocolo TCP y para
los puertos estandard (HTTP, HTTPS y SSH). Esta regla se complementa con el NAT
Port Forward definido para www.
[Firewall] [Rules] [WAN1]
Las reglas corresponden a la autorización del tráfico (desde la red WAN1) para los NAT Port
Forward anteriormente definidos ...

[Firewall] [Rules] [WAN2]

Las reglas corresponden a:
• La autorización del tráfico (desde la red WAN2) del NAT Port Forward anteriormente
definido para s204.
• La autorización del tráfico (desde la red WAN2) para el port 1194, que emplea
OpenVPN. pfSense incorpora el servidor OpenVPN, que permite montar accesos
VPN. Por ejemplo, podremos conectarnos desde casa, con una IP dinámica, y ser una
máquina más de las redes gestionadas por pfSense. Todo ello garantizando nuestra
 autentificación y estableciendo un túnel encriptado a través de Internet. Para más
detalles sobre la configuración de OpenVPN, ir a la página [ OpenVPN ] de esta web.

[Firewall] [Rules] [Alumnes]

Explicación de les reglas:
1. Se permite el tráfico hacia FTP-Proxy Helper, que reside en localhost (127.0.0.1).
2. Se bloquea el acceso a la administración de pfSense desde la red Alumnes.
3. Se bloquea el acceso a servicios de Microsoft desde la red Alumnes. Este bloqueo funciona sólo
si no se pasa por el proxy que hay en la WAN. Por ello, en proxy.pac hay una regla para ir
directo en el caso de Microsoft.
4. En contraposición a la regla 2, se permiten el resto de accesos de Alumnes a Alumnes. Esta
regla es necesaria porqué la red Alumnes ve la IP de pfSense como servidor DHCP, DNS y
puerta de enlace predeterminada.
5. Regla desactivada. Si se la activa sirve para bloquear el acceso al servidor proxy situado en la
red WAN.
6. Permite el acceso a la red WAN desde la red Alumnes. Regla necesaria para poder acceder al
servidor proxy de la WAN.
7. Regla desactivada. Si se la activa permite el acceso a la red WAN1 desde la red Alumnes.
8. Regla desactivada. Si se la activa permite el acceso a la red WAN2 desde la red Alumnes.
9. Permite el acceso desde la red Alumnes a www por los puertos estandard (HTTP, HTTPS y
SSH).
10.Permite el acceso desde la red Alumnes a www por los puertos samba (servidor Samba/CIFS).
11.Permite el acceso SSH desde la red Alumnes a s207.
12.Permite el acceso desde la red Alumnes a s207 por los puertos samba (servidor Samba/CIFS).
13.Permite el acceso desde la red Alumnes a mail por los puertos correu (SMTP, POP3 SSL, HTTP
y HTTPS).
14.Permite el acceso desde la red Alumnes a s204 por el puerto 60080 (webcam).
15.Permite el acceso desde la red Alumnes a s204 por los puertos samba (servidor Samba/CIFS).
16.Permet el acceso por RDP desde la red Alumnes a s204.
17.Permite el acceso desde la red Alumnes a cb50 por el puerto 60081 (webcam).
18.Permite el acceso desde la red Alumnes a s206 por los puertos samba (servidor Samba/CIFS).
19.El resto de tráfico de la red Alumnes saldrá hacia Internet por el router ADSL
192.168.AAA.1.
[Firewall] [Rules] [Wireless]
Vistas las reglas de la red Alumnes (sin duda la más compleja), las de la red Wireless se
explican por si mismas ...
Las diferencias son que para la Wireless sólo se autorizan los servicios locales que se
tendrían si se accediese desde Internet (web, SSH, correo y webcams) y que la conexión a
Internet se hace por el router ADSL 192.168.CCC.1.
DNS (Domain Name Server)
Yendo a [Services] [DNS forwarder] activaremos el DNS (servidor de nombres) que
incorpora pfSense y, además, le diremos que haga uso de las asignaciones que realice el
DHCP de pfSense, tal como muestran las dos primeras casillas de verificación de la pantalla
que figura al final de esta página.
A pesar de que FreeBSD lleva como DNS el conocido BIND, pfSense emplea como DNS y
DHCP el demonio (daemon) dnsmasq, ideal para cortafuegos.
Es un servidor de nombres limitado pero muy rápido, que recurrirá a los servidores de
nombres especificados en la configuración básica del cortafuegos cuando no pueda resolver
un nombre.
Al emplear el DHCP de pfSense, las máquinas verán el cortafuegos como su servidor de
nombres y su puerta de enlace.
Además, podemos indicar nombres de máquinas (incluido su dominio) para forzar la
resolución del nombre de máquina hacia una determinada IP. Ello nos permite asignar IP
locales a nombres de máquina del tipo nombremaquina.dominio.ejemplo, con lo que los
usuarios podrán ver un servicio (web, correo) con el mismo nombre tanto si están en la red
local como si se conectan desde Internet (desde casa, desde una biblioteca, desde un
ciber, ...)
Resulta ideal poner en esta lista de nombres de máquina (que puedes ver en la figura de
más abajo) todas las máquinas que den servicios a la red (servidores e impresoras). De esta
forma la resolución de nombres para los servicios será altamente eficaz.
Eventualmente también se puede emplear esta asignación para bloquear/redireccionar el
acceso a alguna dirección de Internet que no interese que esté disponible. No conviene,
pero, abusar de esta funcionalidad. Si lo que pretendemos es filtrar contenidos más vale
pensar en un servidor proxy como, por ejemplo, Squid.

[Services] [DNS forwarder]

DHCP (Dynamic Host Configuration Protocol)
Emplearemos DHCP en las tres LAN (LAN, Alumnes i Wireless), mientras que en las WAN
(WAN, WAN1 y WAN2) las direcciones IP estarán configuradas de forma totalmente estática.
He tardado años en decidirme por DHCP, pero con las funcionalidades que ofrece el DHCP
de pfSense (basado en dnsmasq) he apostado por él incluso en los puntos de acceso de la
red sin hilos y las impresoras de red.
¿Qué me ha hecho decidir? Pues:
• La posibilidad de asignar direcciones IP "estáticas" en función de la dirección MAC del
dispositivo.
• La posibilidad de "capturar" fácilmente las direcciones MAC, sin tener que introducirlas
manualmente.
• La posibilidad de "cerrar" la lista de direcciones MAC, impidiendo la conexión de
dispositivos "no conocidos".
• Poder "despertar" (wake-up) dispositivos de la red para tareas de mantenimiento
remoto.
• Tener una pantalla donde tienes relacionados todos los equipos de una red.
• Eventual movilidad de equipos entre redes.
• Y, evidentemente, lo que supone intrínsecamente el uso de DHCP: olvidarme de una
vez por todas de configurar las conexiones de red de cada dispositivo (ordenador,
punto de acceso, impresora, ...) ¡Lástima que esto no pueda incluir el nombre de
máquina!
[Services] [DHCP Server] [LAN]
[Services] [DHCP Server] [Alumnes]
[Services] [DHCP Server] [Wireless]

[Services] [DHCP Server] [LAN]

Activaremos pues la casilla [Enable DHCP server on LAN interface]. Indicaremos el rango de
IP que queremos que el servidor asigne en las casillas [Range] y guardaremos los cambios.
Con ello ya tendremos DHCP activado para la interfase.
Después haremos que cada máquina tome una dirección IP determinada (fuera del rango) en
función de su dirección MAC. De esta forma cada máquina tendrá siempre la misma
dirección IP (DHCP estático). Para ello necesitamos llenar la tabla [MAC address][IP
address] [Description], pero no lo haremos (en principio) desde esta pantalla, si no que
iremos al menú [Status] [DHCP Leases] del cortafuegos:
Allí podremos emplear el botón para "capturar" la dirección MAC, asignarle una dirección IP y
modificar el comentario (inicialmente es el nombre de máquina). A partir de aquí se asignará
siempre la misma dirección IP para la máquina en cuestión. Hay que tener presente que esta
dirección IP no puede estar, naturalmente, dentro del rango de direcciones automáticas de
DHCP. La "captura" se puede hacer mientras la máquina esté en la lista [DHCP leases].
Estará en ella mientras esté conectada o no haya pasado demasiado tiempo desde su
desconexión.

Si queremos "cerrar" la red a nuevas máquinas habrá que activar una de estas dos casillas
de verificación:

Deny unknown clients. En este caso sólo se asignan direcciones IP para las máquinas que
figuran en la lista de direcciones MAC que hay al final de la pantalla. Se permite el resto de
comunicaciones con el cortafuegos.

Enable static ARP entries. Sólo las máquinas que figuren en la lista de direcciones MAC
podrán comunicarse con el cortafuegos. A pesar de que un hacker podría llegar a falsear una
dirección MAC esta opción es mucho más segura que la anterior.

¡Cuidado con "cerrar" las redes si no se han incluido todas las máquinas! Si hay máquinas
que no funcionan por DHCP habrá que mirar su dirección MAC (orden ipconfig /all en
Windows y ifconfig en Unix/Linux) y entrarlas manualmente en la lista.
[Services] [DHCP Server] [Alumnes]
De forma similar a la red LAN, activaremos DHCP en la red Alumnes y "capturaremos" sus
direcciones MAC para que cada máquina trabaje siempre con la misma dirección IP.

[Services] [DHCP Server] [Wireless]

Tal como hemos hecho en las redes LAN y Alumnes, activaremos DHCP en la red Wireless y
"capturaremos" las direcciones MAC de los puntos de acceso y de los ordenadores que
tengan tarjeta sin hilos (wireless) para que siempre trabajen con la misma dirección IP.
Agregar el Servcio OPENVPN

Portal cautivo
Yendo a [Services] [Captive portal] podemos configurar la forma en que los usuarios de una
red entran a navegar por Internet. A esta prestación se le llama portal cautivo.
El portal cautivo admite desde sencillas configuraciones donde sólo aparece una página de
información al usuario hasta distintos sistemas de validación.
Se muestra aquí cómo habilitar el portal cautivo para la red sin hilos (wireless) con una
página de información al usuario, sin autentificación y con un tiempo máximo de conexión de
30 minutos.
El código HTML cargado en Portal page contents es:
<html>

<head>
<title>wireless.dominio.ejemplo</title>
</head>

<body>

<h1><font face="Arial">wireless.dominio.ejemplo</font></h1>
<p><font face="Arial">Has entrado en nuestra red sin hilos (wireless).</font></p>

<p><font face="Arial">Esta red es un servicio público de libre acceso. Como medida legal y
de seguridad, <b>todas las conexiones que realices serán registradas y guardadas durante
un tiempo prudencial en nuestros servidores</b>.</font></p>

<p><font face="Arial">En caso de producirse algún problema legal con el uso de esta red nos
reservamos el derecho de entregar los registros de las conexiones realizadas a las
autoridades competentes.</font></p>

<p><font face="Arial"><b><font color="#FF0000">Las conexiones están limitadas a 30

minutos. Pasado este tiempo serás desconectado automáticamente.</b> Puedes, no
obstante, volver a conectarte después si lo deseas.</font></p>

<p><font face="Arial">En bien de todos/as, haz un buen uso de este servicio ...</font></p>

<p><font face="Arial">¡Gracias!</font></p>

<form method="post" action="$PORTAL_ACTION$">

<p align="center"><font face="Arial">
<input name="redirurl" type="hidden" value="$PORTAL_REDIRURL$">
<input name="accept" type="submit" value="Acepto las condiciones del servicio">
</font>
</form>

</body>

</html>

es decir, que lo que ve el usuario cuando entra por primera vez a su navegador es: