Utiliser en sécurité les paramètres VPN globaux de Sophos Firewall

La Device Console de Sophos Firewall propose sous set vpn des paramètres globaux pour le failover VPN, le traitement IPsec et les protocoles hérités L2TP et PPTP. Ils ne concernent pas seulement la connexion en cours d’analyse. Un test imprécis peut affecter d’autres tunnels, supprimer des sessions existantes ou affaiblir une fonction de protection.

Ce n’est pas une recette générale de performance : ne pas augmenter préventivement ipsec-max-workqueue-items ou la fenêtre anti-replay, ni activer use-resolved-ip-address. Sophos les décrit comme des paramètres avancés à utiliser pour un besoin réseau précis ou sur conseil de Sophos Support.

Pour un problème de tunnel ordinaire, commencer par le dépannage VPN IPsec. Il vérifie IKE, la Child SA, le routing, le NAT, les règles et le flux réel. Les paramètres globaux de cet article ne deviennent pertinents que si le symptôme correspond exactement à leur fonction.

Enregistrer l’état initial avant chaque modification

Les commandes s’exécutent sous 4. Device Console. Avant toute valeur, documenter la version et le build SFOS, l’heure, les tunnels concernés, le flux de test attendu et un accès d’administration indépendant. Interroger séparément les valeurs existantes :

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

show vpn ipsec-performance affiche notamment les valeurs de workqueue et de replay. show vpn configuration concerne la configuration L2TP et PPTP actuelle. Si une valeur n’apparaît pas dans le build installé, ne pas la déduire d’un default supposé. Avant de modifier un paramètre avancé global, intégrer au changement une sauvegarde de configuration et Sophos Support.

Le rollback utilise toujours la valeur réellement lue sur l’appliance. default n’est pas documenté comme retour universel pour ces commandes VPN et ne doit pas être utilisé par supposition.

Sessions lors des transitions de tunnel et de WAN

conn-remove-tunnel-up détermine si les connexions existantes sont supprimées lorsqu’un tunnel IPsec s’établit. Cela peut compter lorsqu’un flux a commencé par un autre chemin et reste attaché à ce mauvais chemin après la montée du tunnel. La suppression peut aussi interrompre des sessions productives. Depuis SFOS 19.0, les nouvelles configurations utilisent disable par défaut, tandis que les systèmes migrés peuvent conserver une ancienne valeur.

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

conn-remove-on-failover contrôle le nettoyage global au failover et au failback. all concerne toutes les connexions, alors que non-tcp limite le nettoyage au trafic non TCP comme UDP ou ICMP. La valeur appropriée n’est donc pas une simple décision VPN : VoIP, visioconférence, DNS et autres applications UDP doivent être observés dans la même fenêtre de test.

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

Sophos a modifié ces defaults dans SFOS 19.0 pour les nouvelles configurations afin de réduire le flapping des connexions non TCP lors de la montée ou de la chute des tunnels IPsec. Le changement n’a volontairement pas été appliqué globalement lors des upgrades et migrations. Sous SFOS 22, la sortie actuelle de l’appliance prime donc sur une valeur d’usine supposée.

En HA, Sophos Firewall ne transmet pas au peer les sessions VPN et non TCP comme les sessions TCP transférées ordinaires. Les deux paramètres conn-remove-* ne remplacent ni la conception HA ni un test de failover contrôlé.

Performance IPsec et fonctions de protection

Le groupe ipsec-performance réunit quatre fonctions très différentes. Son nom peut encourager des essais de tuning, même si une seule fonction définit directement la taille d’une file de travail.

Modifier la workqueue uniquement pour un goulot démontré

ipsec-max-workqueue-items accepte des valeurs de 1024 à 10240. La file contient le travail destiné au traitement IPsec. Une valeur supérieure ne garantit pas plus de débit et ne corrige ni Packet Loss, ni problème de MTU, ni résultat faible avec un seul stream, ni liaison WAN saturée.

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

Une modification n’a de sens que si un test de charge reproductible, l’utilisation du système et les diagnostics Sophos indiquent précisément ce goulot. Vérifier d’abord séparément MTU et MSS, latence, Packet Loss, profil de chiffrement, IPsec Acceleration et streams parallèles. Sans amélioration, restaurer la valeur initiale enregistrée.

La fenêtre anti-replay est une fonction de sécurité

Dans la fenêtre replay, IPsec mémorise les paquets déjà vus pendant le déchiffrement. Il peut ainsi détecter et rejeter les paquets répétés. SFOS 22 accepte 0, 32, 64, 128, 256, 512, 1024, 2048 et 4096; le default documenté est 1024.

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

Une fenêtre supérieure peut être utile si les paquets sont fortement réordonnés sur des chemins parallèles. Ce n’est pas un réglage général de débit. La valeur 0 supprime la protection anti-replay et n’est pas recommandée comme solution. Un tel test exige une fenêtre isolée, une consigne explicite de Sophos Support et un rollback immédiatement disponible.

Le seuil de cookies IKEv2 protège les SA semi-ouvertes

Selon Sophos, la validation des cookies est toujours active et n’existe que pour IKEv2. cookie_threshold ne l’active ni ne la désactive. Lorsque le nombre de IKE SA simultanément semi-ouvertes dépasse le seuil, le responder demande un cookie à l’initiator. L’état d’établissement est ainsi protégé contre une charge DoS. Le default documenté est 30.

set vpn ipsec-performance cookie_threshold <nombre>

Une valeur inférieure ou supérieure ne se choisit qu’à partir de la charge IKE réelle et des diagnostics du support. Elle ne corrige pas une Child SA absente, des proposals incompatibles ou un échec d’authentification. La validation observe les nouvelles connexions IKEv2, strongswan.log, la charge CPU et les connexions simultanées légitimes.

Utiliser l’adresse résolue du peer uniquement pour le cas Charon documenté

use-resolved-ip-address est destiné à de nombreux tunnels IPsec site-to-site avec peers FQDN et une résolution DNS lente. Selon Sophos, cette combinaison précise peut bloquer un thread charon. Avec enable, le pare-feu utilise l’adresse déjà résolue au lieu d’initier le tunnel avec une nouvelle résolution du FQDN distant.

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

Le FQDN doit déjà avoir été résolu correctement. Le default documenté est Off. L’option ne remplace donc ni un DNS fonctionnel, ni des TTL adaptés, ni des resolvers accessibles. Avant activation, corréler le temps de résolution, les réponses A et AAAA actuelles, le nombre de tunnels et charon.log. Après un changement de DNS ou de provider, confirmer que le pare-feu utilise la nouvelle adresse du peer dans le délai prévu. Sans le cas Charon décrit, laisser le paramètre désactivé.

Compatibilité L2TP, MTU et PPTP

set vpn contient aussi les protocoles d’authentification L2TP et PPTP ainsi que la MTU L2TP globale. Cela ne rend pas PPTP adapté à un nouvel environnement. PPTP est obsolète et ne doit plus être déployé. L2TP Remote Access reste aussi une solution de compatibilité contrôlée, pas la norme privilégiée pour de nouveaux clients administrés.

Lire d’abord la configuration actuelle avec show vpn configuration. L2TP et PPTP proposent ANY, CHAP, MS_CHAPv2 et PAP :

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

Ne pas choisir uniquement le nom qui semble le plus fort. Le client, le serveur d’authentification et la méthode VPN configurée sous Authentication > Services doivent prendre en charge le même protocole. Avec Active Directory, la combinaison compatible peut différer d’un chemin RADIUS. ANY n’améliore pas la sécurité, mais élargit les méthodes acceptées et exige une décision de risque explicite.

La MTU L2TP peut être réglée de 576 à 1460; le default documenté est 1410 :

set vpn l2tp mtu <576-1460>

La MTU L2TP ne modifie pas une interface IPsec site-to-site route-based ou policy-based. Elle n’est ajustée progressivement que pour un problème de fragmentation L2TP reproductible. Les transferts petits et grands, le DNS, l’authentification et la reconnexion doivent ensuite rester fonctionnels.

Tester et restaurer de manière contrôlée

Modifier exactement une valeur globale par fenêtre de maintenance. Utiliser les mêmes tunnels, le même flux et la même transition WAN ou HA avant et après le changement. Pour IPsec, enregistrer l’état du tunnel, la Child SA, les compteurs, strongswan.log, charon.log, le CPU et Packet Loss. Pour le nettoyage des sessions, inclure VoIP, DNS et d’autres flux UDP.

Un ping réussi n’est pas une validation complète. Contrôler au minimum un flux existant, une nouvelle connexion, les deux directions et un test négatif maîtrisé. Relire ensuite l’état cible avec la commande show vpn ... appropriée.

Si l’amélioration attendue n’apparaît pas ou si de nouvelles interruptions surviennent, réappliquer exactement la valeur relevée avant le test. Contrôler à nouveau tunnel et trafic. Sans état initial connu, accès d’administration indépendant et symptôme défendable, ne pas exécuter de changement set vpn.

FAQ