Problema

Los firewalls basados en pfSense suelen estar en producción durante meses o años. Cuando el proyecto lanza una versión mayor, como la 2.9.0, aparecen tres tipos de fricción recurrente:

  1. Actualización interrumpida – el proceso de upgrade falla o deja el appliance sin acceso a la UI.
  2. Incompatibilidad de certificados – los nuevos requisitos de fuerza TLS hacen que los certificados auto‑generados o de CAs internos dejen de ser aceptados.
  3. Nuevas opciones de NAT o algoritmos criptográficos – la configuración existente no reconoce los cambios y el tráfico comienza a comportarse de forma inesperada.

Cualquier sysadmin que haya intentado subir una versión de pfSense en un entorno de producción sabe que, aunque la actualización sea “un clic”, la realidad está en los detalles que quedan fuera del asistente gráfico.

Causa

1. Saltos de versión sin pruebas de compatibilidad

pfSense 2.9.0 incluye más de 150 parches de seguridad y cambios en la pila TLS. Si la instalación actual corre sobre 2.7.x o 2.8.x, el salto introduce nuevas dependencias de OpenSSL y modifica la forma en que se valida la longitud de claves y los algoritmos de intercambio.

2. Certificados con propiedades obsoletas

Los requisitos de “TLS Certificate Strength” descartan RSA < 2048 bits, firmas SHA‑1 y extensiones de clave pública consideradas débiles. Los certificados creados en versiones anteriores siguen almacenados en /conf/ y, al reiniciar el servicio, el firewall los rechaza.

3. Configuraciones de NAT estáticas

El “Port Restricted Cone” es una variante de NAT que depende de la tabla de estados del kernel. Si la regla NAT está escrita con la sintaxis antigua (nat → nat64), el motor no la interpreta y el tráfico saliente se bloquea.

4. Dependencias externas rotas

WireGuard se actualiza para corregir CVE‑2026‑58085. En instalaciones que usan módulos de kernel personalizados o paquetes de terceros, la recompilación automática puede fallar, dejando la interfaz inoperativa.

Solución

Paso 1 – Preparar respaldo completo

Antes de tocar el firmware, exporta la configuración completa y guarda una copia del directorio /conf/. En la consola:

cp -a /conf /conf.backup_$(date +%F)

Esto permite volver al estado previo con pfSsh.php playback restore /conf.backup_YYYY-MM-DD.

Paso 2 – Verificar requisitos de hardware y espacio

pfSense 2.9.0 necesita al menos 1 GB de RAM y 2 GB de almacenamiento libre. Usa:

sysctl -n hw.physmem
df -h /

Si el espacio es insuficiente, elimina snapshots antiguos o amplía la partición antes de continuar.

Paso 3 – Ejecutar la actualización desde la UI o la consola

En entornos sin acceso a la UI, la consola permite lanzar el upgrade con:

pfSsh.php playback upgrade

El script descarga la última imagen, verifica la firma y realiza la migración de la base de datos. Si el proceso se interrumpe, revisa /var/log/system.log para errores de checksum o de montaje.

Paso 4 – Renovar certificados TLS automáticamente

Una vez arrancado el nuevo kernel, habilita la renovación automática:

  1. Navega a System → Cert. Manager → Certificates.
  2. Marca la casilla Auto‑Renew en los certificados auto‑firmados o de la CA interna.
  3. Guarda y ejecuta una recarga de servicios:
pfSsh.php playback reload_all

Para validar que la longitud de clave y el algoritmo cumplen con los nuevos requisitos, inspecciona el certificado:

openssl x509 -in /conf/ssl/server.crt -text -noout | grep "Public Key"

Debe mostrar al menos 2048 bits y un algoritmo de firma SHA‑256 o superior.

Paso 5 – Configurar el nuevo modo NAT (Port Restricted Cone)

En la UI, crea una regla NAT bajo Firewall → NAT → Outbound y selecciona Hybrid Outbound NAT rule generation. Añade la siguiente línea en la sección “Advanced Options”:

mode=port_restricted_cone

Si prefieres la consola, edita /conf/config.xml directamente y agrega:

<nat>
  <mode>port_restricted_cone</mode>
</nat>

Luego recarga la configuración:

pfSsh.php playback reload_all

Paso 6 – Verificar la versión de WireGuard

Confirma que el módulo cargado corresponde a la versión parcheada:

kldstat | grep wireguard

Debería aparecer una línea con wireguard.ko y la versión 1.0.2026‑… Si el módulo no carga, reinstala el paquete:

pkg install -y wireguard

Paso 7 – Ejecutar pruebas de conectividad y estado

Revisa la tabla de estados NAT y los logs de TLS:

pfctl -s state | grep -i nat
cat /var/log/nginx/error.log | grep TLS

Los resultados sin errores indican que la actualización ha tomado efecto sin romper la funcionalidad existente.

Cuándo aplicar esta solución

  • Se necesita migrar a 2.9.0 porque la política de seguridad exige los últimos parches (por ejemplo, cumplimiento PCI‑DSS).
  • Los certificados actuales no cumplen con los nuevos requisitos de fuerza TLS y se requiere renovación automática.
  • Se quiere habilitar el nuevo modo NAT para entornos con clientes que requieren “Port Restricted Cone”.
  • Se usan túneles WireGuard y el CVE‑2026‑58085 está presente en la versión anterior.

No es necesario aplicar este proceso si la infraestructura está aislada, sin exposición a internet, y la política interna permite seguir usando versiones anteriores sin riesgo inmediato.

Código

# 1. Backup completo
cp -a /conf /conf.backup_$(date +%F)

# 2. Chequeo de recursos
sysctl -n hw.physmem
df -h /

# 3. Upgrade desde consola
pfSsh.php playback upgrade

# 4. Auto‑renew certificados
pfSsh.php playback reload_all

# 5. Configuración NAT experimental
sed -i '' '/<nat>/a\  <mode>port_restricted_cone</mode>' /conf/config.xml
pfSsh.php playback reload_all

# 6. Verificar WireGuard
kldstat | grep wireguard || pkg install -y wireguard

Verificación

  1. Versión del firmware – pfctl -v debe devolver 2.9.0‑RELEASE.
  2. Certificado válido – abre la UI con HTTPS y verifica que el candado no muestre advertencias de algoritmo débil.
  3. NAT activo – ejecuta pfctl -s nat y busca la regla con mode=port_restricted_cone.
  4. WireGuard operativo – wg show debe listar las interfaces sin errores.
  5. Estado de los servicios – pfSsh.php playback status_all debe reportar “OK” para todos los daemons.

Si alguna de estas comprobaciones falla, revierte al backup con:

pfSsh.php playback restore /conf.backup_YYYY-MM-DD

y revisa los logs de /var/log/system.log para identificar el punto de ruptura.

Notas adicionales

  • La opción Hybrid Outbound NAT es la única forma segura de mezclar reglas estáticas y dinámicas en la versión 2.9.0. Mantener exclusivamente “Manual” puede provocar que el motor ignore la nueva mode.
  • Cuando habilites post‑quantum key exchange (KEM), verifica que los clientes VPN soporten los algoritmos añadidos; de lo contrario, la negociación TLS fallará y los túneles se caerán.
  • En entornos de alta disponibilidad, realiza la actualización primero en el nodo secundario y sincroniza la configuración antes de pasar al primario. Esto reduce el tiempo de inactividad y permite validar la compatibilidad de la replicación de estado.
  • Si utilizas paquetes de terceros (por ejemplo, snort o suricata), revisa sus dependencias de OpenSSL después del upgrade; algunos pueden requerir recompilación manual.