[IPSec] Association phase 2 non pérenne



  • Bonjour,

    • Version pfSense 2.2.5 (nous sommes en production et un upgrade vers 2.3.4 est, pour l'instant, très compliqué)

    • Ce pfSense est utilisé en tant que router/firewall/VPN (OpenVPN "road warrior") en frontend d'accès à l'ensemble d'une infrastructure VMWare Dedicated Cloud OVH

    • Il nous apporte entière satisfaction ;-) (charge, fonctionnalités, etc.)

    Nous avons mis en place un tunnel IPSec entre cette infrastructure et l'infrastructure de notre société (Fortinet).

    
       Remote                                                             Local
    ------------------------------------------------------------------------------
    192.168.0.0/16   |                                               |
    172.30.0.0/16    |--- XXX.XXX.XXX.XXX   <==>   YYY.YYY.YYY.YYY --| 172.16.8.0/22
    10.0.0.0/8       |                                               | 172.16.12.0/24
    
    

    Le paramétrage général est le suivant (je n'ajoute pas le détail des phases 1/2 ici car ces éléments semblent être fonctionnels dans la mesure où le tunnel se monte et les phases 2 sont toutes UP initialement , mais je peux les ajouter le cas échéant) :

    Concernant les 3 premières phases 2 (Local 172.16.8.0/22 <=> Remote "*") , tout se passe bien, les phases "montent" au lancement du tunnel IPSec et restent active.

    Concernant les 3 autres (Local 172.16.12.0/24 <=> Remote "*"), nous sommes face à un dysfonctionnement que nous ne  comprenons pas :

    • Au démarrage du service IPSec, elles se montent correctement et les réseaux privés sont accessibles de part et d'autre

    • Après quelques heures de fonctionnement (il semblerait que cela corresponde à 8 heures soit la "lifetime" 28800 de la phase 1), les phases 2 vers/depuis Local "172.16.12.0/24" tombent et n'arrivent plus à remonter

    • Les 3 premières phases 2  (Local 172.16.8.0/22 => Remote "*") restent bien actives et fonctionnent toujours correctement

    • Les logs nous indiquent (XXX.XXX.XXX.XXX IP public phase 1 distante et YYY.YYY.YYY.YYY IP public phase 1 locale):

    
    May 30 13:58:45	charon: 12[NET] waiting for data on sockets
    May 30 13:58:45	charon: 05[NET] <con1000|1>received packet: from XXX.XXX.XXX.XXX[500] to YYY.YYY.YYY.YYY[500] (364 bytes)
    May 30 13:58:45	charon: 05[ENC] <con1000|1>parsed QUICK_MODE request 2714872162 [ HASH SA No KE ID ID ]
    May 30 13:58:45	charon: 05[CFG] <con1000|1>looking for a child config for 172.16.12.0/24|/0 === 192.168.0.0/16|/0
    May 30 13:58:45	charon: 05[IKE] <con1000|1>no matching CHILD_SA config found
    May 30 13:58:45	charon: 05[ENC] <con1000|1>generating INFORMATIONAL_V1 request 3030038507 [ HASH N(INVAL_ID) ]
    May 30 13:58:45	charon: 05[NET] <con1000|1>sending packet: from YYY.YYY.YYY.YYY[500] to XXX.XXX.XXX.XXX[500] (76 bytes)
    May 30 13:58:47	charon: 12[NET] received packet: from XXX.XXX.XXX.XXX[500] to YYY.YYY.YYY.YYY[500]</con1000|1></con1000|1></con1000|1></con1000|1></con1000|1></con1000|1> 
    
    • Les messages "looking for a child config for 172.16.12.0/24|/0 === 192.168.0.0/16|/0" et "no matching CHILD_SA config found" qui nous laisse perplexe car cette association existe bien dans nos phases 2

    • A priori la phase 1 reste bien active et fonctionnelle car l'accès au réseau Local "172.16.8.0/22" reste opérationnel de part et d'autre

    • Un redémarrage du service IPSec sur le pfSense ne permet pas de remonter ces phases 2

    • Par contre, un redémarrage du service IPSec distant sur le Fortinet(que nous ne maîtrisons pas) provoque bien une "réinitialisation" de toutes les phases 2 et rend donc toutes les phases 2 opérationnelles à nouveau (par rapport à son rôle d'Initiator peut-être ?)

    Nous disposons par ailleurs d'une instance pfSense de test sur laquelle nous avons mis en place une configuration IPSec similaire (ie. 1 phase 1 avec XXX.XXX.XXX.XXX identique à celle ci-dessus et adresse YYY.YYY.YYY.YYY différente mais sur la même infrastructure Dedicated Cloud OVH, et plusieurs phases 2 sur les mêmes réseaux privés distants mais avec réseaux locaux privés différents) et sur laquelle nous ne reproduisons pas ce problème…

    Il doit donc s'agir d'un problème de configuration de notre part, mais nous ne voyons pas à quel niveau.

    Nous avons essayé de passer le mode d'échange de clé en "IKEV2" mais sans succès...
    Cette fois toutes les phases 2 "tombent" après quelques heures de fonctionnement et les logs nous indiquent (pour toutes les phases 2, donc):

    
    May 29 08:09:34 fro-pfsense-01 charon: 03[NET] waiting for data on sockets
    May 29 08:09:34 fro-pfsense-01 charon: 13[NET] <con1|318>received packet: from XXX.XXX.XXX.XXX[500] to YYY.YYY.YYY.YYY[500] (396 bytes)
    May 29 08:09:34 fro-pfsense-01 charon: 13[ENC] <con1|318>parsed CREATE_CHILD_SA request 2100 [ SA No KE TSi TSr ]
    May 29 08:09:34 fro-pfsense-01 charon: 13[CFG] <con1|318>looking for a child config for 172.16.8.0/22|/0 === 172.30.0.0/16|/0 
    May 29 08:09:34 fro-pfsense-01 charon: 13[IKE] <con1|318>traffic selectors 172.16.8.0/22|/0 === 172.30.0.0/16|/0  inacceptable
    May 29 08:09:34 fro-pfsense-01 charon: 13[IKE] <con1|318>failed to establish CHILD_SA, keeping IKE_SA
    May 29 08:09:34 fro-pfsense-01 charon: 13[ENC] <con1|318>generating CREATE_CHILD_SA response 2100 [ N(TS_UNACCEPT) ]
    May 29 08:09:34 fro-pfsense-01 charon: 13[NET] <con1|318>sending packet: from YYY.YYY.YYY.YYY[500] to XXX.XXX.XXX.XXX[500] (76 bytes)</con1|318></con1|318></con1|318></con1|318></con1|318></con1|318></con1|318> 
    

    Les recherches effectuées sur ce forum (anglais ou Français) ne nous apporte pas de réponse évidente (dans la plupart des cas, il s'agit effectivement bien d'association n'existant pas en phase 2 ou d'adresses IP en non correspondance ou mal paramétrée, cf. par exemple https://doc.pfsense.org/index.php/Upgrade_Guide#Stricter_Phase_1_Identifier_Validation).

    Vous remerciant par avance pour toutes les pistes que nous pourrions exploiter…

    Bonne journée

    Patrick



  • Bonsoir,

    Si votre seule solution actuelle est de forcer la renégociation des clefs sur la phase 1,  augmentez la négociation a 24h et créez un script dans cron qui automatise la tache, vous maîtriserez alors l'erreur

    Je n'ai pas rencontré ce problème avec les versions antérieures de pfsense.

    Cordialement,

    Mathieu



  • Bonsoir,

    Merci pour votre réponse.

    A priori, les phases 1 semblent rester UP. Votre idée est intéressante, mais il semblerait qu'il faille l'appliquer sur l'appliance/boitier Fortinet distant (que nous ne maîtrisons pas), car côté pfSense, si nous redémarrons complètement le service IPSec (via le GUI), les phases 2 ne remontent pas (mêmes messages en log) :-(

    Nous sommes à cours d'idée, et allons tester une solution openVPN pour avancer sur ce sujet (nous avons déjà un tunnel openVPN "site to site" entre 2 infras, avec des frontaux pfSense, qui fonctionne très bien).

    Bonne soirée


Log in to reply