Le VPN Windows se déconnecte toujours après <3 minutes, uniquement à partir de mon réseau

11

Premièrement, ce problème existe depuis près de deux ans. Jusqu'à ce que le défaut de serveur soit né, j'ai à peu près renoncé à le résoudre - mais maintenant, l'espoir renaît!

J'ai configuré un serveur Windows 2003 comme contrôleur de domaine et serveur VPN dans un bureau distant. Je suis capable de me connecter et de travailler sur le VPN à partir de tous les clients Windows que j'ai essayés, y compris XP, Vista et Windows 7 sans problème, à partir d'au moins cinq réseaux différents (entreprise et maison, domaine et non.) Cela fonctionne bien de tous.

Cependant, chaque fois que je me connecte à partir de clients sur mon réseau domestique, la connexion tombe (silencieusement) après 3 minutes ou moins. Après un court instant, il finira par m'indiquer que la connexion a été interrompue et tentera de recomposer / reconnecter (si j'ai configuré le client de cette façon.) Si je me reconnecte, la connexion se rétablira et semblera fonctionner correctement, mais encore une fois baissera silencieusement, cette fois après une période de temps apparemment plus courte.

Ce ne sont pas des gouttes intermittentes. Cela se produit à chaque fois, exactement de la même manière. La seule variable est la durée de la connexion.

Peu importe le type de trafic que j'envoie. Je peux rester inactif, envoyer des pings continus, RDP, transférer des fichiers, tout cela à la fois - cela ne fait aucune différence. Le résultat est toujours le même. Connecté pendant quelques minutes, puis mort silencieuse.

Étant donné que je doute que quelqu'un ait connu cette situation exacte, quelles mesures puis-je prendre pour dépanner mon VPN évolutif?

Contexte supplémentaire

Au cours de cette période de deux ans, j'ai changé de FAI (aux deux extrémités), ajouté un nouveau contrôleur de domaine (mon réseau) et changé de routeurs (les deux réseaux). Rien de tout cela n'a eu d'effet.

Le problème est reproductible à partir de plusieurs PC, avec différents systèmes d'exploitation, mais uniquement à partir de mon réseau.

J'ai vérifié que le comportement est indépendant du client en testant sur un appareil non Windows. J'ai configuré le VPN sur mon iPhone et connecté via wifi sur mon réseau. À l'aide d'une application appelée Scany, j'ai envoyé une requête ping au serveur en continu jusqu'à ce que la connexion tombe après environ 2 minutes - même comportement que je voyais sur les clients Windows. Par la suite, j'ai désactivé le wifi et le VPN sur AT & Ts 3G et j'ai pingé en continu sans aucune perte de requête pendant 11 minutes. Ce test a correctement isolé le problème sur mon réseau.

Le seul composant cohérent sur la période de deux ans est mon contrôleur de domaine qui gère WINS et agit également comme un serveur VPN pour les connexions entrantes. Mais, le trafic sortant ne doit pas passer par mon DC, il va directement au pare-feu / routeur, qui est directement connecté à mon modem câble.

Plus de notes

Une demande a été faite pour vérifier que mes itinéraires ne sont pas géniaux lorsque la connexion VPN est établie. J'ai jeté un coup d'œil et je ne vois rien de mal à l'évidence, mais mon expérience avec la configuration de l'itinéraire est assez limitée, donc je publie les données.

La plage de classe C de mon LAN est 192.168.1.255, la plage de classe C du LAN distant est 192.168.10.255. J'ai également masqué l'IP publique du serveur VPN (74.93.XXX.XXX).

>route print (VPN Disconnected)
===========================================================================
Interface List
 17...00 ff 10 80 57 0c ......Juniper Network Connect Virtual Adapter
 11...00 23 ae e6 bb 49 ......Realtek RTL8168C(P)/8111C(P) Family PCI-E Gigabit
Ethernet NIC (NDIS 6.20)
  1...........................Software Loopback Interface 1
 12...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
 13...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
 16...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.1.1     192.168.1.24     10
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
      192.168.1.0    255.255.255.0         On-link      192.168.1.24    266
     192.168.1.24  255.255.255.255         On-link      192.168.1.24    266
    192.168.1.255  255.255.255.255         On-link      192.168.1.24    266
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link      192.168.1.24    266
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link      192.168.1.24    266
===========================================================================
Persistent Routes:
  None


>route print (VPN Connected)
===========================================================================
Interface List
 25...........................VPN Test
 17...00 ff 10 80 57 0c ......Juniper Network Connect Virtual Adapter
 11...00 23 ae e6 bb 49 ......Realtek RTL8168C(P)/8111C(P) Family PCI-E Gigabit
Ethernet NIC (NDIS 6.20)
  1...........................Software Loopback Interface 1
 12...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
 13...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
 16...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.1.1     192.168.1.24     10
    74.93.XXX.XXX  255.255.255.255      192.168.1.1     192.168.1.24     11
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
      192.168.1.0    255.255.255.0         On-link      192.168.1.24    266
     192.168.1.24  255.255.255.255         On-link      192.168.1.24    266
    192.168.1.255  255.255.255.255         On-link      192.168.1.24    266
     192.168.10.0    255.255.255.0   192.168.10.134   192.168.10.134     11
   192.168.10.134  255.255.255.255         On-link    192.168.10.134    266
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link      192.168.1.24    266
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link      192.168.1.24    266
  255.255.255.255  255.255.255.255         On-link    192.168.10.134    266
===========================================================================
Persistent Routes:
  None
windows-server-2003  vpn 
— chanvre
source
Puisque vous avez essayé de résoudre ce problème auparavant, pouvez-vous nous faire savoir ce que vous avez déjà essayé afin que nous ne ressassions pas les choses qui n'ont pas fonctionné pour vous jusqu'à présent?
— Zypher
La plupart de ce que j'ai "essayé" impliquait de rechercher sur le Net des problèmes connexes, qui se sont finalement révélés très peu. Un problème qui peut ou non être pertinent est que le serveur VPN a des problèmes de configuration. Par exemple, pour communiquer avec lui une fois le VPN connecté, je dois utiliser son adresse IP plutôt que son nom (je modifie généralement le fichier hosts sur chaque client qui se connecte.) De plus, je désactive toujours "Utiliser la passerelle par défaut" lors de la connexion à le VPN car son routage RAS est mal configuré. Cependant, ces problèmes n'ont pas causé de problèmes lors de la connexion à partir d'un autre réseau.
— chanvre

Réponses:

8

Un immense merci à @Warner et @William pour leurs suggestions. En fin de compte, c'est la réponse de William qui m'a conduit à la résolution finale. Pour tous ceux qui viennent à la recherche, voici l'affaire.

Après une tonne de plaisanteries à essayer d'isoler le problème, j'ai finalement fait ce que William a suggéré et j'ai récupéré mes journaux de pare-feu. Ne m'attendant pas à trouver quelque chose d'intéressant, j'ai été surpris en voyant cette ligne:

PPTP ALG a rejeté le paquet de xxxx à xxxx: 1723

Sachant que PPTP est la configuration de ce VPN, j'ai fait une recherche sur l'erreur. Il s'avère que d' autres personnes l' ont également vu . Plus précisément, les gens avec mon routeur exact , le D-Link DIR-655.

Il s'avère que la solution est simple.

Dans l'interface d'administration Web du routeur, accédez à l'onglet Avancé et cliquez sur Paramètres du pare-feu dans le menu de gauche. Dans la section intitulée "CONFIGURATION DE LA PASSERELLE DE NIVEAU D'APPLICATION (ALG)", décochez la case PPTP (éventuellement, décochez également IPsec si votre VPN utilise ce protocole.) Cliquez sur "Enregistrer les paramètres" et dites au routeur de redémarrer. Voila!

Malheureusement, la désactivation de ces options ALG signifie que certaines fonctionnalités de routage avancées ne fonctionneront pas. Par exemple, la prise en charge PPTP est destinée à permettre à plusieurs clients NAT de tunneler simultanément vers le même serveur VPN. Cela ne fonctionnera probablement pas si la case est décochée. Cependant, si comme moi votre VPN ne fonctionne pas du tout lorsque la case est cochée, cela ne vous dérange probablement pas.

Je ne sais toujours pas pourquoi je me souviens avoir eu ce problème auparavant avec un routeur totalement différent, mais je suis heureux que cela fonctionne néanmoins.

— chanvre
source
J'ai eu un problème similaire et que savez-vous ... le même routeur D-Link. Votre solution a fonctionné. Merci! Fait intéressant, je n'ai jamais eu de problème avec mon VPN jusqu'à ce que j'insère un appareil Vonage VDV21-VD entre le modem câble et mon routeur D-Link.
— staticman
Quels journaux de pare-feu vous montrent ce message? Pas les journaux de pare-feu sur votre client VPN ou serveur VPN, je suppose.
— Ian Boyd
@Ian: Non, le pare-feu est le DIR-655 lui-même. C'est là que les journaux sont (consultables via leur interface Web.)
— chanvre
1
Cela a également résolu le problème pour moi. Attention: lors de l'ajout de la redirection de port requise par VPN.
— rouge
2

À une supposition, il y a un composant du trafic VPN qui est requis mais qui est bloqué (par exemple au niveau d'un pare-feu) ou perdu, et qui provoque le décrochage. Vérifiez les journaux du pare-feu si vous en avez pour les paquets perdus. Vérifiez les règles pour vous assurer que tous les ports et protocoles nécessaires sont activés. Vous pouvez également vouloir effectuer une surveillance continue de l'itinéraire de votre côté pour voir si le trafic est mal dirigé après le tunnel VPN. La commande "route print" affiche ces informations sous Windows.

— William
source
Ce sont d'excellentes suggestions, William. Merci. Je reviendrai avec mes résultats.
— chanvre
J'ai publié mes itinéraires en tant que modifications à la question.
— chanvre
Cette réponse m'a conduit à la résolution finale, que j'ai documentée séparément. Merci de votre aide!
— chanvre
1

J'avais le même défaut avec openwrt et luci, je me connectais via vpn à mon serveur openvpn sur mon routeur. La connexion serait établie, puis il continuerait à redémarrer mon modem 3G et à perdre ma connexion, la réponse était, pare-feu (merci de pointer la direction) et éditez la connexion: 1194. Ici, vous avez le choix d'où provenait la connexion VPN et par défaut c'était l'appareil, les deux autres options où lan et wan donc pour ma situation c'était wan, un changement rapide et redémarrer et fonctionne très bien ..

— Homme heureux
source
0

Dépannage de base. Éliminez l'équipement. Connexion Internet directement au PC. S'il est reproductible, un autre PC. Remplacez le modem, essayez différents FAI (modem cellulaire). Continuez à descendre jusqu'à ce que vous soyez isolé, puis dépannez l'équipement auquel il est isolé.

— Warner
source
Merci pour les suggestions. Dans ce sens, voici ce que je peux ajouter: Au cours de cette période de deux ans, j'ai changé de FAI (aux deux extrémités), ajouté un nouveau contrôleur de domaine (mon réseau) et changé de routeurs (les deux réseaux). Rien de tout cela n'a eu d'effet. La connexion du serveur VPN directement à Internet ne se fera pas, même pendant quelques minutes, donc c'est fini. Le problème est reproductible à partir de plusieurs PC, avec différents systèmes d'exploitation, mais uniquement à partir de mon réseau. Cependant, cela m'a donné l'idée de l'essayer à partir d'un client non Windows, que j'essaierai maintenant.
— chanvre
Votre réseau de travail est déjà hors de portée, comme vous l'avez dit vous-même, il est isolé de votre réseau. Il semble que ce soit votre connexion ou votre équipement réseau. Connectez votre connexion domestique directement à un PC fonctionnant connu contre le VPN.
— Warner
J'ai configuré le VPN sur mon iPhone et je me suis connecté via wifi sur mon réseau. À l'aide d'une application appelée Scany, j'ai envoyé une requête ping au serveur en continu jusqu'à ce que la connexion tombe après environ 2 minutes - même comportement que je voyais sur les clients Windows. Par la suite, j'ai désactivé le wifi et le VPN sur AT & Ts 3G et j'ai fait un ping continu sans aucune demande perdue pendant 7 minutes (et en comptant). Ce test isole correctement le problème sur mon réseau. Cependant, je l'avais déjà fait - il offre donc peu de nouvelles informations, sauf que le comportement est indépendant du client.
— chanvre
Pour info - ce ping a fonctionné pendant 11 minutes sans problème avant de m'ennuyer et de le tuer.
— chanvre
1
Arrêtez votre DC. Le problème persiste-t-il? Connectez votre poste de travail directement à Internet. Cela continue-t-il? Quel équipement a été éliminé en se connectant directement à Internet?
— Warner
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.