Qu'est-ce qu'une passerelle de couche application (ALG) ?

Une passerelle de couche applicative (ALG), également appelée « passerelle de niveau applicatif », est un composant de sécurité qui inspecte les protocoles intégrant des adresses de connexion au sein de leur propre charge utile – FTP, SIP, PPTP, TFTP et IKE ESP – et ouvre de manière dynamique des « pinholes » temporaires dans le pare-feu afin que ces protocoles continuent de fonctionner au-delà des barrières NAT et des pare-feu.

Points clés à retenir

• ALG analyse les protocoles qui intègrent des adresses dans leur propre charge utile.
• Il ouvre des ouvertures temporaires dans le pare-feu au lieu de rediriger des ports de manière statique.
• Les protocoles pris en charge sont les suivants : FTP, SIP, PPTP, TFTP et IKE ESP.
• La fonction IKE ESP ALG est désactivée par défaut à partir de la version 22.1.4 de VOS.
• Versa configure les politiques ALG à la fois dans Concerto et dans Director.

Sur cette page : Pourquoi est-ce important ? · Comment ça marche · Types · ALG & Versa · FAQ

Pourquoi l'ALG est-elle importante ?

Les pare-feu NAT classiques et les pare-feu avec suivi d'état se contentent de réécrire les en-têtes des paquets, c'est-à-dire les adresses et les ports au niveau des couches IP et TCP/UDP. Certains protocoles dérogent à cette règle : le protocole FTP négocie une deuxième connexion de données en inscrivant une adresse et un port dans la charge utile de sa session de contrôle, et le protocole SIP procède de la même manière pour établir un flux vocal ou vidéo. Un pare-feu ou un dispositif CGNAT qui inspecte uniquement les en-têtes ne voit jamais ces valeurs intégrées ; il ne peut donc pas déterminer quelle connexion entrante autoriser, et la session est bloquée.

ALG comble cette lacune sans percer de trous statiques dans le pare-feu ni désactiver complètement le NAT. Il analyse la charge utile pour y trouver l'adresse intégrée, la réécrit afin qu'elle corresponde à l'adresse traduite de l'autre côté, puis ouvre un « pinhole » temporaire limité à cette seule connexion – ce qui permet aux transferts FTP, aux appels SIP et aux tunnels VPN de continuer à fonctionner à travers le NAT tandis que le pare-feu reste fermé à tout le reste.

Qu'est-ce que l'ALG ?

L'ALG résout le problème des adresses intégrées de deux manières : soit l'application identifie une combinaison adresse-port que le pare-feu doit autoriser en entrée, soit l'ALG surveille le trafic de contrôle et ouvre dynamiquement le mappage de port correspondant. Les appareils VOS utilisent la deuxième approche.

Prenons le protocole FTP en mode actif comme exemple type. Le FTP utilise deux sessions : une session de contrôle sur le port 21, qui répertorie les répertoires et envoie des commandes, et une session de données distincte, qui transfère le fichier. Un client situé derrière un NAT envoie au serveur une adresse interne dans la charge utile de contrôle – une adresse vers laquelle le serveur ne peut pas acheminer le trafic, et pour laquelle le pare-feu n’a jamais été configuré pour attendre une connexion. L’ALG écoute sur le port 21, surveille le paquet qui initie la session de données, remplace l’adresse intégrée par l’adresse NAT externe, puis crée une règle de pare-feu temporaire autorisant la connexion. Une fois la session de données terminée, le « pinhole » se referme.

Types d'ALG

L'ALG est implémenté par protocole, car chacun intègre les informations de connexion différemment. L'ALG FTP réécrit l'adresse dans la session de contrôle afin que la connexion de données du serveur parvienne au client malgré le NAT. L'ALG SIP analyse les champs SDP dans la signalisation SIP pour ouvrir les ports multimédia (RTP) utilisés par un appel. L’ALG PPTP suit le tunnel GRE établi par un VPN utilisant le protocole PPTP (Point-to-Point Tunneling Protocol) parallèlement à son canal de contrôle TCP. L’ALG TFTP gère les transferts sans connexion du protocole Trivial FTP, invisibles pour un pare-feu analysant uniquement les en-têtes. L’ALG IKE ESP prend en charge la négociation IPsec qui passe du canal UDP d’IKE à ESP pour le tunnel chiffré.

ALG & Versa

Sur les appareils VOS d’ Versa , les protocoles ALG sont activés par défaut pour FTP, PPTP, SIP et TFTP ; le protocole IKE ESP était également activé jusqu’à la version 22.1.4 de VOS (version de service du 23 septembre 2025), après quoi il est désactivé par défaut et nécessite une vsm-configs modifier dans /opt/versa/etc/vsboot.conf ainsi qu'un redémarrage du service pour le réactiver.

Dans Concerto, les administrateurs créent une politique ALG à partir du workflow du modèle principal SD-WAN, ou séparément sous « Serveurs et paramètres > Politiques de passerelle de couche application » – voir « Configurer la passerelle de couche application » pour les versions actuelles et « Configurer la passerelle de couche application (ALG) » pour les versions 12.1.1 à 12.2.2. Dans Director, l’équivalent se trouve dans le menu « Autres > ALG » d’une organisation – voir « Configurer l’ALG ». Dans les deux cas, la configuration est associée au profil maître d’un périphérique.

Questions fréquentes

Quelle est la différence entre l'ALG et le NAT ?

Le NAT traduit les adresses IP et les ports figurant dans l'en-tête d'un paquet. L'ALG va plus loin : il inspecte la charge utile des protocoles qui intègrent leurs propres informations d'adresse et de port, et ouvre les « pinholes » temporaires que le NAT seul ne peut pas créer pour ces données intégrées.

Quels protocoles ALG prend-il en charge sur les appareils VOS d'Versa ?

FTP, SIP, PPTP, TFTP et IKE ESP. Chacun de ces protocoles est implémenté sous la forme d'une instance ALG distincte, ce qui permet aux administrateurs de les activer ou de les désactiver individuellement et d'y intégrer des services définis par l'utilisateur pour chaque protocole, plutôt que d'activer ou de désactiver l'inspection de la couche application pour l'ensemble du dispositif en une seule fois.

Pourquoi l'algorithme IKE ESP est-il désormais désactivé par défaut ?

À partir de la version 22.1.4 de VOS (version de service datée du 23 septembre 2025), l'ALG IKE ESP est désactivé par défaut et ne peut pas être réactivé via l'interface utilisateur. Pour le réactiver, il faut modifier le fichier vsm-configs strophe dans /opt/versa/etc/vsboot.conf pour définir enable_ike_alg=true, puis en redémarrant les services à l'aide de la commande vsh restart Commande CLI.

ALG est-il compatible avec les pare-feu, le NAT, ou les deux ?

Les deux. L'ALG optimise spécifiquement le fonctionnement conjoint du pare-feu et du NAT de niveau opérateur (CGNAT) : c'est le mécanisme qui permet aux protocoles nécessitant des connexions négociées dynamiquement de continuer à fonctionner lorsqu'un appareil se trouve à la fois derrière une frontière NAT et un pare-feu à état.

Comment configurer une politique ALG sur un périphérique Versa ?

Dans Concerto, la configuration s'effectue via le workflow du modèle principal SD-WAN ou dans la section « Serveurs et paramètres », puis est appliquée via des autorisations et un objet de stratégie réutilisable. Dans Director, elle est configurée par organisation sous « Autres > ALG » et associée au profil d'un appareil.

En savoir plus sur ALG

Si vous souhaitez en savoir plus, voici des sources auxquelles nous faisons confiance.

Termes associés

Si vous vous intéressez à l'ALG, voici quelques liens qui pourraient vous intéresser.