Ces logs ont été récoltés avec un appliance Symantec VPN/Firewall 100.

Dans le cas ou un des équipements IPSEC se trouve derrière un Routeur NAT, celui-ci ne disposera pas d’une adresse WAN.

Par défaut, le protocole IPSEC (authentification IKE) utilisera un identifiant (ID TYPE) de type IP, avec pour valeur l’adresse qu’il suppose être l’adresse WAN. En faite il utilisera une adresse privé (dans notre cas 192.168.1.107). Lorsque l’équipement distant recevra la requête avec une adresse IP public (celle du NAT), et qu’il appliquera la politique par défaut (contrôle de l’ID sur l’adresse WAN), celui ci la compareras à l’adresse privée enfaite de notre routeur :

[04/27/2010 06:00:08.81] ike_midgard - Initiating IKE Main Mode

[04/27/2010 06:00:08.81] ike_midgard - STATE_MAIN_I1: initiate

[04/27/2010 06:00:09.51] ike_midgard - STATE_MAIN_I2: from STATE_MAIN_I1; sent MI2, expecting MR2

[04/27/2010 06:00:09.51] ike_midgard - ERR:discarding duplicate packet; already STATE_MAIN_I2

[04/27/2010 06:00:10.51] ike_midgard - STATE_MAIN_I3: from STATE_MAIN_I2; sent MI3, expecting MR3

[04/27/2010 06:00:10.51] ike_midgard - ERR:discarding duplicate packet; already STATE_MAIN_I3

[04/27/2010 06:00:10.66] ike_midgard - ERR: no suitable connection for peer '192.168.1.107'

[04/27/2010 06:00:10.66] ike_midgard - STATE_MAIN_I3: INVALID_ID_INFORMATION

[04/27/2010 06:00:10.66] ike_midgard - state transition function for STATE_MAIN_I3 failed: INVALID_ID_INFORMATION

[04/27/2010 06:00:10.66] ike_midgard - Sending ISAKMP OAK INFO (Notification IKE SA)

Ce problème constaté avec les logs d’une équipement DLINK DFL-210 :

ipsec_sa_negotiation_completed ipsec_sa_enabled

sa=Responder info="tunnel" local_peer="79.93.4.92 ID 192.168.1.107" remote_peer="213.245.40.63 ID 213.245.40.63" spi_in="ESP 6c5370ca" spi_out="ESP dd6f2a52"

Résolution : sur l’équipement placé derrière le NAT, configurer l’identifiant manuellement, avec pour type : IP; et pour valeur l’adresse WAN (celle du NAT). Attention si votre passerelle ne dispose pas d’une adresse IP statique. Pour plus de simplicité, certains équipements proposent de ne pas comparer des IP mais d’autres type (nom de domaine, adresse @mail, nom unique dn…). Attention, les deux équipements devront attendre le même type.

Exemple ou l’information attendu et l’information envoyée ne sont pas de même type :

[04/27/2010 06:58:46.91] ike_midgard - STATE_MAIN_I1: initiate

[04/27/2010 06:58:47.56] ike_midgard - STATE_MAIN_I2: from STATE_MAIN_I1; sent MI2, expecting MR2

[04/27/2010 06:58:47.56] ike_midgard - ERR:discarding duplicate packet; already STATE_MAIN_I2

[04/27/2010 06:58:48.51] ike_midgard - STATE_MAIN_I3: from STATE_MAIN_I2; sent MI3, expecting MR3

[04/27/2010 06:58:48.51] ike_midgard - ERR:discarding duplicate packet; already STATE_MAIN_I3

[04/27/2010 06:58:48.76] ike_midgard - ERR: no suitable connection for peer '@ใP'

[04/27/2010 06:58:48.76] ike_midgard - STATE_MAIN_I3: INVALID_ID_INFORMATION

[04/27/2010 06:58:48.76] ike_midgard - state transition function for STATE_MAIN_I3 failed: INVALID_ID_INFORMATION

[04/27/2010 06:58:48.76] ike_midgard - Sending ISAKMP OAK INFO (Notification IKE SA)

[04/27/2010 06:58:48.76] ike_midgard - Terminating connection

Exemple de logs lorsque la clé n’est pas identique sur les configurations des deux équipements :

[04/27/2010 09:28:58.63] midgard - Initiating IKE Main Mode

[04/27/2010 09:28:58.63] midgard - STATE_MAIN_I1: initiate

[04/27/2010 09:28:59.23] midgard - STATE_MAIN_I2: from STATE_MAIN_I1; sent MI2, expecting MR2

[04/27/2010 09:28:59.23] midgard - ERR:discarding duplicate packet; already STATE_MAIN_I2

[04/27/2010 09:29:00.38] midgard - STATE_MAIN_I3: from STATE_MAIN_I2; sent MI3, expecting MR3

[04/27/2010 09:29:00.38] midgard - ERR:discarding duplicate packet; already STATE_MAIN_I3

[04/27/2010 09:29:00.43] midgard - Receive ISAKMP OAK INFO (INVALID_PAYLOAD_TYPE)

[04/27/2010 09:29:00.43] midgard - Terminating connection