Provya

Sécurité et téléphonie

Articles & Tutoriaux  -  Liens & Actualités

[pfSense] Comprendre et analyser les logs de son VPN IPsec

icon 10/03/2020

Savoir lire les logs de pfSense concernant IPsec peut être difficile.
Nous donnons dans cet article les clefs pour comprendre les logs IPsec et identifier les erreurs de configuration associées.

Après notre article sur comment configurer un VPN IPsec sous pfSense, notre article sur les causes de défaillances généralement rencontrées sur un VPN IPsec et leurs solutions les plus probables, nous abordons dans cet article la gestion des logs d'IPsec sous pfSense et la signification des messages pouvant être rencontrés dans ces fichiers de journalisation.



Configurer les logs IPsec

Les logs pour les VPN IPsec peuvent être configurés pour apporter des informations utiles pour le debogage. Pour effectuer cette configuration, se rendre dans le menu VPN > IPsec, puis onglet Advanced :

menu VPN > IPsec > Advanced - pfSense - Provya


Au sein de la rubrique "IPsec Logging Controls", configurer les options avec les valeurs suivantes :

  • IKE SA : Diag
  • IKE Child SA : Diag
  • Configuration Backend : Diag
  • Autres options : Control

Exemple de résultat obtenu :

Configuration des logs pour debug VPN IPsec sous pfSense - Provya


Il est à noter que modifier ces options ne coupera pas le VPN IPsec.



Interpréter les logs IPsec liés à la phase 1

Les logs des VPN IPsec sont accessibles depuis le menu Status > System Logs, onglet IPsec :

Menu Status > System Logs > IPsec - pfSense - Provya


Nous allons parcourir les messages que l'on peut rencontrer le plus couramment dans les logs.

La bonne manière de procéder, pour analyser les logs, consiste à rechercher les expressions clés indiquant quelles étapes fonctionnent ou, au contraire, échouent. Cela permet d'orienter très pécisément le diagnostique.

Par exemple, si l'on voit dans les logs "IKE_SA ... established", cela signifie que la phase 1 s'est déroulée avec succès et qu'une SA (Security Association) a été négociée. Ce qui signifie que les deux firewall établissant le tunnel IPsec arrivent à échanger de manière sécurisée.

Si l'on voit "CHILD_SA ... established", alors cela signifie qu'une phase 2 s'est déroulée avec succès également. Le tunnel doit être UP (en tout cas, pour au moins l'une des phases 2 ; dit autrement, pour au moins un sous-réseau local et un sous-réseau distant).



Connexions réussies

Lorsqu'un tunnel est correctement monté, les deux firewall doivent disposer dans leurs logs respectifs d'informations indiquant qu'un IKE SA et un Child SA ont été montés avec succès.

Quand il y a plusieurs phases 2, on doit visualiser un "CHILD_SA ... established" pour chacune d'entre elles.

Exemple de log d'un tunnel monté avec succès :

Logs IPsec tunnel monté pfSense - Provya


On voit sur cette capture d'écran que la phase 1 a été négociée avec succès (IKE_SA con2000[11] established) entre le firewall possédant l'adresse IP 192.0.2.90 et celui possédant l'adresse IP 192.0.2.74).

Puis, on voit qu'une phase 2 a été négociée avec succès (CHILD_SA con2000{2} established) permettant aux sous-réseaux 192.168.48.0/24 d'un côté et 10.42.42.0/24 de l'autre d'échanger entre eux.



Connexions échouées

Les exemples suivants montrent plusieurs cas de connexions IPsec échouées.

Un point important à avoir en tête est que dans la plupart des cas, le firewall initiant la connexion IPsec (initiateur) aura peu d'informations pertinentes dans ses logs (on ne saura pas précisément la raison de l'échec de la connexion) ; tandis que le firewall répondant à la demande de connexion IPsec (répondant) aura des informations beaucoup plus précises et détaillées. C'est normal. Il s'agit là d'un élément de sécurité : il serait en effet peu sûr de fournir à un attaquant potentiel trop d'informations sur la configuration du VPN.



Phase 1 - Écart de configuration Main / Aggressive

Dans cet exemple, l'initiateur est configuré en mode "Aggressive", tandis que le répondant est configuré en mode "Main".

Extrait des logs pour l'initiateur :

Échec négociation phase 1 IPsec pfSense - Provya


On lit bien dans les logs que la négociation de la phase 1 se fait en mode "Aggressive" et que l'authentification a échoué (AUTHENTICATION FAILED). Mais l'on ne connaît pas la raison de cet échec.

Extrait des logs pour le répondant :

Échec négociation phase 1 côté répondant IPsec pfSense - Provya


On lit dans les logs que la négociation de la phase 1 a échoué et que la raison de cet échec est que le mode "Aggressive" n'est pas autorisé. Les logs sont bien plus explicites.



Phase 1 - Erreur d'identifiant

Lorsque l'identifiant ne correspond pas (pour rappel, l'identifiant est généralement configuré pour être l'adresse IP publique du firewall), l'initiateur montre seulement que l'authentification a échoué. Le répondant précise la raison de cet échec.

Extrait des logs pour l'initiateur :

Échec identifiant phase 1 côté initiateur IPsec pfSense - Provya


On peut voir que l'erreur retournée est la même que dans le cas précédent : il s'agit d'une erreur d'authentification standard.

Extrait des logs pour le répondant :

Échec identifiant phase 1 côté répondant IPsec pfSense - Provya


Les logs sont beaucoup plus explicites : "no peer config found" ; l'identifiant correspondant à la requête n'a pas été trouvé.



Phase 1 - Erreur sur la Pre-Shared Key

Une erreur sur la PSK peut être difficile à diagnostiquer. En effet, on ne trouvera pas de message explicite dans les logs indiquant qu'il y a une erreur sur la Pre-Shared Key.

Les logs, aussi bien côté initiateur que répondant, ressembleront à ceci :

Erreur PSK sur VPN IPsec phase 1 pfSense - Provya


Si vous voyez ces messages apparaître dans vos logs IPsec, un conseil : vérifiez la valeur de votre Pre-Shared Key sur chaque firewall établissant le VPN IPsec.



Phase 1 - Écart sur le choix de l'algorithme de chiffrement ou de hachage

Extrait des logs pour l'initiateur :

Erreur chiffrement sur VPN IPsec phase 1 côté initiateur pfSense - Provya



Extrait des logs pour le répondant :

Erreur chiffrement sur VPN IPsec phase 1 côté répondant pfSense - Provya


Les messages sont très explicites et indiquent le problème exact. Ici, l'initiateur était configuré avec de l'AES-128 et le répondant avec de l'AES-256.

Il est à noter que la portion de message "MODP" correspond au groupe Diffie-Hellman (DH group). Ici, on voit que les deux firewall ont bien la même configuration de groupe Diffie-Hellman "MODP_1024".
S'il y avait eu un écart, nous aurions eu deux valeurs différentes, comme par exemple MODP_1024 d'un côté et MODP_8192 de l'autre.

Enfin, la portion "HMAC" correspond à l'algorithme de hachage. Ici, la valeur est HMAC_SHA1_96. Encore une fois, s'il y a un écart entre les deux, il faut alors corriger.



Interpréter les logs IPsec liés à la phase 2

Phase 2 - Erreur sur la configuration des sous-réseaux

Dans l'exemple ci-dessous, la phase 2 du firewall initiateur est configurée avec le sous-réseau 10.3.0.0/24 vers le 10.5.0.0/24. Tandis que le firewall répondant est configuré avec 10.5.1.0/24 pour son côté.

Extrait des logs pour l'initiateur :

Erreur log config VPN IPsec phase 2 côté initiateur pfSense - Provya


Extrait des logs pour le répondant :

Erreur log config VPN IPsec phase 2 côté répondant pfSense - Provya


Dans les logs du répondant, on peut visualiser les sous-réseaux présents dans la négociation de la phase 2 (ligne "looking for a child config for ...") et les sous-réseaux présents dans sa configuration locale (lignes "proposing traffic selectors for ...").

En comparant les deux, une erreur peut être détectée.
Enfin, la mention "no matching CHILD_SA config found" sera toujours présente dans les logs lorsqu'il y aura une erreur de configuration de ce type. Ce message signifie que pfSense n'a pas pu trouver de phase 2 correspondant à la requête du firewall initiateur.



Phase 2 - Écart sur le choix de l'algorithme de chiffrement ou de hachage

Extrait des logs pour l'initiateur :

Erreur chiffrement sur VPN IPsec phase 2 côté initiateur pfSense - Provya


Extrait des logs pour le répondant :

Erreur chiffrement sur VPN IPsec phase 2 côté répondant pfSense - Provya


Dans ce cas, l'initiateur reçoit un message indiquant que le répondant n'a pas pu trouver de proposition correspondant à la demande (ligne "received NO_PROPOSAL_CHOSEN").
Côté répondant, les logs sont plus détaillés et précisent la proposition reçue (ligne received proposals) et la proposition configurée localement (ligne configured proposals).

Dans l'exemple ci-dessus, sur les extraits de logs, on voit que c'est l'algorithme de chiffrement qui est différent (AES_CBC_128 dans un cas et AES_CBC_256 dans l'autre).

La portion "HMAC" correspond à l'algorithme de hachage. Ici, la valeur est HMAC_SHA1_96. Encore une fois, s'il y a un écart entre les deux, il faut alors corriger.


Voilà ! Nous avons fait le tour des messages de logs les plus courants pour les VPN IPsec sous pfSense.



Pour aller plus loin

[pfSense] Configurer un VPN IPsec site à site
[pfSense] Les pannes courantes et leurs solutions sur un VPN IPsec
[pfSense] Monter un accès OpenVPN site-à-site
[pfSense] Troubleshooting / Dépannage de ses règles de filtrage


Vous avez aimé cet article ? Vous cherchez du matériel ou un support professionnel ? Alors contactez-nous.


Découvrez nos firewall SSD pour pfSense, assemblés en France, compatibles AES-NI


           

store.provya.fr

icon Tags de l'article :

Aucun commentaire

icon Flux RSS des commentaires de cet article