Túnel IPsec lento en FortiGate: cómo activar la aceleración NPU
¿Tu túnel IPsec en FortiGate va lento? Aprende a detectar si cifra por CPU y a activar la aceleración por NPU con AES-GCM, con comandos paso a paso.
Un túnel IPsec site-to-site entre dos FortiGate puede estar "up", sin errores y con enlaces de sobra en ambos extremos, y aun así mover datos a unos pocos Mbps. Cuando una transferencia grande entre sedes va mucho más lenta de lo que permiten las líneas, una de las causas más habituales es que el tráfico del túnel se esté cifrando por CPU en lugar de por el chip de aceleración (NPU).
Descartar primero un límite de ancho de banda
Antes de mirar el cifrado conviene comprobar que no haya un traffic shaper aplicado a las políticas del túnel:
show firewall shaper traffic-shaper show firewall shaper per-ip-shaper show firewall policy
FortiOS trae shapers de fábrica como shared-1M-pipe, pero que existan no significa que se usen. Lo que importa es si alguna política del túnel tiene set traffic-shaper o set traffic-shaper-reverse. También vale la pena revisar si las interfaces WAN tienen inbandwidth u outbandwidth configurado.
Revisar la sesión con tráfico real
diagnose sys session list muestra solo lo que ocurre en ese momento. Sin tráfico activo, las sesiones aparecen con velocidad 0 y no aportan nada. Hay que lanzarlo mientras la transferencia está en marcha, y preferiblemente en el FortiGate que envía:
diagnose sys session filter clear
diagnose sys session filter dst
Si el túnel no está acelerado, verás algo así:
offload=0/0, in_npu=0/0, out_npu=0/0 ofld_fail_reason: IPsec-dec-SA-not-offloaded / IPSec-enc-SA-not-offloaded
Eso indica que las SA de cifrado y descifrado del túnel no están en el NPU y que todo el tráfico se procesa por software, paquete a paquete.
Ver qué algoritmo se ha negociado
El asistente de VPN suele dejar en la fase 2 una lista larga de propuestas:
set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256 aes128gcm aes256gcm chacha20poly1305
Prioriza la compatibilidad, pero el túnel se queda con la primera propuesta que coincide en ambos extremos, que no tiene por qué ser la más eficiente. Para saber cuál se está usando:
diagnose vpn tunnel list name <túnel>
Una salida como esta:
enc: esp=aes key=16 ah=sha1 key=20 npu_flag=00 ... enc_npuid=0 npu_isaidx=-1 npu_osaidx=-1
indica AES de 128 bits con la integridad calculada aparte mediante HMAC-SHA1, y los campos npu_* a cero o a -1 confirman que el túnel no está enganchado al chip.
La solución: dejar solo AES-GCM en la fase 2
GCM cifra y autentica en una sola pasada y es el modo con el que mejor trabaja la aceleración IPsec de los FortiGate. Basta con dejarlo como única propuesta en la fase 2, en los dos extremos:
config vpn ipsec phase2-interface edit "<nombre del túnel>" set proposal aes256gcm next end
Algunas cosas a tener en cuenta:
La fase 1 puede quedarse como está. Con IKEv1, muchas versiones de FortiOS ni siquiera ofrecen GCM en la fase 1. No es un problema, porque la fase 1 solo negocia claves periódicamente y no transporta los datos. El rendimiento depende de la fase 2.
Hay que cambiar ambos extremos seguidos. Mientras solo uno ofrece GCM no hay propuesta común y el túnel cae. No hace falta hacerlo en el mismo segundo, pero sí aplicar un cambio justo detrás del otro y fuera del horario de uso.
Los nombres de los túneles distinguen mayúsculas y minúsculas. Si en edit escribes el nombre con una letra distinta, FortiOS no da error: crea una entrada nueva vacía. Lo más seguro es hacer antes un show y copiar el nombre exacto. Si ocurre, basta con hacer delete de la entrada creada por error.
Comprobar el resultado
Tras el cambio, el túnel renegocia solo en unos segundos. En diagnose vpn tunnel list name <túnel> debería aparecer:
enc: esp=aes-gcm key=36 ah=null key=0
npu_flag=03 npu_lgwy=
aes-gcm con ah=null confirma el nuevo algoritmo, y npu_flag ya no está a 00. Justo después de renegociar, algún campo del NPU puede seguir a -1 porque apenas ha pasado tráfico. La comprobación definitiva es repetir la transferencia y revisar la sesión otra vez: offload debe ser distinto de 0/0 y el not-offloaded tiene que haber desaparecido.
Conclusión
Un túnel levantado no es necesariamente un túnel eficiente. Las propuestas por defecto están pensadas para que la VPN conecte con casi cualquier equipo, no para rendir al máximo, y el firewall puede acabar cifrando por CPU sin avisar. Antes de culpar a la línea o al proveedor, conviene revisar qué algoritmo se ha negociado y si el NPU está trabajando.
El soporte de offload varía según el modelo y el chip (NP6, NP6XLite, NP7…), así que revisa la documentación de hardware acceleration de tu equipo y verifica siempre con diagnose antes y después del cambio.
