cette erreur (789, 835) est dû au fait que l’on mette “vpn.univ-fcomte.fr” à la place de l’IP du serveur VPN : 194.57.91.250 (sur besançon).
La correction de la configuration fait rentrer dans l’ordre la connexion VPN.
sur le serveur VPN, les logs indiquent :
packet from 172.21.7.86:500: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000006]
received Vendor ID payload [RFC 3947] method set to=110
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 110
ignoring Vendor ID payload [FRAGMENTATION]
ignoring unknown Vendor ID payload [fb1de3cdf341b7ea16b7e5be0855f120]
ignoring Vendor ID payload [Vid-Initial-Contact]
ignoring unknown Vendor ID payload [e3a5966a76379fe707228231e5ce8652]
responding to Main Mode from unknown peer 172.21.7.86
only OAKLEY_GROUP_MODP1024 and OAKLEY_GROUP_MODP1536 supported. Attribute OAKLEY_GROUP_DESCRIPTION
only OAKLEY_GROUP_MODP1024 and OAKLEY_GROUP_MODP1536 supported. Attribute OAKLEY_GROUP_DESCRIPTION
transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
STATE_MAIN_R1: sent MR1, expecting MI2
J’ai aussi une erreur 789 sur Vista (dans une machine virtuelle VMWare)
En charchant sur internet. J’ai trouvé que :
“Si le client VPN se trouve derrière un périphérique réseau effectuant une traduction d’adresses réseau (NAT, Network Address Translation), la session L2TP échoue, car ceci endommage les paquets ESP (Encapsulating Security Payload) IPSec cryptés. Si le client VPN se trouve sur le même ordinateur que le Partage de connexion Internet de Windows/Traducteur d’adresses réseau, le client peut probablement établir une session L2TP, car NAT n’effectue pas de traduction d’adresses IP ou de port sur les paquets provenant de son propre noeud. ”
=> existe-t-il un espoir de se connecter quand même ?
aucun soucis : le NAT-T est bien pris en compte, c’est même le moyen privilégié de connexion.
L’erreur vu est dû à un autre problème.