pfSense es el cortafuegos con el que muchas empresas descubren que el equipo que separa su red de internet no tiene por qué costar una fortuna ni venir con una suscripción atada. Además, se instala sobre hardware común, se administra desde el navegador y hace de firewall, de enrutador y de concentrador de VPN a la vez. Esta guía explica qué es, sobre qué está construido, cómo se instala y qué hace falta para configurar pfSense de principio a fin: las interfaces, las VLAN en pfSense, las reglas de firewall que deciden qué pasa y qué no, y la VPN en pfSense por la que entra el teletrabajo. Todo ello, además, sobre un caso numérico que se sigue hasta el final.
Asimismo, está escrita en dos niveles. Si usted decide la inversión y no toca la consola, los primeros apartados, las tablas de decisión y las recomendaciones le bastan. En cambio, si administra la plataforma, encontrará el proceso de instalación, la asignación de interfaces, el orden real en que se evalúan las reglas, los comandos de diagnóstico y las cuentas para dimensionar el equipo.
Qué es pfSense y qué problema resuelve
pfSense es una distribución de software libre pensada para una sola tarea: convertir una computadora con dos o más tarjetas de red en el cortafuegos perimetral de una organización. Es decir, no es un programa que se instala encima de Windows o de Linux, sino un sistema operativo completo que toma el control del equipo entero.
El problema que resuelve es viejo y sigue vigente. Toda empresa necesita una frontera entre su red interna y el mundo, y esa frontera tiene que hacer varias cosas al mismo tiempo: filtrar el tráfico, traducir direcciones, repartir el direccionamiento, resolver nombres, terminar túneles de teletrabajo y dejar registro de todo. Por lo tanto, el equipo que hace de puerta suele acabar siendo el más caro del armario.
Ahí es donde entra este firewall de código abierto. En efecto, cubre esas funciones con una interfaz web coherente, sin licencias por usuario ni por conexión, y con un archivo de configuración único que cabe en un correo. Asimismo, su historia le da credibilidad: nació en 2004 como una bifurcación de m0n0wall y, desde entonces, lleva dos décadas en producción en miles de redes.
Sobre qué corre pfSense: FreeBSD y el filtro de paquetes pf
El sistema operativo base de pfSense es FreeBSD, no Linux. Esa decisión, tomada en el origen del proyecto, explica casi todo lo que un administrador encuentra después: en efecto, los nombres de las interfaces, el árbol de directorios, el gestor de paquetes y las herramientas de diagnóstico son las de FreeBSD.
El motor de filtrado es pf, el packet filter que OpenBSD escribió en 2001 y que FreeBSD adoptó poco después. Por eso el comando que más se usa para diagnosticar se llama pfctl, y por eso el nombre del producto empieza por esas dos letras. En consecuencia, quien ya conozca pf de OpenBSD se mueve aquí sin aprender nada nuevo.
Las versiones de pfSense y su FreeBSD base
Conviene saber qué versión de FreeBSD hay debajo, puesto que de ahí salen los controladores de red disponibles. Por ejemplo, una tarjeta reciente puede no tener soporte en una publicación antigua. La tabla resume, por lo tanto, las publicaciones vigentes según la documentación oficial de Netgate.
| Versión | Publicada | FreeBSD base | Estado |
|---|---|---|---|
| pfSense CE 2.9.0 | 20 de agosto de 2026 | 16.0-CURRENT | Con soporte |
| pfSense CE 2.8.1 | 4 de septiembre de 2025 | 15.0-CURRENT | Con soporte |
| pfSense CE 2.8.0 | 28 de mayo de 2025 | 15.0-CURRENT | Sin soporte |
| pfSense Plus 26.07 | 13 de agosto de 2026 | 16.0-CURRENT | Con soporte |
| pfSense Plus 26.03.1 | 27 de mayo de 2026 | 16.0-CURRENT | Con soporte |
Sobre esa base corren después las piezas conocidas: nginx sirve la interfaz web, PHP la genera, strongSwan levanta los túneles IPsec y unbound resuelve los nombres. Es decir, nada aquí es exótico, y sin duda esa es una ventaja cuando algo falla a las once de la noche.
pfSense CE frente a pfSense Plus: cuál elegir
Hay dos productos con el mismo nombre y conviene no confundirlos, ya que la diferencia es de licencia y de soporte, no de calidad. En primer lugar, la Community Edition —pfSense CE— es software libre bajo licencia Apache 2.0, se descarga sin registro y puede usarse en una empresa sin pagar nada. En segundo lugar, pfSense Plus es la versión de Netgate, de código cerrado, que viene instalada en sus equipos y se vende por suscripción.
| Criterio | pfSense CE | pfSense Plus |
|---|---|---|
| Licencia | Apache 2.0, código abierto | Propietaria, de Netgate |
| Costo | Sin costo, uso comercial permitido | Suscripción o incluida con el equipo |
| Numeración | Clásica: 2.8.1, 2.9.0 | Por fecha: 25.11, 26.03, 26.07 |
| Soporte del fabricante | Comunidad y foros | Soporte contratable |
| Funciones nuevas | Llegan más tarde o no llegan | Primero, y algunas en exclusiva |
| Hardware | Cualquier equipo amd64 | Equipos Netgate y plataformas admitidas |
Cuál conviene a cada organización
El criterio práctico es sencillo. Si su organización tiene quien administre el equipo y acepta apoyarse en la comunidad, entonces la edición libre cubre el caso completo. En cambio, si necesita un tercero con obligación contractual de responder, o si compra el aparato ya armado, el camino natural es Plus. Sin embargo, hay un matiz que conviene anotar: Netgate concentra el desarrollo nuevo en Plus, así que la distancia entre ambas crece con los años.
Un aviso que ahorra disgustos: la antigua modalidad gratuita Home+Lab de pfSense Plus dejó de ofrecerse. Por lo tanto, quien busque una opción sin costo para un laboratorio debe descargar la edición libre y, de paso, no perder tiempo buscando la otra.
Arquitectura soportada y requisitos de hardware de pfSense
Aquí hay una respuesta corta y una larga. La corta: pfSense CE solo corre en amd64, es decir, en procesadores de 64 bits compatibles con x86-64, sean Intel o AMD. Además, no hay imagen de 32 bits desde hace años y tampoco hay imagen ARM para instalar en hardware genérico.
La larga añade el matiz que explica la confusión habitual: sí existen equipos con procesador ARM que ejecutan este cortafuegos, pero son aparatos de Netgate y llevan pfSense Plus con una imagen compilada para ese modelo. Es decir, ARM aquí no es una arquitectura que uno pueda elegir, sino la consecuencia de comprar cierto equipo.
| Recurso | Mínimo oficial | Recomendado para una empresa pequeña |
|---|---|---|
| Procesador | amd64 (x86-64) de 64 bits | 4 núcleos con instrucciones AES-NI |
| Memoria | 1 GB | 8 GB |
| Disco | 8 GB | SSD de 120 GB |
| Red | Una o más tarjetas compatibles | Cuatro puertos Intel de 1 GbE o dos de 2,5 GbE |
| Instalación | Memoria USB o unidad óptica | Memoria USB, imagen memstick |
La distancia entre las dos columnas sorprende a mucha gente: en efecto, la recomendación pide ocho veces la memoria y quince veces el disco del mínimo. Y la razón no es el filtrado, que consume muy poco, sino tres cosas que llegan después: los registros, los paquetes añadidos y la tabla de estados. Volveremos a ello con números al final.
La tarjeta de red decide el rendimiento
Hay un detalle de hardware que pesa más que el procesador: la tarjeta de red. La documentación de Netgate es explícita en que las tarjetas baratas consumen mucha más CPU que las de gama alta. De hecho, en la práctica un puerto Intel frente a uno genérico cambia el resultado a igualdad de procesador. Por lo tanto, ahorrar en la tarjeta suele salir caro.
Usos más comunes de pfSense y beneficios reales
En las redes que uno se encuentra a diario, este cortafuegos aparece casi siempre en los mismos papeles. Por ejemplo, la tabla los ordena de más a menos frecuente, con lo que aporta cada uno.
| Uso | Qué hace | Qué aporta |
|---|---|---|
| Firewall perimetral | Filtra lo que entra y sale de internet | Política única y registro de todo |
| Enrutador entre VLAN | Comunica las redes internas y las aísla | Un invitado deja de ver la contabilidad |
| Concentrador de VPN | Termina túneles de teletrabajo y entre sedes | Acceso remoto sin publicar servicios |
| Balanceo de enlaces | Reparte o conmuta entre dos proveedores | La oficina no se queda sin internet |
| Servidor DHCP y DNS | Reparte direcciones y resuelve nombres | Un servicio menos que administrar aparte |
| Portal cautivo | Exige identificación en la red de visitas | Trazabilidad de quién usó la red |
| Reparto de ancho de banda | Prioriza tráfico sensible al retardo | Las videollamadas dejan de cortarse |
Los cuatro beneficios que inclinan la decisión
En primer lugar, el costo: no hay licencia por usuario, por túnel ni por regla, así que crecer no cuesta más. Viene después la transparencia, puesto que la configuración entera vive en un archivo XML que se descarga, se versiona y se restaura en minutos.
En tercer lugar, la independencia del hardware. Si el equipo se avería, se instala en otro cualquiera, se restaura el respaldo y la red vuelve; con un aparato cerrado, en cambio, hay que esperar al reemplazo del mismo modelo. Y por último, la visibilidad: el panel muestra los estados abiertos, el tráfico por interfaz y los registros del filtro sin comprar nada aparte.
Lo que pfSense no hace
Un artículo honesto sobre pfSense tiene que decir también dónde termina. Porque la mayoría de los proyectos que salen mal no fallan por la herramienta, sino por haberle pedido algo que nunca prometió.
- No se administra solo. Las reglas envejecen, los registros hay que mirarlos y, además, las actualizaciones no se aplican por sí mismas.
- No sustituye a la protección del puesto de trabajo. El tráfico cifrado que sale del navegador le resulta opaco, como a cualquier cortafuegos de red.
- No tiene soporte del fabricante en la edición libre. Si a las tres de la mañana hace falta alguien al teléfono, entonces eso se contrata aparte.
- No perdona un diseño de red malo. Si todo está en una sola red plana, el firewall no ve ese tráfico y, por lo tanto, no puede filtrarlo.
- No es un equipo desechable. Es el punto por el que pasa todo, así que su avería deja a la empresa sin internet.
Ese último punto merece atención. Un cortafuegos perimetral es, por definición, un punto único de falla, y la forma de tratarlo es la misma que con cualquier otro servicio crítico: con un segundo equipo y un mecanismo de conmutación, o bien con un plan claro de reemplazo. De hecho, el asunto se trata a fondo en la guía sobre alta disponibilidad.
Cómo se instala pfSense paso a paso
Preparar el medio de instalación
La descarga oficial ofrece dos formatos. Por un lado, la imagen memstick se escribe en una memoria USB y es la vía normal para hardware físico. Por otro, la imagen ISO sirve para máquinas virtuales y para equipos con unidad óptica. Además, cada una viene en variante VGA y en variante serial, para equipos sin salida de vídeo.
Antes de escribir nada, compruebe la huella SHA-256 que publican junto al archivo. Es un minuto de trabajo y, sin embargo, descarta de golpe una descarga corrupta o manipulada, que es la clase de problema que después cuesta días de diagnóstico.
El instalador, pantalla por pantalla
El instalador es en modo texto y se recorre con las flechas. Pide, en este orden, el tipo de terminal si la conexión es serial, la aceptación de la licencia, la distribución del teclado y el esquema de particionado. Por lo tanto, todo el proceso cabe en menos de diez minutos si el hardware coopera.
Conviene saber, asimismo, que el instalador es en línea: descarga parte de lo que necesita, así que el equipo debe tener salida a internet por el puerto que vaya a ser la WAN. Es decir, no intente instalar en una sala sin conectividad y luego preguntarse por qué se detiene.
ZFS o UFS: qué elegir
En el particionado se elige entre ZFS y UFS. La recomendación práctica es ZFS y la razón es el corte de luz, ya que ZFS soporta mucho mejor un apagado brusco, que es exactamente lo que le pasa a un firewall de oficina. Además, permite instantáneas del sistema antes de una actualización, con lo que volver atrás deja de ser una aventura.
Con un solo disco se elige stripe, que no es redundancia sino simplemente el volumen. Con dos discos iguales, en cambio, se elige mirror, y ahí sí el equipo sobrevive a la avería de uno. Si esos términos le suenan lejanos, la guía de niveles de RAID los explica con detalle.
Primer arranque de pfSense: asignar las interfaces
Tras el primer reinicio aparece la pregunta que más confunde a quien llega de otros productos: qué tarjeta física es la WAN y cuál la LAN. El sistema las nombra con la convención de FreeBSD —em0, igb1, ix0— y, sin embargo, ese nombre no dice nada sobre el conector del chasis.
La forma fiable de resolverlo es la detección automática: el instalador pide desconectar todos los cables y volver a enchufar uno solo, el de la interfaz que se está asignando. Así, el propio sistema descubre cuál es. Por su parte, quien prefiera hacerlo a mano puede anotar antes las direcciones MAC de cada puerto.
Al terminar, el equipo queda con la LAN en 192.168.1.1/24 y un servidor DHCP activo en ella. En consecuencia, desde cualquier equipo conectado a ese puerto ya se entra por el navegador con el usuario admin. Sin embargo, la consola sigue haciendo falta, puesto que es la única vía cuando la interfaz web no responde.
El menú de consola de pfSense, opción por opción
| Opción | Nombre | Para qué sirve |
|---|---|---|
| 1 | Assign Interfaces | Reasignar qué tarjeta es WAN, LAN u OPT |
| 2 | Set interface(s) IP address | Cambiar direccionamiento y activar DHCP |
| 3 | Reset admin account and password | Recuperar el acceso administrativo |
| 4 | Reset to factory defaults | Dejar el equipo como salido de fábrica |
| 5 | Reboot system | Reiniciar de forma ordenada |
| 6 | Halt system | Apagar de forma ordenada |
| 7 | Ping host | Tres solicitudes ICMP para probar salida |
| 8 | Shell | Línea de comandos tcsh |
| 9 | pfTop | Ver los estados abiertos en tiempo real |
| 10 | Filter Logs | Registro del filtro en vivo |
| 11 | Restart GUI | Reiniciar el nginx de la interfaz web |
| 12 | PHP shell + pfSense tools | Ejecutar código y guiones playback |
| 13 | Upgrade from console | Actualizar sin la interfaz web |
| 14 | Enable/Disable Secure Shell (sshd) | Encender o apagar el acceso por SSH |
| 15 | Restore recent configuration | Volver a una configuración anterior |
| 16 | Restart PHP-FPM | Reiniciar el motor de PHP |
Merece la pena memorizar tres. Primero, la 3 devuelve el acceso cuando nadie recuerda la contraseña. Después, la 15 deshace un cambio que dejó la red incomunicada. Y por último, la 4 es la que nunca hay que pulsar por error. De hecho, el historial de configuraciones de la opción 15 ha salvado más noches que cualquier otra función del producto.
Configurar pfSense desde la interfaz web
La primera vez que se entra al navegador arranca un asistente. Pide el nombre del equipo, el dominio, los servidores DNS, la zona horaria, la configuración de la WAN y la de la LAN, y termina pidiendo una contraseña nueva. Es decir, es el camino más corto para configurar pfSense y dejarlo operativo.
Las dos casillas de la WAN
Sin embargo, hay dos casillas en la pantalla de la WAN que conviene entender antes de pasar de largo, puesto que vienen activadas y casi siempre deben quedarse así:
- Block private networks. Descarta el tráfico que llegue por la WAN con origen en
10.0.0.0/8,172.16.0.0/12,192.168.0.0/16o127.0.0.0/8. En efecto, esas direcciones no deben venir de internet. - Block bogon networks. Descarta el tráfico de rangos reservados o sin asignar. Además, el propio equipo mantiene esa lista al día.
Ambas se activan solo en interfaces externas. En una red interna, en cambio, estorban, porque justamente ahí el direccionamiento es privado y bloquearlo dejaría la oficina sin comunicación. Es decir, son opciones de WAN, no de LAN.
Terminado el asistente, quedan tres tareas que este no cubre y que no conviene aplazar. Primero, cambiar la interfaz web a HTTPS con un certificado propio. Después, restringir desde dónde se permite administrar el equipo. Y por último, activar el respaldo de la configuración.
El diseño de esta guía: cinco VLAN y 188 dispositivos
A partir de aquí todo se explica sobre un caso único, para que las cifras se puedan seguir. Se trata, por ejemplo, de una empresa de 85 personas en una sede, con un enlace de internet de 300 Mbps simétricos y 25 personas que trabajan desde fuera.
| VLAN | Nombre | Red | Dispositivos | Qué contiene |
|---|---|---|---|---|
| 10 | Administración | 10.20.10.0/24 | 6 | Switches, puntos de acceso y el propio firewall |
| 20 | Servidores | 10.20.20.0/24 | 14 | Servidores físicos y máquinas virtuales |
| 30 | Usuarios | 10.20.30.0/24 | 85 | Equipos de trabajo del personal |
| 40 | Invitados | 10.20.40.0/24 | 60 | Visitas y dispositivos personales |
| 50 | Impresión y planta | 10.20.50.0/24 | 23 | Impresoras y equipos de producción |
| Total | 188 | Cinco redes, una sola boca física | ||
El direccionamiento y la holgura del DHCP
Cinco redes de 24 bits dan 1.270 direcciones útiles para 188 dispositivos, es decir, una ocupación del 14,8 %. Puede parecer derroche, pero no lo es: el espacio privado no se cobra y, además, una red apretada obliga a rediseñar direccionamiento el día que la empresa crece. Por lo tanto, en redes internas conviene ser generoso.
Dentro de la VLAN de usuarios, el rango de DHCP va de .100 a .240, esto es, 141 direcciones para 85 equipos: un 66 % de holgura. En consecuencia, las primeras noventa y nueve quedan libres para asignaciones fijas, que es donde viven los equipos que deben ser siempre el mismo número.
VLAN en pfSense: cómo se crean y qué pide el switch
Configurar una VLAN en pfSense tiene dos pasos que la gente confunde a menudo, ya que uno solo no basta. Primero se crea la VLAN sobre una interfaz física; después se asigna esa VLAN como interfaz del sistema. De hecho, hasta que no se hace lo segundo, la VLAN existe pero no filtra ni enruta nada.
La creación pide tres datos: la interfaz padre —la boca física que llevará el tráfico etiquetado—, la etiqueta VLAN, que va de 1 a 4094, y una prioridad opcional de 0 a 7. Asimismo, el etiquetado sigue el estándar 802.1Q, con la marca 0x8100 por defecto; la variante 0x88a8, en cambio, solo hace falta en escenarios de doble etiquetado.
Del otro lado hace falta un switch administrable. El puerto que va al firewall se configura como troncal y debe llevar etiquetadas las cinco VLAN del caso. Por su parte, los puertos donde se conectan los equipos van sin etiqueta, cada uno en la VLAN que le corresponde. Si el switch no admite 802.1Q, entonces esta configuración no es posible y el proyecto se queda sin su base.
La trampa del troncal compartido
Aquí aparece la trampa de rendimiento más común. Con las cinco VLAN sobre un solo troncal de 1 GbE, el tráfico entre dos VLAN cruza ese cable dos veces: una al subir al firewall y otra al bajar. En consecuencia, el rendimiento efectivo entre redes cae a la mitad, unos 55 MB/s reales.
La cuenta lo deja claro. Por ejemplo, una copia nocturna de 200 GB desde la VLAN de usuarios a la de servidores tarda 1 hora y 1 minuto con un troncal compartido. En cambio, si servidores y usuarios cuelgan de bocas físicas distintas del firewall, el mismo respaldo baja a 30 minutos. Es decir, separar esas dos redes en puertos propios reduce el tiempo a la mitad sin gastar un peso más en enlaces.
Quien venga de un entorno virtualizado reconocerá el patrón, puesto que es la misma decisión que se toma al segmentar en un hipervisor, descrita en la guía del firewall de Proxmox. Y si los conceptos de red subyacentes le quedan lejos, entonces conviene repasar antes la guía de red de área local.
Reglas de firewall en pfSense: cómo se procesan
El orden manda, siempre
Este es el apartado que decide si una configuración funciona o solo lo parece. Las reglas de firewall se evalúan de arriba abajo y el proceso se detiene en la primera coincidencia. Es decir, no se sigue leyendo, no gana la más específica y tampoco hay prioridades: gana la primera que encaje.
Además, las reglas de las pestañas de interfaz se aplican siempre en sentido entrante sobre esa interfaz. Esto es, se escriben desde el punto de vista del tráfico que llega al firewall desde esa red, no del que sale hacia ella. Sin embargo, hay una excepción: las reglas flotantes sí pueden actuar en cualquier sentido.
El orden de evaluación entre las tres clases es fijo. En primer lugar van las flotantes, después las de grupo de interfaces y por último las de interfaz. Y al final de todo hay una regla implícita que descarta en silencio lo que no encajó en ninguna: la negación por defecto.
Estados, y por qué no hay reglas de salida
Todas las reglas son con estado por omisión. Cuando una regla permite tráfico, el firewall crea una entrada en la tabla de estados y, gracias a ella, el tráfico de vuelta queda autorizado automáticamente. Por lo tanto, no hay que escribir la regla de retorno, y quien viene de equipos que sí la exigen tarda un rato en creérselo.
Las tres acciones posibles son Pass, Block y Reject. La diferencia entre las dos últimas importa: en efecto, Block descarta el paquete sin avisar a nadie, mientras que Reject devuelve un mensaje de rechazo al origen. En interfaces internas conviene Reject, ya que el usuario recibe un error inmediato en lugar de esperar treinta segundos.
El ejemplo que enseña el orden: la red de invitados
La VLAN 40 del caso debe salir a internet y no debe ver nada de la red interna. Parece un requisito simple y, sin embargo, es donde más veces se falla, porque el orden de dos reglas lo cambia todo.
| Orden | Acción | Origen | Destino | Puerto | Para qué |
|---|---|---|---|---|---|
| 1 | Pass | VLAN40 net | Dirección de esta interfaz | 53 (TCP y UDP) | Resolver nombres contra el firewall |
| 2 | Block | VLAN40 net | alias RedesPrivadas | Cualquiera | Aislar a las visitas de la red interna |
| 3 | Pass | VLAN40 net | Cualquiera | Cualquiera | Salida a internet |
| — | Block | Regla implícita de negación por defecto | Lo que no encajó arriba | ||
Si se invierten la 1 y la 2, entonces la red de invitados se queda sin resolver nombres y, con ello, sin internet aparente. El motivo es que la dirección del firewall en esa VLAN —10.20.40.1— está dentro de 10.0.0.0/8, así que la regla de bloqueo la alcanza primero. De hecho, es el error más frecuente de todos y su síntoma engaña: el usuario dice «no hay internet» cuando lo que no hay es DNS.
Los alias, o cómo mantener legible el conjunto
El alias RedesPrivadas del ejemplo es simplemente un nombre que agrupa los tres rangos privados. Además, los alias son la herramienta que mantiene legible un conjunto de reglas: se define una vez, se usa en muchas reglas y se actualiza en un solo sitio. En consecuencia, un firewall con alias bien puestos se audita en minutos.
Con este criterio, el caso completo se resuelve con 14 reglas explícitas: dos en administración, tres en servidores, cuatro en usuarios, tres en invitados y dos en impresión. Por su parte, la WAN no lleva ninguna de entrada mientras no se publique un servicio.
NAT en pfSense: salida y publicación de servicios
La traducción de direcciones tiene dos caras. Por un lado, la de salida convierte las direcciones privadas en la pública del enlace. Por otro, la de entrada publica un servicio interno hacia internet. Para la primera, el producto ofrece cuatro modos.
| Modo | Qué hace | Cuándo usarlo |
|---|---|---|
| Automatic | Genera las reglas solo, de las redes internas a la WAN | Por defecto; cubre la mayoría de los casos |
| Hybrid | Respeta las reglas manuales y genera el resto | Cuando una sola red necesita trato distinto |
| Manual | Solo aplica lo que se escriba a mano | Escenarios complejos con varias salidas |
| Disabled | Desactiva toda la traducción de salida | Cuando todas las redes ya son públicas |
Publicar un servicio, o mejor no publicarlo
El modo híbrido es el que resuelve el caso de esta guía sin complicar nada. En efecto, se deja la generación automática para las cuatro VLAN normales y se añade una regla manual para la de invitados, de modo que salga por una dirección distinta si el enlace tiene varias.
La publicación de servicios se hace con una redirección de puerto y, además, hay una advertencia que no sobra: cada puerto publicado es una puerta nueva. Antes de abrir el 3389 de un escritorio remoto, por ejemplo, compare el esfuerzo con el de levantar una VPN, que resuelve lo mismo sin exponer nada. De hecho, es la conversación que más veces evita un incidente.
VPN en pfSense: IPsec, OpenVPN y WireGuard
La VPN en pfSense se puede montar con tres tecnologías y, aunque elegir mal no rompe nada, sí cuesta horas de administración. Por lo tanto, la tabla resume el criterio que la propia documentación de Netgate recomienda.
| Criterio | IPsec | OpenVPN | WireGuard |
|---|---|---|---|
| Entre sedes con equipos de otra marca | La mejor opción | Solo si ambos extremos lo tienen | Solo si ambos extremos lo tienen |
| Teletrabajo | Correcto, con cliente nativo | Muy usado, con exportador de clientes | Sencillo, pero sin automatismos |
| Complejidad | Alta: muchas opciones | Media: exige certificados | Baja: muy pocas opciones |
| Puertos y NAT | Sensible a la traducción | Un solo puerto, muy tolerante | Un solo puerto UDP, muy tolerante |
| Rendimiento | Alto, integrado en el sistema | Menor sin aceleración | Alto, integrado en el sistema |
| Muchos usuarios | Escala sin problema | Se gestiona bien | Se vuelve pesado |
Para el caso de esta guía —25 personas en teletrabajo— OpenVPN es la elección razonable, ya que el exportador de clientes genera el archivo de cada persona y el asistente cubre la configuración habitual. Y para unir esta sede con la de un socio que tiene otro fabricante, en cambio, IPsec, que es lo único que hablan todos.
Las reglas del túnel, que casi nadie recuerda
Hay un detalle que sorprende al principio: los túneles tienen sus propias pestañas de reglas. Es decir, levantar la VPN no autoriza nada por sí solo, puesto que hace falta escribir en la pestaña del túnel qué puede alcanzar quien entra por ahí. Por lo tanto, una VPN recién montada que «no llega a los servidores» casi nunca está rota, sino sin permisos.
Sobre el dimensionado, además, cifrar consume procesador. En el caso de la guía, con un pico de 12 personas conectadas a 2,5 Mbps cada una, el equipo cifra 30 Mbps. En efecto, es una carga modesta para cualquier procesador con instrucciones AES-NI, y ese es justamente el motivo de exigirlas en la tabla de hardware.
Servicios que asume el firewall: DHCP, DNS y certificados
Un cortafuegos perimetral acaba prestando servicios que no son de filtrado y, por lo tanto, conviene decidirlo a propósito y no por inercia. Los tres habituales son el reparto de direcciones, la resolución de nombres y la emisión de certificados.
DHCP: la transición de ISC a Kea
En DHCP hay una transición en marcha que merece atención. El producto trae dos motores: por un lado el clásico ISC DHCP y, por otro, Kea, el sustituto moderno del mismo consorcio. Asimismo, la documentación es explícita en que ISC está declarado obsoleto y se retirará en versiones futuras. En consecuencia, toda implantación nueva debería arrancar ya con Kea, mientras que las existentes deberían planificar el cambio.
DNS propio y certificados automáticos
En DNS, el equipo trae un resolutor propio que responde a la red interna y consulta hacia fuera. Funciona bien y ahorra un servidor, pero tiene un límite claro: si la empresa usa un directorio corporativo, entonces los nombres internos deben resolverse contra él y no contra el firewall. De hecho, la guía del servidor DNS desarrolla ese reparto de papeles.
Sobre certificados, el paquete ACME automatiza la obtención y la renovación de certificados gratuitos. Sirve tanto para la propia interfaz de administración como para los servicios publicados. Además, evita la caducidad olvidada, que sigue siendo una de las causas más tontas de caída de un servicio.
Paquetes de pfSense: qué añadir y qué pensar dos veces
El gestor de paquetes ofrece más de sesenta añadidos oficiales. Son cómodos, sin embargo, cada uno consume memoria, disco y tiempo de administración. Por lo tanto, la regla sana es instalar lo que se vaya a mirar y nada más.
| Paquete | Qué aporta | Consideración |
|---|---|---|
| pfBlockerNG | Listas de bloqueo por dirección y por dominio | Muy útil; vigile el consumo de memoria |
| ACME | Certificados automáticos y su renovación | Prácticamente obligatorio |
| HAProxy | Balanceo y publicación de sitios web | Potente, pero es un producto en sí mismo |
| ntopng | Consumo de ancho de banda por dirección | Exige memoria y disco con holgura |
| Suricata o Snort | Detección y prevención de intrusiones | Requiere revisar alertas a diario; sin eso, no sirve |
| Agente de monitoreo | Envía métricas a una plataforma externa | La vía recomendable para vigilar el equipo |
Sobre el último, conviene insistir. Un firewall sin monitoreo externo se vigila a sí mismo, lo cual es inútil justamente el día que se cae. Por lo tanto, lo razonable es que sus métricas viajen a una plataforma aparte, como la que describe la guía de Zabbix, y que las alertas salgan de ahí.
Comandos más usados en pfSense
La consola se abre con la opción 8 del menú, por SSH o desde Diagnostics > Command Prompt en la interfaz web. Esta última, sin embargo, tiene una limitación que conviene recordar: no es interactiva, así que un vi o un ping sin límite de conteo se quedan colgados sin devolver nada.
Diagnóstico del filtro con pfctl
| Comando | Qué muestra o hace |
|---|---|
pfctl -sr | El conjunto de reglas de filtrado cargado |
pfctl -sn | Las reglas de traducción de direcciones |
pfctl -sa | Todo: filtrado, NAT, tablas y contadores |
pfctl -vvsr | Las reglas con su número, contadores y aciertos |
pfctl -ss | La tabla de estados abierta en este momento |
pfctl -si | Estadísticas generales del filtro |
pfctl -t tabla -T show | El contenido de una tabla o alias |
pfctl -T flush -t sshguard | Vacía la tabla de bloqueos por intentos fallidos |
pfctl -f /tmp/rules.debug | Recarga el conjunto de reglas generado |
pfctl -d · pfctl -e | Desactiva o activa el filtro por completo |
El más valioso del conjunto es pfctl -vvsr. En efecto, muestra cuántos paquetes ha tocado cada regla, y una regla con contador en cero después de una semana es una regla que sobra o que está mal escrita. Es decir, ese comando convierte una auditoría de reglas en un trabajo de diez minutos.
Guiones de recuperación con pfSsh.php
La opción 12 del menú abre un intérprete propio con guiones ya escritos. Además, se invocan con playback y resuelven situaciones concretas sin tocar la configuración a mano.
# Certificado nuevo para la interfaz web y reinicio del servidor
pfSsh.php playback generateguicert
# Regla temporal de acceso total en la WAN (uso puntual, para recuperar el acceso)
pfSsh.php playback enableallowallwan
# Ver el estado y las estadisticas de las puertas de enlace
pfSsh.php playback gatewaystatus
# Buscar reglas escondidas en los anclajes de paquetes y funciones
pfSsh.php playback pfanchordrill
# Contenido de todas las tablas del filtro
pfSsh.php playback pftabledrill
# Activar el acceso por SSH
pfSsh.php playback enablesshd
# Controlar un servicio del firewall
pfSsh.php playback svc restart unboundHay una limitación documentada que conviene tener presente, puesto que ahorra un diagnóstico inútil: el intérprete no está pensado para encadenar varios guiones en una misma sesión. Por lo tanto, después de ejecutar uno hay que salir y volver a entrar.
Recuperación del acceso y comandos del sistema
# Restablecer la cuenta de administrador desde la consola
/etc/rc.initial.password
# Abrir un puerto a una IP concreta sin entrar a la interfaz web
easyrule pass wan tcp 203.0.113.25 10.20.20.10 443
# Ver las interfaces y sus direcciones
ifconfig -a
# Tabla de rutas
netstat -rn
# Capturar trafico en una interfaz concreta, con limite de paquetes
tcpdump -ni em0 -c 100 port 53
# Seguir el registro del filtro en vivo
tail -f /var/log/filter.log
# Procesos, por hilo, ordenados por consumo
top -aSH
# Reinicio ordenado
/sbin/rebootDe esa lista, easyrule es la que más veces salva una situación, ya que permite abrir una regla desde la consola cuando la interfaz web quedó inalcanzable, sin tener que reconstruir nada. Y tcpdump con -c, por su parte, es la forma correcta de capturar sin dejar el comando corriendo para siempre.
Dimensionar el equipo de pfSense con números
Llega la pregunta que todo el mundo hace al final: qué equipo hace falta. Se responde, sin embargo, con tres cuentas y no con una sensación.
La primera es la tabla de estados. El firewall reserva por defecto el 10 % de la memoria total para ella y, además, cada estado ocupa cerca de 1 KB, es decir, aproximadamente 1 MB por cada mil estados. Por lo tanto, con 8 GB de memoria el valor por defecto queda en unos 819.200 estados.
| Cuenta | Operación | Resultado |
|---|---|---|
| Estados que necesita el caso | 188 dispositivos × 50 estados | 9.400 estados |
| Estados disponibles con 8 GB | 10 % de 8.192 MB ÷ 1 KB | 819.200 estados |
| Ocupación de la tabla | 9.400 ÷ 819.200 | 1,1 % |
| Tráfico a filtrar | 300 Mbps de enlace | 300 Mbps |
| Tráfico a cifrar | 12 túneles × 2,5 Mbps | 30 Mbps |
| Copia entre VLAN por troncal | 200.000 MB ÷ 55 MB/s | 1 h 01 min |
| La misma con puertos separados | 200.000 MB ÷ 110 MB/s | 30 min |
La conclusión que casi nadie espera
Y es esta: la tabla de estados no es el límite. En efecto, una empresa de este tamaño usa el 1,1 % de lo que el equipo ofrece de serie, así que subir ese parámetro no mejora nada y solo consume memoria. Lo que sí manda, en cambio, es el procesador y, sobre todo, la calidad de la tarjeta de red.
Por eso la recomendación del caso es un equipo de cuatro núcleos con AES-NI, 8 GB de memoria, un disco de estado sólido de 120 GB y puertos Intel. Con eso, los 300 Mbps del enlace y los 30 Mbps cifrados quedan holgados y, además, sobra margen para pfBlockerNG y para los registros de un año.
Sobre virtualizar el firewall en lugar de dedicarle un equipo, se puede y funciona, aunque con dos condiciones: que las tarjetas de red se pasen de forma dedicada y que el hipervisor no dependa de ese mismo firewall para arrancar. De hecho, la guía de Proxmox explica cómo se reparten esas interfaces.
Respaldo y actualizaciones de pfSense
Toda la configuración —reglas, interfaces, VPN, usuarios, certificados— vive en un único archivo config.xml. Se descarga desde la interfaz web en segundos y cabe en un correo. Sin duda, esa es la mejor propiedad del producto: una recuperación completa consiste en instalar el sistema en cualquier equipo y subir ese archivo.
Ocho recomendaciones para operar pfSense
- Descargue el respaldo después de cada cambio y guárdelo fuera del propio firewall, ya que un archivo que solo existe en el equipo averiado no es un respaldo.
- Cifre el respaldo al descargarlo, puesto que contiene claves de VPN y contraseñas.
- Actualice en ventana, nunca en caliente, porque el equipo reinicia y la oficina se queda sin salida durante un par de minutos.
- Tome una instantánea de ZFS antes de actualizar, si instaló con ese sistema de archivos.
- No exponga la interfaz de administración a internet. Si hace falta entrar desde fuera, entonces que sea por VPN.
- Documente cada regla en su campo de descripción, ya que dentro de dos años nadie recordará por qué se abrió ese puerto.
- Revise los contadores con
pfctl -vvsrcada trimestre y, además, elimine lo que no se usa. - Vigile el equipo desde fuera, con un agente que envíe métricas a una plataforma de monitoreo.
Una recomendación más, que no es técnica y pesa igual: deje por escrito quién puede tocar el firewall y con qué procedimiento. De hecho, la mayoría de las caídas que se atribuyen al equipo son en realidad un cambio hecho a las seis de la tarde sin avisar a nadie.
Preguntas frecuentes sobre pfSense
¿Es realmente gratuito para una empresa?
Sí. La Community Edition se distribuye bajo licencia Apache 2.0 y, por lo tanto, puede usarse en una organización comercial sin pagar nada, siempre que se respeten los términos de esa licencia. Lo que no incluye, en cambio, es soporte del fabricante.
¿Sirve un equipo viejo de oficina?
Técnicamente sí, si es de 64 bits. En la práctica, sin embargo, conviene pensarlo dos veces: un equipo de escritorio antiguo tiene fuente de alimentación cansada y disco mecánico, y además estará encendido las veinticuatro horas. Para un laboratorio es perfecto; para producción, en cambio, no.
¿Cuántas VLAN admite?
El estándar 802.1Q permite etiquetas de 1 a 4094, y ese es el límite real. Sin embargo, mucho antes de acercarse a esa cifra el freno lo pondrán el troncal compartido y el trabajo de mantener las reglas de cada red.
¿Qué pasa si se pierde la contraseña de administrador?
Se recupera desde la consola con la opción 3 del menú, o bien ejecutando /etc/rc.initial.password. Hace falta acceso físico o por consola serial, que es justamente la razón por la que ese acceso debe estar controlado.
¿Conviene pasar de pfSense a OPNsense?
Son dos proyectos con el mismo origen y filosofías distintas. Además, la decisión rara vez se toma por funcionalidad, puesto que ambos cubren lo mismo en una empresa mediana; se toma por el modelo de publicaciones y por con cuál se siente cómodo quien lo va a administrar.
Qué hacer con esta guía de pfSense
Si va a montarlo por su cuenta, el orden que funciona es este. Primero, instale sobre ZFS. Después, asigne las interfaces con el método de desconectar y reconectar. Luego cree las VLAN antes de escribir una sola regla y, por último, deje la red de invitados para el final, porque es la que enseña el orden de evaluación. Al terminar, descargue el respaldo y guárdelo fuera del equipo.
Verifique además tres cosas antes de dar por buena la instalación: que pfctl -vvsr muestre contadores subiendo en las reglas que deben usarse, que la red de invitados resuelva nombres y no vea la red interna, y que el respaldo restaurado en un equipo de prueba levante la configuración completa. De hecho, eso último casi nadie lo prueba, y sin embargo es lo único que convierte un archivo en un respaldo de verdad.
Y si lo que necesita es que alguien administre el perímetro todos los días —reglas revisadas, registros mirados, actualizaciones en ventana y segmentación mantenida—, entonces esa es exactamente la conversación de nuestro servicio de redes y conectividad. La herramienta es gratuita; sostenerla bien, en cambio, es el trabajo.
Documentación consultada para esta guía: el historial de versiones, el menú de consola y la elección de VPN de Netgate.
