L’ENSMM par sa politique de sécurité qui consiste à autoriser qu’une ou deux adresses publique pour le NAT des machines en classe privée en son sein, ne permet donc qu’a un seul client Windows/Mac de se connecter sur le serveur VPN1 (194.57.91.250). Pour éviter ce problème (NAT), nous pourrions utiliser le lien direct (ENSMM-UFC) qui à été mis en place pour les besoins du laboratoire FEMTO-ST, mais l’ENSMM refuse de router les classes d’adresses de l’UFC par ce biais. De fait, le VPN ne fonctionne pas de manière efficace entre l’ENSMM et l’UFC
Problème de connexion depuis l’ENSMM
septembre 16th, 2010Windows Vista : erreur 769
septembre 9th, 2010Un cas particulier d’erreur windows Vista 769 survient si l’adresse IP entrée pour le serveur VPN comporte un caractère invisible ou qu’au lieu de l’adresse IP il soit indiqué le nom vpn1. De fait la connexion avec le serveur VPN ne s’établie jamais.
problèmes déconnexion sauvage
avril 23rd, 2010Nous nous sommes aperçu qu’après une déconnexion sauvage (câble débranché, mise en veille des périphériques, …), il devient quasi impossible de se reconnecter.
Nous travaillons sur une solution, veuillez nous excuser pour la gène occasionnée.
Problèmes NAT
avril 23rd, 2010Le vpn ne fonctionne derrière un NAT (même adresse ip de sortie) que pour la première personne connectée.
Problème Linux : Kernel 2.6.31
novembre 26th, 2009Le kernel 2.6.31 que l’on retrouve dans ubuntu 9.10 et suze 11.2 pose des problèmes avec le VPN.
Celui-ci semble se monter correctement, mais aucune communication n’est alors possible, puis au bout d’une minute ou deux la connexion tombe.
Si vous avez eu le temps de taper une commande ifconfig vous aurez alors pu voir la connexion ppp0 avec 100 000 000 d’octet émis et 0 en réception.
Le problème est dû au noyau linux 2.6.31 dans lequel nombre d’API ont changé et qui ne sont donc plus compatible avec les différents logiciels devant utilisé la pile IPSEC (cf net: remove COMPAT_NET_DEV_OPS ou il semble que deux ou trois choses se soit faites … trop vite).
Une recompilation du noyau sur la version 2.6.30 remet les choses en l’état, mais cette opération étant délicate, nous ne la conseillons pas.
Normalement la version d’openSWAN 2.6.24rc2 devrait prendre en compte la modification de l’API du noyau.
Confirmation de notre collègue Michel Devel : <<Après installation de Openswan Version 2.6.ikev2-200950.git-g80b1ff8a (2.6.24.rc3), l’accès VPN depuis opensuse 11.2 (kernel 2.6.31) fonctionne.>>
En attendant la sortie corrigée d’Openswan, vous pouvez toujours appliquer le script de Jean-Michel Carricand (https://vpn.univ-fcomte.fr/?p=97)
Problème windows : erreur d’authentification L2TP
novembre 23rd, 2009Si les logs du serveur VPN (/var/log/syslog) indique pour une connexion XP/VISTA/SEVEN l’erreur :
peer refused to authenticate: terminating link
sent [LCP TermReq id=0x3 "peer refused to authenticate"]
c’est qu’il faut vérifier en plus les logs du serveur RADIUS.
Si ceux-ci indique :
Info: rlm_perl: Entry xxxxx@xxxxx/194.57.91.250 not found in database (post_auth)
c’est que l’on a oublié de rentrer dans la base de données des ACL la règle autorisant la personne à se connecter sur le realm voulu.
windows VISTA : erreur 789 ou 835
octobre 21st, 2009cette 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
Problème VISTA : la connexion ne fonctionne pas, pas de message d’erreur
octobre 20th, 2009Sous 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 d’utilisation multiple d’un certificat
août 24th, 2009Attention lorsque vous avez plusieurs machines qui possèdent le même certificat.
L’utilisation du même certificat depuis deux machines distincts (même avec deux adresses IP distincts) ne sera pas possible. La deuxième connexion sera coupé toutes les 10 secondes environ par le serveur VPN.
Le système client ré-essayant de se connecter automatiquement, cela vous donnera une impression de marche partiel.
Linux/Windows : déconnexion de la liaison VPN
juillet 12th, 2009Dans certain cas, il y a perte de connexion VPN sans erreur visible dans les fichiers de logs.
Deux pistes :
– coupure temporaire du lien réseau (qui peut arriver avec le WIFI, ou plus rarement une panne de l’opérateur) ;
– surcharge importante du lien par un ordinateur tièrce (si votre portable est en VPN que votre machine de bureau sans VPN effectue un gros transfert de fichier en utilisant toute la bande passante).