vpnc - il continue de se déconnecter après 24 minutes

VPNC pour une raison quelconque continue de me déconnecter après un certain temps. J'ai essayé de le chronométrer pour voir combien de temps cela prend et cela semble être à chaque fois après 24 minutes.

Après avoir été déconnecté, je n'ai pas de connexion Internet car mon /etc/resolv.conf est toujours le même qu'il devrait l'être lors de la connexion à vpnc. Si j'essaye de vpnc-déconnecter, il ne dit que "aucun vpnc trouvé en cours d'exécution". Je dois prendre eth0 dow et plus, puis modifier manuellement le fichier /etc/resolv.conf pour obtenir une connexion réseau appropriée.

Mes paramètres sont les suivants:

IPSec gateway xx.xx.xx.xx
IPSec ID anonymized
IPSec secret anonymized
#IKE Authmode hybrid
Xauth username myUsername
DPD idle timeout (our side) 0

J'ai également essayé d'avoir un ping en cours d'exécution en continu. J'ai aussi des streams et de la musique en continu, mais ça me déconnecte toujours.

Cela fonctionne bien sans déconnexion sur Windows.

ÉDITER. Plus d'informations: J'ai ajouté un journal de mon / var / log / syslog de ce qui se passe lorsque je suis déconnecté:

Je me connecte d'abord:

 Jul 24 14:03:09 cad-unix NetworkManager[1086]:    SCPlugin-Ifupdown: devices added 
 path: /sys/devices/virtual/net/tun0, iface: tun0)
 Jul 24 14:03:09 cad-unix NetworkManager[1086]:    SCPlugin-Ifupdown: device added 
 (path: /sys/devices/virtual/net/tun0, iface: tun0): no ifupdown configuration found.

Ensuite, je suis déconnecté après 24 minutes:

 Jul 24 14:27:29 cad-unix avahi-daemon[1089]: Withdrawing workstation service for tun0.
 Jul 24 14:27:29 cad-unix NetworkManager[1086]:    SCPlugin-Ifupdown: devices removed 
 (path: /sys/devices/virtual/net/tun0, iface: tun0)

Edit : peaufiné un peu la question pour une meilleure lecture. Précisant également maintenant que le problème se produit à 24 minutes à chaque fois.

Edit : Version Im en cours d'exécution: vpnc version 0.5.3

Edit : Après avoir compilé la version 0.5.1, je reçois maintenant une entrée supplémentaire dans le fichier journal: vpnc [16364]: connexion interrompue par l'homologue

Dernière modification, je suppose : je suis désespéré. Ouvert à toute suggestion. Même passer à une autre distribution linux est une option si c'est Ubuntu qui est le problème.

Il existe un rapport de bogue qui résout ce problème, datant du 28/10/2010, mais malheureusement toujours non résolu. Il semble que le temps de déconnexion soit quelque peu individuel, bien que les temps signalés soient toujours supérieurs à 24 minutes.

L'article pointe vers un correctif décrit ici , qui nécessite la recompilation de vpnc.

Si votre problème est lié à la recomposition, alors le problème de recomposition de l'article avec 0.5.3 affirme que le bogue est nouveau dans la version 0.5.3 et n'existe pas dans la version 0.5.1.

[ÉDITER}

Il semble que le retour à 0.5.1 n'a pas fonctionné pour vous. Il semble également que les déconnexions vpnc soient communes à de nombreuses distributions Linux.

J'ai trouvé la résolution d'un problème de déconnexion de vpnc au-dessus de la version 0.5.x , ce qui suggère que peut-être il faut revenir même à 0.4.x. Dans tous les cas, l'article suggère un correctif qui ne se rapporte probablement pas à votre cas, mais vous pouvez essayer:

Après tout, nous devons également désactiver DPD du côté client (vpnc), ce que nous pouvons réaliser de 2 manières:

• ajouter le commutateur de ligne de commande "--dpd-idle 0" lors de l'appel de "vpnc"
• mieux encore d'ajouter cette ligne au fichier de configuration: "Délai d'inactivité DPD (de notre côté) 0"

Plus d'informations: man vpnc

Il existe des informations similaires provenant de la prise en charge de RedHat: bogue 484114 - déconnexion VPN toutes les 5 minutes .

Vous pouvez essayer d'aller à vpnc 0.4.x, mais je commence à me demander si le problème est de votre côté ou avec un réglage du serveur vpn: 24 minutes est trop précis.

Essayez de changer le mode de traversée NAT en cisco-udp, qui l'a résolu pour moi

NAT Traversal Mode cisco-udp

Ma configuration complète ressemble à ceci

IPSec gateway VPNHOSTIP
IPSec ID SAMPLESHAREDUSER
IPSec secret SAMPLESHAREDKEY
Xauth username SAMPLEUSER
Xauth password SAMPLEUSERPASS
IKE Authmode psk
#IKE DH Group dh2 # this is the default
DNSUpdate no
DPD idle timeout (our side) 0
NAT Traversal Mode cisco-udp

Ma connexion VPN fonctionne toujours après 20 heures jusqu'à présent.

J'ai eu le même problème et aucune des solutions suggérées n'a fonctionné pour moi. En fin de compte, j'ai abandonné vpnc et essayé le client vpn ShrewSoft. C'est un peu compliqué parce que vous devez le compiler vous-même (et installer manuellement toutes les dépendances manquantes - dans mon cas, cmake, libedit2, flex et bison). Mais cela semble bien fonctionner.

Au moment de la rédaction, vous pouvez le télécharger à partir de https://www.shrew.net/download/ike

Vous pourriez regarder l' --nat-keepaliveoption, peut-être essayer--nat-keepalive 1200

À un moment donné, il s'agissait d'un bug connu , je ne sais pas s'il a jamais été corrigé.

J'ai le même problème, http://dietrichschroff.blogspot.com/2011/07/linux-vpn-client-disconnect-every-600s.html semble mentionner que le problème peut être lié au groupe DH utilisé. Pour changer le groupe DH en 5, dans votre fichier de configuration, ajoutez

IKE DH Group dh5

Les options pour ce changement de configuration sont

IKE DH Group <dh1/dh2/dh5>

La page d'accueil du projet VPNC ne mentionne pas qu'il s'agit d'un problème connu, mais je suppose que le "changement de phase2" n'est toujours pas aussi stable (sur la base des bogues signalés). Notez également que

• phase1-rekeying manquant

La version corrigée de 0.5.3 (comme la dernière version SVN du projet d'origine) de VPNC sur github comprend:

• Ajoute la capacité de répondre aux questions XAuth avec un script externe
• Ajoute des routines de nettoyage qui s'exécutent en cas de déconnexion inattendue
• Ajoute une solution de contournement pour le scénario dans lequel le concentrateur pose une question Xauth en tant que demande de mot de passe.
• Ajoute le patch de Mihai Maties pour la détection de Dead Peer ( http://lists.unix-ag.uni-kl.de/pipermail/vpnc-devel/2010-December/003492.html )

Je recommanderais également un garde-montre comme solution ultime pour les reconnexions https://github.com/dcantrell/vpncwatch/network si un mode automatisé est très souhaité et que le côté distant peut toujours provoquer des déconnexions (sans lien avec le logiciel).

PS

Étant donné que VPNC est une version à ingénierie inversée de l'implémentation commerciale, les déconnexions avec des changements de version émergents du côté distant peuvent réapparaître jusqu'à ce qu'elles soient trouvées et corrigées à nouveau.

Enfin, il existe une option d'utilisation d'un client natif ( anyconnect ) pour linux. L'un des inconvénients est que les capacités de configuration côté client en tant que mise à jour des enregistrements DNS et aucune route par défaut sont extrêmement limitées. Un autre, les déconnexions auront toujours lieu mais en de très rares occasions.

J'ai le même problème sur Ubuntu 12.04, et avec VPNC, il se déconnecte exactement après 24 minutes.

J'ai essayé "Shrew Soft" que j'ai installé à partir du centre logiciel. J'ai pu configurer le VPN à l'aide du fichier .pcf que j'ai obtenu de mon service informatique. Ensuite, j'ai eu exactement le même problème.

Cependant, avec "Shrew Soft", vous pouvez configurer deux ou trois choses. Celui qui permet à ma connexion de rester active à tout jamais est le paramètre de Phase1-rekeying. J'ai changé la valeur "Key Life Time Limit" de 86400 (24 heures) à 600 secondes. Je suppose qu'il y a un bug quelque part où il utilise 24 minutes au lieu de 24 heures.

J'ai proposé un correctif pour la re-clé de la phase I d'IKE sur la base d'une soumission de correctif précédente qui rend ma connexion initiée par vpnc stable pendant plusieurs jours par rapport à une tête de réseau ASA. Ma vie phase 1 est 24h il fait rekey avec succès et maintient la connexion en vie. Par exemple

• re-clés SA de phase 2 (IPsec) -et-
• re-clés SA de phase 1 (ISAKMP).