En Logs Explorer, cada fase del túnel tiene su consulta:

Cloud VPN corre strongSwan por debajo, así que los mensajes son los de strongSwan: si conoces charon, ya sabes leerlos.

Qué significa cada mensaje

establishing IKE_SA failed, peer not responding. Cloud VPN manda IKE_SA_INIT y nadie contesta. En orden de probabilidad: el peer está en IKEv1 y el túnel en IKEv2 (o al revés), la IP del peer configurada no es la pública real (NAT delante del firewall), UDP 500 y 4500 no llegan al peer, o el peer ni siquiera tiene el túnel activo. La PSK no produce este mensaje: con PSK incorrecta la fase 1 arranca y falla en IKE_AUTH.

IKE_SA … established between y después nada. Fase 1 bien, fase 2 no. Busca CHILD_SA y traffic selectors.

Remote traffic selectors narrowed / Local traffic selectors narrowed. Las redes de fase 2 no coinciden en los dos lados. En HA VPN (y en Classic VPN basada en rutas) Cloud VPN propone 0.0.0.0/0 a ambos lados y espera lo mismo; un peer policy-based con subredes concretas hace que strongSwan estreche los selectores y solo pase tráfico entre lo que casó, o nada. En el peer: fase 2 con 0.0.0.0/0 local y remoto (en pfSense, modo Routed, que crea una interfaz de túnel ipsecN), y las rutas se resuelven por BGP o estáticas.

received DELETE for ESP CHILD_SA en bucle. El peer tumba la fase 2 cada pocos minutos: lifetimes de fase 2 distintos con rekey mal negociado, o DPD agresivo. Iguala lifetimes (Cloud VPN usa 3 horas en fase 2 y 10 en fase 1) y deja que el rekey lo inicie un solo lado.

Sube, pasa tráfico un rato y muere con NAT-T. Un peer detrás de NAT con UDP 4500 y un middlebox que “ayuda” (ALG de IPsec en el router) descarta paquetes ESP encapsulados. Desactiva el ALG o pasa el firewall a IP pública directa.

HA VPN con BGP contra pfSense (FRR)

El túnel sube, bgp se establece, y ninguna ruta entra ni sale. FRR en pfSense arranca con una política que rechaza todo lo que no esté permitido explícitamente:

1. Services → FRR → BGP → Route Maps: crea ALLOW-ALL, Action Permit, Sequence 100, sin criterios.
2. BGP → Neighbors → el peer de Cloud Router: Remote AS el ASN del Cloud Router, y en Peer Filtering asigna ALLOW-ALL como route map in y out.
3. BGP → Network Distribution: lista las redes locales que quieres anunciar (o Default Originate si todo va por el túnel).
4. En GCP, el Cloud Router con --advertisement-mode custom si quieres controlar qué prefijos salen; por defecto anuncia las subredes de la VPC.

Sin el paso 2, vtysh -c "show ip bgp summary" muestra la sesión Established con 0 prefijos en ambas direcciones, que es exactamente el síntoma.

Trampas

• IKEv2 salvo que el peer no pueda: IKEv1 sigue soportado, pero sin IPv6 y con menos cifrados. Classic VPN sigue existiendo (99,9 %), pero parte de su funcionalidad está retirada; lo nuevo va en HA VPN (99,99 %).
• Dos túneles por gateway en HA VPN para el 99.99 %: si solo levantas uno, el estado del gateway queda en aviso aunque funcione.
• MTU: 1460 por defecto en la VPC de GCP; con IPsec encima, deja que TCP haga MSS clamping en el peer (pfSense lo hace en la interfaz ipsecN del túnel) o verás transferencias que se cuelgan tras el handshake.
• Los logs tardan: un minuto o dos entre el evento y Logs Explorer. Refresca antes de cambiar la configuración otra vez.
• PSK con caracteres especiales copiada de un gestor de contraseñas: comprueba en el peer que no se comió nada; el síntoma es IKE_AUTH que falla, no peer not responding.

Ver también

• pfSense: NAT reflection y split DNS — el otro clásico de “el túnel está bien y aun así no llego”.
• Cloud VPN troubleshooting en la documentación de Google Cloud.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

#!/usr/bin/env python3
"""Codifica rutas classless (RFC 3442) para la opción DHCP 121."""
import ipaddress

def encode(routes):
    out = bytearray()
    for dest, via in routes:
        net = ipaddress.ip_network(dest, strict=False)
        n = (net.prefixlen + 7) // 8                 # octetos significativos del destino
        out.append(net.prefixlen)
        out += net.network_address.packed[:n]
        out += ipaddress.ip_address(via).packed
    return bytes(out)

routes = [
    ("192.0.2.0/24", "192.168.1.254"),   # la otra sede, por el router de la VPN
    ("0.0.0.0/0",    "192.168.1.1"),     # la ruta por defecto: obligatoria si mandas la 121
]
raw = encode(routes)
print("hex      ", raw.hex())
print("mikrotik ", "0x" + raw.hex())
print("isc      ", ", ".join(str(b) for b in raw))
print("pfsense  ", ":".join(f"{b:02x}" for b in raw))

1
2
3
4

hex       18c00002c0a801fe00c0a80101
mikrotik  0x18c00002c0a801fe00c0a80101
isc       24, 192, 0, 2, 192, 168, 1, 254, 0, 192, 168, 1, 1
pfsense   18:c0:00:02:c0:a8:01:fe:00:c0:a8:01:01

El formato

Cada ruta de la opción 121 son tres campos pegados, sin separadores:

Un /24 lleva tres octetos de destino, un /16 dos, un /32 cuatro, y la ruta por defecto /0 ninguno: 00 seguido directamente del router. Varias rutas se concatenan; la opción entera cabe en 255 octetos (unas 28 rutas /24).

La regla que rompe la red

RFC 3442, sección 3: “If the DHCP server returns both a Classless Static Routes option and a Router option, the DHCP client MUST ignore the Router option.” Si empiezas a mandar la 121 con una sola ruta a la otra sede, los clientes que la entienden pierden la puerta de enlace de la opción 3 y se quedan sin salida a Internet. La ruta por defecto va dentro de la 121, siempre, como en el ejemplo. Los clientes que no entienden la 121 siguen usando la opción 3, así que déjala configurada también.

Dónde se pone

ISC dhcpd (dhcpd.conf): hay que declarar la opción, y conviene mandarla también como 249, que es la que piden los Windows antiguos:

1
2
3
4
5
6
7
8
9

option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;
option ms-classless-static-routes code 249 = array of unsigned integer 8;

subnet 192.168.1.0 netmask 255.255.255.0 {
  range 192.168.1.100 192.168.1.199;
  option routers 192.168.1.1;
  option rfc3442-classless-static-routes 24, 192,0,2, 192,168,1,254, 0, 192,168,1,1;
  option ms-classless-static-routes     24, 192,0,2, 192,168,1,254, 0, 192,168,1,1;
}

Kea (2.4 o posterior) entiende la opción por nombre y con notación legible, sin hex:

1
2
3
4

"option-data": [
  { "name": "classless-static-route", "code": 121,
    "data": "192.0.2.0/24 - 192.168.1.254, 0.0.0.0/0 - 192.168.1.1" }
]

pfSense / OPNsense: con el backend ISC, Services → DHCP Server → Additional BOOTP/DHCP Options, número 121, tipo String, valor en hex con dos puntos (18:c0:00:02:…); añade otra con 249 para Windows. Con el backend Kea, la opción 121 todavía no está en la interfaz (a fecha de este post hay peticiones abiertas en los dos proyectos); si tu versión permite opciones personalizadas de Kea, usa el JSON de arriba; si no, es el motivo para seguir en ISC.

MikroTik RouterOS:

1
2
3
4

/ip dhcp-server option add name=classless code=121 value=0x18c00002c0a801fe00c0a80101
/ip dhcp-server option add name=classless-ms code=249 value=0x18c00002c0a801fe00c0a80101
/ip dhcp-server option sets add name=routes options=classless,classless-ms
/ip dhcp-server network set [find address=192.168.1.0/24] dhcp-option-set=routes

Qué clientes la entienden

Compruébalo en el cliente con ip route (Linux), route print (Windows) o netstat -rn (macOS) tras renovar el lease.

Trampas

• /32 con router en otra subred: válido en la codificación, pero el cliente necesita una ruta previa al router; ordena las rutas de más específica a menos y pon primero la del propio segmento si hace falta.
• Rutas hacia redes que el DHCP no controla (un servidor DHCP en una VLAN que anuncia rutas por otra) se aceptan igual: la 121 es una lista de texto, nadie la valida. Un error de un octeto se convierte en una ruta hacia una red inventada.
• Los clientes no revisan las rutas hasta renovar el lease; tras cambiar la opción, T1 (la mitad del lease) es lo que tardarán en verla, o fuerza la renovación.
• Windows y la 249: si solo mandas la 121, los Windows modernos la usan; la 249 es por compatibilidad y contiene exactamente los mismos bytes.
• Anuncios /0 desde un DHCP ajeno: cualquier servidor DHCP de la LAN puede reescribir la ruta por defecto de todos los clientes con la 121; DHCP snooping en el switch es la única defensa real.

Referencia: RFC 3442.

Ver también

• Cloud VPN de GCP no levanta — la VPN por la que suelen ir estas rutas.
• pfSense: NAT reflection y split DNS — el otro ajuste de LAN que los clientes reciben sin enterarse.

1
2
3
4
5
6
7
8
9

pfctl -sT                                    # tablas cargadas
pfctl -t <tabla> -T show                     # contenido
pfctl -t <tabla> -T add 192.168.1.10         # añadir IP o red (también 10.20.0.0/16)
pfctl -t <tabla> -T delete 192.168.1.10
pfctl -t <tabla> -T test 192.168.1.10        # ¿está dentro? (match / no match)
pfctl -t <tabla> -T flush                    # vaciar la tabla
pfctl -t <tabla> -T replace -f /ruta/lista   # reemplazar todo el contenido desde un archivo

pfctl -t sshguard -T flush                   # pfSense: quitar el bloqueo por intentos de login fallidos

Qué es una tabla

Una tabla de PF es un conjunto de direcciones y redes al que las reglas hacen referencia como <nombre>. Se cambia en caliente, sin recargar el ruleset, y aguanta miles de entradas con búsqueda rápida; por eso PF la usa para listas de bloqueo, bogons y cualquier cosa que cambie más a menudo que las reglas.

En pf.conf:

1
2

table <blocklist> persist file "/etc/pf/blocklist.txt"
block in quick from <blocklist>

persist mantiene la tabla aunque ninguna regla la use en ese momento; file la carga desde un archivo (una IP o red por línea).

Comandos

Todos con la forma pfctl -t <tabla> -T <comando>:

Y sin -t:

1
2
3
4

pfctl -sT                    # nombres de todas las tablas
pfctl -vvsT                  # info global por tabla: entradas, evaluaciones, referencias
pfctl -T load -f /etc/pf.conf   # recarga solo las definiciones de tabla del pf.conf
pfctl -sr | grep '<nombre>'  # qué reglas usan una tabla

Tablas en pfSense

• Los aliases son tablas. Un alias de tipo Host, Network o URL Table llamado Admins existe en PF como <Admins>; pfctl -t Admins -T show te enseña lo que resolvió pfSense, incluidos los FQDN que ya convirtió a IPs.
• sshguard: donde caen las IPs bloqueadas por intentos de login fallidos a SSH o a la webGUI. Si te bloqueaste a ti mismo, pfctl -t sshguard -T flush (documentado por Netgate en Locked out of the WebGUI).
• virusprot: hosts bloqueados por superar los límites Max. src. conn. rate o Max. states de una regla. pfctl -t virusprot -T show y -T delete <ip> para soltar a uno.
• snort2c: bloqueos de Snort/Suricata en modo legacy. -T flush para desbloquear todo.
• bogons / bogonsv6: las listas que se actualizan solas cuando activas Block bogon networks en una interfaz.
• pfBlockerNG: cada lista es un alias pfB_*. Para saber si una IP está bloqueada por alguna: pfctl -t pfB_Top_v4 -T test 203.0.113.7.

En OPNsense la mecánica es la misma (pfctl -sT para ver los nombres); la tabla de bloqueo por login se llama sshlockout.

Lo que se pierde al recargar

Cualquier -T add, -T delete o -T flush vive hasta la siguiente recarga del filtro: guardar casi cualquier cosa en la GUI, Filter Reload en Status → Filter Reload, o el cron de actualización de aliases. En ese momento pfSense regenera cada tabla desde su alias y tus cambios a mano desaparecen. Para que algo sea permanente, edita el alias; para pruebas rápidas y desbloqueos, pfctl es perfecto.

Más allá de las tablas

Lo que más se usa junto a lo anterior:

1
2
3
4
5
6
7

pfctl -sr                    # reglas cargadas (con -vv, contadores y números de regla)
pfctl -ss                    # tabla de estados
pfctl -si                    # estadísticas globales
pfctl -k 192.168.1.10        # matar los estados de un host
pfctl -F states              # matar todos los estados (corta todas las conexiones)
pfctl -d / pfctl -e          # desactivar / activar PF (sin PF no hay NAT: úsalo solo para salir de un bloqueo)
pfctl -nf /etc/pf.conf       # comprobar sintaxis sin cargar

Referencia completa: pfctl cheat sheet del OpenBSD Handbook y man pfctl en FreeBSD.

System → Advanced → Networking → Disable hardware checksum offload ✔ → Save → reinicia la VM. La GUI no avisa, pero el cambio no aplica a las interfaces vtnet hasta el reinicio.

Para probar sin reiniciar (se pierde al arrancar):

1
2

ifconfig vtnet0 -rxcsum -txcsum -tso -lro
ifconfig vtnet1 -rxcsum -txcsum -tso -lro

En OPNsense: Interfaces → Settings → Hardware CRC → Disable hardware checksum offload, y el mismo reinicio.

Síntomas

La VM arranca, las interfaces están UP, el DHCP de la LAN reparte direcciones y aun así:

• Los equipos detrás del firewall no llegan a Internet, o la conexión se queda a medias (el ping pasa, TCP se cuelga).
• Desde el propio host de virtualización o desde otras VMs del mismo host no se llega a nada protegido por pfSense, ni a la GUI.
• Cambiar la NIC de la VM a e1000 lo arregla al momento, lo que confirma el diagnóstico.

Por qué pasa

El driver vtnet de FreeBSD, con el offload de checksums activado, entrega a la pila de red paquetes cuyo checksum nunca llegó a calcularse: entre VMs del mismo host, y entre el host y la VM, el tráfico no pasa por una NIC física que lo haga. FreeBSD ve checksums inválidos y descarta (bug 165059 de FreeBSD). Netgate lo documenta en VirtIO Driver Support.

pfSense intenta marcar la opción solo cuando detecta interfaces vtnet en la instalación. Si la NIC VirtIO se añadió después, si restauraste el config.xml de un firewall físico, o si migraste la VM desde otro hipervisor con otro tipo de NIC, la opción sigue apagada.

Procedimiento

1. System → Advanced → Networking, sección Network Interfaces:

   • Disable hardware checksum offload: marcar.
   • Disable hardware TCP segmentation offload y Disable hardware large receive offload: ya vienen marcadas por defecto; déjalas así.

2. Save.

3. Reboot desde Diagnostics → Reboot. Sin este paso, nada cambia en vtnet.

4. Comprueba:

   1	ifconfig vtnet0 | grep options

   No deben aparecer RXCSUM ni TXCSUM (ni TSO4, LRO).

Si sigue igual

• Todas las NICs de la VM tienen que ser del mismo estilo. Una vtnet con offload y otra e1000 se comportan distinto; revisa cada ifconfig.
• Offload en el host. Netgate señala que a veces también hay que apagar checksums y TSO en el hipervisor. En Proxmox/KVM, sobre la interfaz tap de la VM: ethtool -K tap100i0 tx off (el número es el VMID y i0 la NIC). Es raro necesitarlo; pruébalo el último.
• Plan B: modelo de NIC e1000 en la VM. Menos rendimiento que VirtIO sin offload, pero sin este bug.

Trampas

• El reinicio no es opcional y la GUI no lo pide. Es la causa número uno de “lo marqué y sigue sin funcionar”.
• No es un problema de reglas. Con el offload activo, los paquetes se descartan antes de llegar a pf; el log del firewall no muestra nada.
• e1000 también en OPNsense como plan B; el ajuste equivalente está en Interfaces → Settings.
• Multiqueue (queues=N en Proxmox) funciona bien con vtnet una vez desactivado el offload; no lo confundas con la causa.

Opción limpia (split DNS): Services → DNS Resolver → Host Overrides → app.example.com → IP interna del servidor (192.168.1.50). Los clientes de la LAN tienen que usar el firewall como DNS.

Opción NAT reflection: System → Advanced → Firewall & NAT:

• NAT Reflection mode for port forwards: Pure NAT
• Enable NAT Reflection for 1:1 NAT: ✔
• Enable automatic outbound NAT for Reflection: ✔

Save y prueba desde un cliente de la LAN contra la IP pública.

El problema

El port forward WAN:443 → 192.168.1.50:443 funciona desde Internet. Desde un equipo de la misma LAN, https://app.example.com (que resuelve a la IP pública) responde con la GUI de pfSense, un error de certificado, o Potential DNS Rebind attack detected.

El paquete sale del cliente hacia la IP pública, llega al firewall por la interfaz LAN y ahí se queda: la regla de port forward escucha en la WAN, no en la LAN, y la IP de destino es una dirección del propio firewall. Nunca “sale y vuelve a entrar”.

Opción 1: split DNS

Es la que recomienda Netgate: el nombre resuelve a la IP interna dentro y a la pública fuera. El tráfico va directo, el servidor ve la IP real del cliente y el firewall no toca nada.

1. Services → DNS Resolver → Host Overrides → Add: host app, dominio example.com, IP 192.168.1.50. Si el servicio tiene varios nombres, añade Additional Names.
2. Los clientes deben usar el firewall como DNS (lo normal si el DHCP lo entrega). Un cliente con 8.8.8.8 fijo seguirá yendo a la IP pública.
3. nslookup app.example.com desde la LAN → 192.168.1.50.

Requisitos: el puerto interno y el externo tienen que ser el mismo (si fuera reenvías 8443 → 443, el cliente interno tendrá que usar 443 directamente).

Si usas DNS Forwarder (dnsmasq) en vez del Resolver, el ajuste equivalente está en Services → DNS Forwarder → Host Overrides.

Opción 2: NAT reflection

Cuando no controlas el DNS de los clientes, o hay un montón de puertos, el firewall puede “reflejar” la conexión: reescribe el destino a la IP interna y, con el outbound NAT automático, también el origen, para que la respuesta vuelva por el firewall.

System → Advanced → Firewall & NAT, sección Network Address Translation:

También se puede activar por regla: Firewall → NAT → Port Forward → editar → NAT reflection → Enable (Pure NAT), dejando el global en Disable.

Costes: el servidor ve como origen la IP LAN del firewall (no la del cliente), y todo ese tráfico pasa por el firewall aunque cliente y servidor estén en el mismo switch.

OPNsense

Misma idea, otros menús:

• Split DNS: Services → Unbound DNS → Overrides → Host Overrides.
• Reflection: Firewall → Settings → Advanced → Reflection for port forwards, Reflection for 1:1, Automatic outbound NAT for Reflection.

Trampas

• DNS rebinding. Si en vez de un host override apuntas el Resolver a un DNS externo que devuelve IPs privadas (un DNS interno de otra sede, un proveedor con vistas), Unbound descarta esas respuestas por protección contra rebinding. No desmarques Disable DNS Rebinding Checks en System → Advanced → Admin Access: añade en Services → DNS Resolver → Custom options private-domain: "example.com" y solo ese dominio queda exento.
• El cliente con DNS fijo se salta el split DNS. O lo obligas por DHCP, o lo capturas con una regla de NAT de puerto 53, o usas reflection.
• Pure NAT necesita saber la interfaz y el gateway en el momento de cargar reglas; con WANs dinámicas que cambian de IP, un Filter Reload después del cambio de IP lo arregla.
• Puertos distintos dentro y fuera solo funcionan con reflection; split DNS no traduce puertos.
• Certificados: con split DNS el navegador sigue viendo app.example.com, así que el certificado del servidor sirve igual. Si reflejas por IP pública, también. El error de certificado del principio era el de la GUI del firewall, no el del servidor.

Referencias: Port Forwards from Local Networks y NAT Reflection en la documentación de Netgate.

1. Cloudflare → My Profile → API Tokens → Create Token → plantilla Edit zone DNS: permisos Zone → Zone → Read y Zone → DNS → Edit, Zone Resources limitado a tu zona. Copia el token; el Account ID y el Zone ID están en la página Overview de la zona.
2. pfSense → System → Package Manager → instalar acme y haproxy.
3. Services → ACME → Account keys → Add: ACME Server Let’s Encrypt Production ACME v2 (o Staging para probar) → Create new account key → Register → Save.
4. Services → ACME → Certificates → Add: nombre, la cuenta, Domain SAN list: app.example.com (y *.example.com si quieres wildcard) con método DNS-Cloudflare, y en sus campos solo Token, Account ID y Zone ID. Actions list: Restart Local Service → haproxy. Save → Issue.
5. Services → HAProxy → Frontend → editar → SSL Offloading ✔ en la dirección de escucha → Certificate: el que acaba de crear ACME → Save → Apply Changes.

Renovación automática (cron diario del paquete) y HAProxy reiniciado en cada renovación.

Cloudflare: el token

La Global API Key que piden las guías antiguas da acceso a toda la cuenta; un API token con permisos mínimos es lo correcto y es lo que el método DNS-Cloudflare del paquete usa cuando rellenas Token:

Con Token basta uno de los dos IDs; poner ambos no molesta. Permisos del token: Zone:Read y DNS:Edit sobre la zona concreta (Include → Specific zone).

Si activas Client IP Address Filtering en el token, tiene que incluir la IP pública IPv4 y también IPv6 del firewall: pfSense sale por la que tenga a mano, y un token limitado a la v4 falla en cuanto la llamada a la API va por v6.

ACME: cuenta y certificado

Cuenta. Crea dos: una contra Staging para probar y otra contra Production. Staging no tiene límites de emisión pero sus certificados no son de confianza; cuando todo funcione, cambia la cuenta del certificado a la de producción y vuelve a emitir.

Certificado. En Services → ACME → Certificates → Add:

• Domain SAN list: una entrada por nombre. Para un wildcard *.example.com la validación tiene que ser DNS-01 (HTTP-01 no lo permite). Un wildcard no cubre el apex: añade example.com como segunda entrada.
• Method: DNS-Cloudflare en cada entrada, con los tres campos.
• DNS Sleep: Cloudflare propaga en segundos; el valor por defecto sobra. Si la emisión falla por TXT not found, súbelo a 120.
• Key: RSA 2048 o ECDSA 256; ambos van bien con HAProxy.
• Actions list: Restart Local Service → haproxy. Sin esto, HAProxy sigue sirviendo el certificado viejo hasta que alguien lo reinicie, aunque ACME ya haya renovado.

Issue desde la lista de certificados. El resultado aparece en System → Certificates con el nombre que le diste; ahí lo verá HAProxy.

HAProxy: usar el certificado

Services → HAProxy:

1. Settings: activar HAProxy, y en Max SSL Diffie-Hellman size deja 2048 o más.
2. Frontend → tu frontend HTTPS → External address: puerto 443, SSL Offloading ✔ → sección SSL Offloading → Certificate: el de ACME. Para varios dominios en el mismo frontend, Additional certificates con los demás; HAProxy elige por SNI.
3. Save → Apply Changes.

Prueba desde fuera:

1
2

openssl s_client -connect app.example.com:443 -servername app.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -dates

issuer=C = US, O = Let's Encrypt y notAfter a 90 días.

De regalo, la GUI de pfSense con el mismo certificado: System → Advanced → Admin Access → SSL/TLS Certificate, y una segunda acción en el certificado ACME: Shell Command /etc/rc.restart_webgui.

Trampas

• Cloudflare en modo proxy (nube naranja) no afecta a DNS-01, pero sí a cómo llega el tráfico: si el registro A está proxificado, HAProxy ve la IP de Cloudflare como origen. Para un servicio interno detrás de pfSense, nube gris.
• Issue falla con Invalid request headers o Authentication error: token sin permiso sobre esa zona, filtro de IP del token, o Zone ID de otra zona.
• Rate limits de producción: cinco certificados por conjunto de nombres a la semana. Prueba en staging.
• El certificado se renueva; HAProxy no lo recarga solo. La acción de reinicio es obligatoria. Comprueba en Services → ACME que la última renovación tiene fecha y en openssl s_client que notAfter avanzó.
• Los ACME se renuevan a los 2/3 de vida (unos 60 días). Si ves el cron ejecutándose y nada cambia antes de eso, es normal.

Referencia: ACME package en la documentación de Netgate y la lista de proveedores DNS de acme.sh (sección dns_cf).

Desde la consola (opción 8) o Diagnostics → Command Prompt:

1
2
3
4
5
6

certctl rehash
pkg-static clean -ay
pkg-static install -fy pkg
pkg-static install -xfy pfSense-repo pfSense-upgrade
pkg-static update -f
pfSense-upgrade -d -c        # muestra qué versión ofrece la rama configurada

Con pkg vivo otra vez, termina la actualización pendiente por System → Update (o pfSense-upgrade -d), no con pkg upgrade.

El error

1

ld-elf.so.1: Shared object "libssl.so.30" not found, required by "pkg"

Lo verás al hacer pkg update, al instalar un paquete, o de forma indirecta: System → Package Manager aparece vacío y System → Update no puede comprobar versiones. A veces el binario que se queja es pfSense-repoc en vez de pkg; es el mismo problema.

Por qué pasa

pfSense es FreeBSD, y pkg es un binario enlazado dinámicamente contra la libssl del sistema. Cuando el repositorio configurado corresponde a una versión de pfSense construida sobre un FreeBSD más nuevo, sus paquetes vienen enlazados contra un OpenSSL más nuevo (libssl.so.30 = OpenSSL 3). Si pkg, o pfSense-repoc, se actualiza desde ese repo antes que el sistema base, el binario nuevo pide una biblioteca que en tu instalación todavía no existe.

Cómo se llega ahí:

• Un pkg upgrade a mano desde la shell. En pfSense no se hace nunca.
• Instalar o reinstalar un paquete después de cambiar la Branch en System → Update a una versión mayor, sin haber actualizado.
• Una actualización interrumpida a medias (fue típico en el salto 2.7.0 → 2.7.1/2.7.2, cuando la base cambió a OpenSSL 3).
• En pfSense Plus, volver a un boot environment anterior con el repo apuntando al nuevo (Redmine #15070).

El nombre de la biblioteca cambiará con las versiones; la mecánica y el arreglo son los mismos.

Arreglo

pkg-static es la copia de pkg enlazada estáticamente: no necesita libssl y por eso funciona cuando pkg no.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 1. Que pkg-static pueda hablar TLS con el repo (vale hasta el siguiente reinicio)
certctl rehash

# 2. Tirar la caché y reinstalar pkg y la configuración del repo
pkg-static clean -ay
pkg-static install -fy pkg
pkg-static install -xfy pfSense-repo pfSense-upgrade   # -x: regex, así entra también pfSense-repoc

# 3. Refrescar metadatos y comprobar
pkg-static update -f
pfSense-upgrade -d -c

Si pkg-static update sigue fallando, pkg-static -d update da la traza completa (certificados, DNS, rama equivocada).

Antes del paso 3 revisa la Branch en System → Update: debe ser la versión a la que quieres ir, no una intermedia. Y termina el trabajo por la GUI o con pfSense-upgrade -d: un pkg upgrade suelto te deja a medio camino otra vez.

Si el sistema base está tan mezclado que ni así arranca, el último recurso documentado por Netgate es pkg-static upgrade -f (reinstala todo), y tras eso reiniciar.

Trampas

• pkg upgrade no existe en pfSense. El único camino soportado es System → Update / pfSense-upgrade. Toda esta situación nace de saltárselo.
• Respaldo antes: Diagnostics → Backup & Restore. Con ZFS, además un boot environment (System → Boot Environments) te deja volver atrás en un reinicio.
• No copies libssl.so.30 de otro FreeBSD. Circula como truco; deja el sistema con bibliotecas de dos versiones y rompe la siguiente actualización.
• Paquetes primero, no. Con una actualización pendiente, actualiza el sistema y luego instala paquetes, no al revés.
• El repo y el upgrade usan HTTPS: si certctl rehash no basta, revisa hora del sistema y DNS del firewall.

Referencia: Upgrade Troubleshooting en la documentación de Netgate.

System → Certificates → Certificate Revocation → lápiz sobre la CRL que usa el servidor OpenVPN → Lifetime (Days) = 730 → Save. Guardar regenera la CRL con fechas válidas. Después, Status → Services → OpenVPN → Restart. Los clientes vuelven a entrar sin cambiar nada de su lado.

Si la GUI no te deja poner una vida sensata (versiones anteriores a 2.7 / 23.01), primero System → Patches (paquete System Patches) → aplica Fix for CRL expiration lifetime default and maximum values (a3c1589086ea67d25a28ec14ab95d7fd9ab25fa2), y luego el paso anterior. O actualiza pfSense: las versiones actuales ya lo llevan.

El error

En el log del servidor (Status → System Logs → OpenVPN) y en el cliente:

1
2
3
4

VERIFY ERROR: depth=0, error=CRL has expired: CN=client1, serial=3
OpenSSL: error:0A000086:SSL routines::certificate verify failed
TLS_ERROR: BIO read tls_read_plaintext error
TLS Error: TLS handshake failed

La pista es que fallan todos los clientes a la vez. Un certificado caducado tumba a un cliente; una CRL caducada tumba al servidor entero, porque la revisa en cada handshake.

Por qué pasa

Dos caminos llevan aquí:

1. La CRL caducó de verdad. Cada CRL tiene un nextUpdate; pasada esa fecha OpenSSL la trata como inválida y OpenVPN rechaza a todos. Una CRL creada hace años con vida corta y nunca tocada acaba así.
2. La CRL nació caducada. pfSense generaba CRLs con 9999 días por defecto, lo que las llevaba más allá de 2050. X.509 codifica las fechas hasta 2049 como UTCTime con año de dos cifras, y pfSense escribía 50 donde tocaba GeneralizedTime: OpenSSL lo lee como 1950 y la CRL “expiró” hace 75 años. Es el bug #13424 de Redmine, y explica por qué instalaciones sanas empezaron a fallar en 2022–2023 sin que nadie tocara nada: las CRLs regeneradas por cualquier cambio cruzaron el 2050.

El arreglo de Netgate bajó la vida por defecto a 730 días, limitó el máximo (2050 en 64 bits, 2038 en 32 bits) y va incluido en las versiones actuales; para las viejas quedó como parche del paquete System Patches.

Comprobarlo

pfSense escribe la CRL de cada servidor OpenVPN en su directorio de configuración:

1
2

ls /var/etc/openvpn/server1/
openssl crl -in /var/etc/openvpn/server1/crl-verify -noout -lastupdate -nextupdate

Un nextUpdate en el pasado, o un año 1950, es el diagnóstico completo.

Arreglo

1. Identifica qué CRL usa el servidor: VPN → OpenVPN → Servers → editar → Peer Certificate Revocation list.
2. Regenérala: System → Certificates → Certificate Revocation → lápiz sobre esa CRL → Lifetime (Days) 730 → Save. Cualquier guardado la reescribe con lastUpdate = ahora.
3. Reinicia OpenVPN: Status → Services. OpenVPN relee crl-verify al detectar el cambio, pero el reinicio evita esperar a que lo note.
4. Vuelve a comprobar con el openssl crl de arriba.

En una versión sin el fix, entre el paso 1 y el 2: System → Package Manager → instalar System_Patches → System → Patches → el parche aparece en la lista de recomendados → Apply. Sin él, la GUI vuelve a escribir 9999 y el problema se repite en cuanto guardes.

Trampas

• No borres la CRL para “arreglarlo”: sin CRL, los certificados que revocaste vuelven a ser válidos. Edítala.
• Una CRL por CA: si tienes varios servidores OpenVPN con CAs distintas, revisa cada una.
• Las CRLs importadas (de una CA externa) no se pueden regenerar desde pfSense; pide una nueva a tu CA y vuelve a importarla.
• 730 días también se acaban. Cualquier revocación, edición de la CRL o cambio en el servidor OpenVPN la regenera; si no tocas nada en dos años, vuelves aquí. Un aviso en el calendario cuesta poco.
• Pasado 2038 en hardware de 32 bits aplica el otro límite; en la práctica, ninguno de esos equipos debería seguir siendo tu firewall.

Referencias: Certificate Revocation List Management en la documentación de Netgate y el análisis de Pasquale Fiorillo.