L’erreur 807 apparait lorsque la connexion à été interrompu brutalement et que l’on cherche à se reconnecter directement. Windows conserve des attributs de connexion qui ne sont plus valide et essaye de les rejouer, sans succès. Un reboot permet une reconnexion correcte.
Problème Windows : erreur 807
octobre 12th, 2011problème Shrew : Error 0x8004a029: Couldn’t install the network component
mars 15th, 2011Comme indiqué dans la FAQ de Shrew :
During install, I receive “Error 0x8004a029: Couldn’t install the network component”. ¶
Error 0x8004a029 means that the maximum number of filter devices for the system has been reached. Other similar software ( VPN clients, 3rd party firewalls, etc ) install filters. You can either attempt to remove other software that has installed a filter, or attempt to increase the following registry entry value to allow more filters to be installed.
Il faut donc supprimer un composant de surveillance/filtrage réseau…
1) lancer regedit
2) aller jusqu’a la clef HKEY_LOCAL_MACHINE/SYSTEM/Current/ControlSet/Control/Network
3) double cliquer sur la valeur nommée MaxNumFilters
4) Le MaxNumFilters est de base à 8. Il faut le passer à 14 et cliquer sur Ok
5) Si possible enlever les autres composants de filtrage pour éviter un nouvel engorgement…
(merci à Fabrice Mussy pour la solution complète)
solution pour “la déconnexion fatale” des clients Windows
novembre 26th, 2010L’équipe travail à l’intégration d’un nouveau client pour les Windows (XP/Vista/Seven/2000/2003/2008) qui tient en compte ce que le client natif de Windows ne fait pas : prendre en charge le DPD (dead peer detection).
Le client (shrew http://www.shrew.net/) gère DPD et donc permet en cas de déconnexion du client au serveur de reprendre en moins d’une minute la connexion perdue.
Nous sommes en phases de test du client sur les diverses plateformes.
Techniquement la connexion s’effectue en deux partie.
– le lancement du client IPSEC (shrew)
– le lancement d’une connexion PPTP pour l’authentification sur le realm souhaité. Cette partie est géré par Windows.
La solution est en phase de test
La documentation provisoire est installation_shrew-20101215
Windows Vista : erreur 810
octobre 18th, 2010Si vous importer le certificat dans le magasin Utilisateur/Personnel, vous obtiendrez l’erreur 810.
Pour corriger cela, vider le magasin (programme mmc à lancer) et ré-importer votre certificat dans le magasin Machine Local/Personnel.
Problème de connexion depuis l’ENSMM
septembre 16th, 2010L’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
Windows 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.