vpnc face à Check Point ou Nortel : pourquoi il se bloque

Le symptôme se lit facilement de travers : vpnc démarre, demande le mot de passe de groupe, puis reste à une étape de négociation jusqu’à signaler qu’aucune réponse ne vient de la cible. Rien dans la sortie ne mentionne le produit de la passerelle, et le compte fonctionne depuis un navigateur, donc la conclusion évidente est un mot de passe erroné ou un port bloqué. Dans la plupart de ces cas, la passerelle n’est pas du tout un pair IPsec, si bien que l’échange n’arrive jamais à tester les identifiants. Ce schéma mérite d’être testé avant de modifier quoi que ce soit d’autre dans le profil.

Identifiez le produit avant de modifier un autre champ du profil.

La panne ressemble à de mauvais identifiants

vpnc commence par envoyer IKE vers UDP 500 et, si la traversée NAT est proposée, vers UDP 4500. Une passerelle qui termine SSL au lieu d’IPsec ne répond ni à l’un ni à l’autre, si bien que le client réessaie et finit par abandonner avec une erreur générique. Si le même compte fonctionne via un portail navigateur qui charge une petite application d’assistance, c’est un indice fort que le tunnel repose sur SSL et que le client pose la mauvaise question.

Une tentative ratée ici ne dit rien du compte utilisateur, car aucun identifiant n’a jamais été présenté à la passerelle.

Vérifiez quel protocole la passerelle propose

Deux minutes de sondage séparent un pair IPsec d’un portail SSL. Lancez-les depuis le même réseau que celui que le client utilisera, et lisez quels ports répondent plutôt que ceux qui figurent dans un document. Conservez le résultat, car ces mêmes ports décident quel client le propriétaire de la passerelle devrait prendre en charge. Sondez depuis le réseau du client et non depuis un hôte à côté de la passerelle.

nc -zvu gw.example.com 500
nc -zvu gw.example.com 4500
nc -zvt gw.example.com 443
curl -sI https://gw.example.com/ | head -5
openssl s_client -connect gw.example.com:443 -servername gw.example.com </dev/null | head -20

Un 443 ouvert avec une redirection vers une page de connexion et un silence sur 500 et 4500 indique un SSL VPN. Des 500 et 4500 ouverts avec un certificat servi sur 443 suggèrent une passerelle IPsec qui fait aussi tourner un frontal web, ce qui est le cas pour lequel vpnc a été conçu.

Le SSL Network Extender de Check Point et le client Aventail de Nortel appartiennent tous deux à la seconde catégorie, et ni l’un ni l’autre n’accepte un secret de groupe IKEv1.

Ce que le profil de vpnc peut exprimer et ce qu’il ne peut pas

Sous le capot, vpnc exécute IKEv1 contre une clé pré-partagée de groupe, puis envoie les identifiants de l’utilisateur individuel via XAuth. Tout dans son fichier de configuration appartient à cet échange : passerelle, nom de groupe, secret de groupe, nom d’utilisateur et mot de passe utilisateur. Ces champs décrivent un seul protocole, et aucune combinaison de ceux-ci ne peut faire parler un autre protocole au client.

C’est pourquoi élargir la liste de chiffrements ou désactiver les vérifications de certificats ne corrige jamais ce type de panne. Ces changements affaiblissent une négociation que la passerelle n’écoute pas.

Choisir le client qui correspond à la passerelle

Pour une passerelle Check Point, utilisez le paquet SNX construit pour cette version de passerelle, que l’éditeur publie avec sa documentation d’accès distant. Les anciennes compilations SNX échouent souvent sur les distributions actuelles parce qu’elles attendent des bibliothèques 32-bit qui ne sont plus installées, et rapiécer un paquet abandonné est généralement pire que d’exécuter le client pris en charge sur une plateforme prise en charge.

Les clients Aventail ont perdu leur support depuis longtemps. Là où une telle passerelle est encore en service, les choix réalistes sont le portail navigateur si l’organisation l’active, ou le client pris en charge de l’éditeur sur un système d’exploitation pris en charge.

Demandez au propriétaire de la passerelle le produit et la version, le client qu’il prend en charge sous Linux, et s’il existe du tout un profil IPsec. S’il en existe un, demandez l’identifiant de groupe et le secret de groupe comme deux éléments distincts, car ce ne sont pas le mot de passe utilisateur et une paire intervertie est l’autre cause fréquente d’un tunnel raté. Quand une connexion finit par réussir, notez quel protocole a été négocié afin que la personne suivante parte d’un fait au lieu de répéter la même supposition.