Posts Tagged ‘log’

Problème VISTA : la connexion ne fonctionne pas, pas de message d’erreur

mardi, octobre 20th, 2009

Sous VISTA si le petit patch de la base de registre est mal appliqué (ou la machine n’est pas rebooté), il est possible que la connexion VPN échoue sans aucun message d’erreur.

Néanmoins dans les logs du serveur VPN nous aurons :

STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Dead Peer Detection (RFC 3706): not enabled because peer did not advertise it
transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
STATE_QUICK_R2: IPsec SA established {ESP=>0xd3e37be6 <0xb8baa9ac xfrm=AES_128-HMAC_SHA1 NATD=172.20.10.58:4500 DPD=none} received Delete SA(0x7e993ed9) payload: deleting IPSEC State #61676 received and ignored informational message

Un log de connexion réussi :

STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Dead Peer Detection (RFC 3706): not enabled because peer did not advertise it
transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
STATE_QUICK_R2: IPsec SA established {ESP=>0x1a850fb1 <0x72559a9e xfrm=AES_128-HMAC_SHA1 NATD=172.21.7.183:4500 DPD=none}

Problème linux : log de connexion

mercredi, avril 9th, 2008

Les logs liés à une connexion VPN se trouvent dans /var/log/auth.log, /var/log/syslog et /var/log/messages.
Au lancement de la connexion IPsec (on voit ici que la connexion est à travers du nat) vous devez avoir des logs similaires à ceux-ci dans /var/log/auth.log (ou /var/log/messages):
#49: initiating Main Mode
#49: ignoring unknown Vendor ID payload [4f456c4c4f5d5264574e5244]
#49: received Vendor ID payload [Dead Peer Detection]
#49: received Vendor ID payload [RFC 3947] method set to=110
#49: enabling possible NAT-traversal with method RFC 3947 (NAT-Traversal)
#49: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
#49: STATE_MAIN_I2: sent MI2, expecting MR2
#49: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): both are NATed
#49: I am sending my cert
#49: I am sending a certificate request
#49: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
#49: STATE_MAIN_I3: sent MI3, expecting MR3
#49: Main mode peer ID is ID_IPV4_ADDR: '194.57.91.251'
#49: no crl from issuer "C=FR, ST=Franche-Comte, L=Besancon, O=UFC, OU=CRI, CN=CA-vpn, E=vpn-master@univ-fcomte.fr" found (strict=no)
#49: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4
#49: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_RSA_SIG cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1536}
#50: initiating Quick Mode RSASIG+ENCRYPT+TUNNEL+UP {using isakmp#49}
#50: transition from state STATE_QUICK_I1 to state STATE_QUICK_I2
#50: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0x2e19c272 <0x37ba5dd5 xfrm=AES_0-HMAC_SHA1 NATD=194.57.91.251:4500 DPD=none}

Si vous n’avez pas de log de connexion IPsec, il faut vérifier votre fichier ipsec.conf, car il doit contenir des erreurs de syntaxe.

lors de la connexion (x)l2tp vous devriez avoir dans /var/log/syslog :
: pppd 2.4.4 started by root, uid 0
: Using interface ppp0
: Connect: ppp0 <--> /dev/pts/2
: Remote message: user2@lifc-edu connecte a lifc-edu^J
: PAP authentication succeeded
: replacing old default route to eth0 [192.168.1.254]
: local IP address 172.20.128.37
: remote IP address 192.168.255.201
: primary DNS address 194.57.91.200
: secondary DNS address 194.57.91.200

votre nouvelle adresse IP est précisée ici : : local IP address 172.20.128.37

Si vous n’avez pas de log (x)l2tp, vous pouvez lancer l2tpd en mode debug avec la commande suivante, en utilisateur root :
/etc/init.d/xl2tpd stop ou /etc/init.d/l2tpd stop
xl2tpd -D -c /etc/xl2tpd/xl2tpd.conf ou l2tpd -D -c /etc/l2tpd/l2tpd.conf
Ensuite effetcuez dans une autre fenêtre root le montage du lien PPP
echo "c user2" > /var/run/xl2tpd/l2tp-control ou echo "c user2" > /var/run/l2tp-control
Le résultat des logs dans la première fenêtre doit vous apporter de l’aide pour corriger votre problème.
Si cela persiste n’hésitez pas à contacter votre correspondant réseau ou vpn-master@univ-fcomte.fr