Ir al contenido
Avanet

Usar con seguridad los ajustes VPN globales de Sophos Firewall

La Device Console de Sophos Firewall incluye bajo set vpn ajustes globales para failover de VPN, procesamiento IPsec y los protocolos heredados L2TP y PPTP. No afectan únicamente a la conexión que se está analizando. Una prueba poco precisa puede influir en otros túneles, eliminar sesiones existentes o debilitar una función de protección.

No es una receta general de rendimiento: ipsec-max-workqueue-items, la ventana anti-replay y use-resolved-ip-address no se configuran preventivamente con valores mayores ni con enable. Sophos los describe como ajustes avanzados que deben utilizarse para una necesidad concreta de red o siguiendo las indicaciones de Sophos Support.

Para problemas normales de túnel se empieza por el troubleshooting de VPN IPsec. Allí se comprueban IKE, Child SA, routing, NAT, reglas y el flujo real de paquetes. Los interruptores globales de este artículo solo son relevantes cuando el síntoma coincide exactamente con su finalidad.

Registrar el estado inicial antes de cada cambio

Los comandos se ejecutan en 4. Device Console. Antes de establecer un valor se documentan la versión y el build de SFOS, la hora, los túneles afectados, el flujo de prueba esperado y un acceso de gestión independiente. Los valores existentes se consultan por separado:

show vpn conn-remove-on-failover
show vpn conn-remove-tunnel-up
show vpn ipsec-performance
show vpn configuration

show vpn ipsec-performance muestra, entre otros, los valores de workqueue y replay. show vpn configuration es relevante para la configuración actual de L2TP y PPTP. Si un valor no aparece en la salida del build instalado, no se deduce a partir de un supuesto default. Antes de modificar un ajuste avanzado global, el cambio debe incluir un backup de configuración y Sophos Support.

El rollback utiliza siempre el valor real leído en el appliance. default no está documentado como rollback universal para estos comandos VPN y no se utiliza por suposición.

Sesiones durante cambios de túnel y WAN

conn-remove-tunnel-up determina si se eliminan conexiones existentes cuando se establece un túnel IPsec. Puede ser importante si un flujo comenzó por otra ruta y queda fijado en ella después de levantarse el túnel. La eliminación también puede interrumpir sesiones productivas. Las configuraciones nuevas usan disable de forma predeterminada desde SFOS 19.0; los sistemas migrados pueden conservar un valor anterior.

set vpn conn-remove-tunnel-up enable
set vpn conn-remove-tunnel-up disable

conn-remove-on-failover controla la limpieza global durante failover y failback. all afecta a todas las conexiones, mientras que non-tcp limita la limpieza al tráfico no TCP, como UDP o ICMP. El valor adecuado no es solo una decisión de VPN: VoIP, videoconferencia, DNS y otras aplicaciones UDP deben observarse en la misma ventana de prueba.

set vpn conn-remove-on-failover all
set vpn conn-remove-on-failover non-tcp

Sophos cambió estos defaults en SFOS 19.0 para configuraciones nuevas con el fin de reducir el flapping de conexiones no TCP cuando los túneles IPsec suben o bajan. El cambio no se aplicó globalmente durante upgrades y migraciones. En SFOS 22 importa la salida actual del dispositivo, no un supuesto valor de fábrica.

En HA también debe tenerse en cuenta que Sophos Firewall no transfiere al peer las sesiones VPN y no TCP como las sesiones TCP reenviadas normales. Los dos ajustes conn-remove-* no sustituyen ni al diseño HA ni a una prueba de failover controlada.

Rendimiento IPsec y funciones de protección

El grupo ipsec-performance contiene cuatro funciones muy diferentes. El nombre puede inducir a realizar pruebas de tuning, aunque solo una de ellas define directamente el tamaño de una cola de trabajo.

Cambiar la workqueue solo ante un cuello de botella demostrado

ipsec-max-workqueue-items acepta valores de 1024 a 10240. La cola contiene trabajo para el procesamiento IPsec. Un valor mayor no garantiza más throughput ni soluciona Packet Loss, problemas de MTU, resultados débiles con un único stream o un enlace WAN saturado.

set vpn ipsec-performance ipsec-max-workqueue-items <1024-10240>

Un cambio solo tiene sentido cuando una prueba de carga reproducible, la utilización del sistema y los diagnósticos de Sophos señalan exactamente este cuello de botella. Antes se comprueban por separado MTU y MSS, latencia, Packet Loss, perfil de cifrado, IPsec Acceleration y streams paralelos. Si no mejora, se restaura el valor inicial registrado.

La ventana anti-replay es una función de seguridad

IPsec registra dentro de la ventana replay qué paquetes ya ha visto durante el descifrado. Así puede detectar y descartar paquetes repetidos. SFOS 22 acepta 0, 32, 64, 128, 256, 512, 1024, 2048 y 4096; el default documentado es 1024.

set vpn ipsec-performance anti-replay window-size <valor>

Una ventana mayor puede ser relevante cuando los paquetes se reordenan mucho en rutas paralelas. No es un interruptor general de rendimiento. El valor 0 elimina la protección anti-replay y no se recomienda como solución. Esta prueba solo corresponde a una ventana aislada, con indicación explícita de Sophos Support y rollback inmediato.

El umbral de cookies IKEv2 protege las SA medio abiertas

Según Sophos, la validación de cookies está siempre activa y solo existe para IKEv2. cookie_threshold no la enciende ni la apaga. Cuando el número de IKE SA medio abiertas simultáneas supera el umbral, el responder solicita una cookie al initiator. Así se protege el estado de establecimiento contra carga DoS. El default documentado es 30.

set vpn ipsec-performance cookie_threshold <numero>

Un valor inferior o superior solo se elige a partir de carga IKE real y diagnósticos de soporte. No corrige Child SAs ausentes, proposals incompatibles ni errores de autenticación. En la validación se observan conexiones IKEv2 nuevas, strongswan.log, carga de CPU y accesos simultáneos legítimos.

Usar la dirección resuelta del peer solo para el caso Charon documentado

use-resolved-ip-address está pensado para muchos túneles IPsec site-to-site con peers FQDN y resolución DNS lenta. Según Sophos, esta combinación concreta puede bloquear un thread de charon. Con enable, la firewall usa la dirección IP ya resuelta en lugar de iniciar el túnel repitiendo la resolución del FQDN remoto.

set vpn ipsec-performance use-resolved-ip-address enable
set vpn ipsec-performance use-resolved-ip-address disable

El FQDN debe haberse resuelto correctamente. El default documentado es Off. La opción no sustituye a un DNS funcional, TTL adecuados ni resolvers accesibles. Antes de activarla se correlacionan el tiempo de resolución, las respuestas A y AAAA actuales, el número de túneles y charon.log. Después de un cambio de DNS o provider se confirma que la firewall utiliza la nueva IP del peer en el tiempo esperado. Sin el caso Charon descrito, permanece desactivada.

Compatibilidad L2TP, MTU y PPTP

set vpn también contiene protocolos de autenticación para L2TP y PPTP, además de la MTU global de L2TP. Esto no convierte a PPTP en una opción adecuada para entornos nuevos. PPTP está obsoleto y no debería desplegarse de nuevo. L2TP Remote Access también sigue siendo una solución de compatibilidad controlada, no el estándar preferido para nuevos clientes gestionados.

Primero se lee la configuración actual con show vpn configuration. L2TP y PPTP ofrecen ANY, CHAP, MS_CHAPv2 y PAP:

set vpn l2tp authentication <ANY|CHAP|MS_CHAPv2|PAP>
set vpn pptp authentication <ANY|CHAP|MS_CHAPv2|PAP>

El valor no se elige solo por el nombre que parece más fuerte. Cliente, servidor de autenticación y método VPN configurado en Authentication > Services deben admitir el mismo protocolo. Con Active Directory, la combinación compatible puede diferir de una ruta RADIUS. ANY no mejora la seguridad, sino que amplía los métodos aceptados y requiere una decisión de riesgo consciente.

La MTU de L2TP puede configurarse entre 576 y 1460; el default documentado es 1410:

set vpn l2tp mtu <576-1460>

La MTU de L2TP no modifica una interfaz IPsec site-to-site route-based o policy-based. Solo se ajusta paso a paso ante un problema reproducible de fragmentación L2TP. Después deben seguir funcionando transferencias grandes y pequeñas, DNS, autenticación y reconexión.

Probar y revertir de forma controlada

En cada ventana de mantenimiento se cambia exactamente un valor global. Antes y después se utilizan los mismos túneles, flujo de prueba y transición WAN o HA. Para IPsec se registran estado del túnel, Child SA, contadores de bytes, strongswan.log, charon.log, CPU y Packet Loss. Para la limpieza de sesiones se incluyen VoIP, DNS y otros flujos UDP.

Un ping correcto no es una aceptación completa. Se comprueban al menos un flujo existente, una conexión nueva, ambas direcciones y un test negativo controlado. Después se vuelve a leer el estado objetivo con el comando show vpn ... correspondiente.

Si no aparece la mejora esperada o surgen nuevas interrupciones, se establece exactamente el valor anotado antes de la prueba. Luego se vuelven a comprobar túnel y tráfico. Sin estado inicial conocido, acceso de gestión independiente y síntoma defendible no se ejecuta ningún cambio set vpn.

FAQ

¿Debe configurarse ipsec-max-workqueue-items en 10240 para obtener más throughput VPN?

No. El máximo no es una Best Practice. Una cola mayor solo puede amortiguar la carga de otra forma y no corrige muchas causas habituales de throughput. Primero se miden latencia, Packet Loss, MTU/MSS, streams únicos y paralelos, CPU, perfil y Acceleration. La workqueue solo se cambia con un diagnóstico coincidente y rollback.

¿Puede desactivarse anti-replay si los paquetes llegan desordenados?

SFOS acepta una ventana 0, pero elimina la protección anti-replay. Primero se demuestran el reordenamiento, las rutas paralelas y la ventana necesaria. Desactivar la función no es un paso normal de troubleshooting y solo corresponde a una prueba de soporte aislada.

¿Ayuda use-resolved-ip-address en todos los túneles IPsec con FQDN?

No. Sophos limita la opción a muchos túneles site-to-site con resolución DNS lenta y un posible bloqueo del thread charon. El FQDN ya debe estar resuelto. Para un túnel individual estable o como sustituto de un DNS defectuoso, el interruptor permanece apagado.