OPENVPN - Connexions des clients

OPENVPN - Connexions des clients - Réseaux - Systèmes & Réseaux Pro

Marsh Posté le 12-03-2013 à 14:53:22    

Bonjour à tous,  
 
En fait j'ai déjà ouvert un sujet sur OPenVpn mais je m'aperçois que ma deuxième demande n'est pas vraiment (pour pas dire pas du tout) la même que la première.
Le probleme est très simple mais je me casse le nez dessus à chaque coup...
 
Voila quand je suis connecté en interne au LAN, je peux me connecter au serveur OPENVPN (sous windows) sans soucis. Je précise que c'est un serveur 2003.  
Ce serveur est relié directement au net enfin avec un routeur firewall devant. Ce routeur est bien configurer pour rédiriger le port X vers la machine du LAN. Dès que je veux me connecter avec le client j'ai un message d'erreur du serveur : TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Je précise que j'utilise pour me connecter non pas le client OPENVPN mais Viscosity (qui est compatible Apple....). Je précise également que jeudi dernier tout marchait parfaitement depuis l'extérieur et qu'un redémarrage du serveur semble avoir fait basculer.
Le firewall WINDOWS n'est pas activé...
Il n'est pas actif sur l'interface qui va au routeur....
 
Quelqu'un aurait une idée ???
 
Merci d'avance,  
 
Mathieu

Reply

Marsh Posté le 12-03-2013 à 14:53:22   

Reply

Marsh Posté le 12-03-2013 à 15:04:59    

Hello,
 
le serveur OpenVPN est bien monté là? un netstat montre qu'il écoute sur son port d'entrée? il y a peut-être quelquechose de mal monté dans la config, et au reboot du serveur, le service ne s'est pas relancé.
la connexion avec le client se fait de quel côté?
 
Cordialement,

Reply

Marsh Posté le 12-03-2013 à 15:46:48    

Hello,  
 
Tout d'abord merci de la réponse...
Je n'ai pas essayé le netstat mais étant donné qu'il accepte mes connexions en interne .... Je pense qu'il écoute bien.. Car le poste client se connecte sans soucis et obtient son IP...
Le client est dans ce cas un portable connecté à l'extérieur de la structure avec une clé 3G . Je précise que le test réalisé se fait depuis chez moi donc derrière une freebox et que justement cela a très bien fonctionné la semaine dernière...
 
Incompréhensible....
N'y a t il pas qq chose dans Windows Server 2003 qui bloquerait ?
Je n'ai plus aucune idée...
 
Merci d'avance,

Reply

Marsh Posté le 12-03-2013 à 16:13:43    

mathcyber a écrit :

Hello,  
 
Tout d'abord merci de la réponse...
Je n'ai pas essayé le netstat mais étant donné qu'il accepte mes connexions en interne .... Je pense qu'il écoute bien.. Car le poste client se connecte sans soucis et obtient son IP...
Le client est dans ce cas un portable connecté à l'extérieur de la structure avec une clé 3G . Je précise que le test réalisé se fait depuis chez moi donc derrière une freebox et que justement cela a très bien fonctionné la semaine dernière...
 
Incompréhensible....
N'y a t il pas qq chose dans Windows Server 2003 qui bloquerait ?
Je n'ai plus aucune idée...
 
Merci d'avance,


 
Hello,
 
Très bien pour le fonctionnement interne je ne sais pas combien de cartes a le serveur d'où mon questionnement sur la config, donc du socket d'écoute.
vu qu'il s'agit d'un windows 2003, il est donc possible de voir ce qu'il se passe avec un sniffer du type wireshark.
Moi je vérifierai en interne dans un premier temps pour voir le dialogue et au niveau transport si c'est UDP ou TCP.
Ensuite, faire tourner wireshark durant la tentative de connexion depuis l'extérieur. Faire également bien attention à configurer le transfert de port en TCP pour les connexions externes.
Pour l'instant je ne vois pas mieux, et je ne pense pas qu'il s'agissent d'un problème de firewall si ce dernier est bel et bien down.
 
COrdialement,
 

Reply

Marsh Posté le 12-03-2013 à 16:53:54    

RE,  
 
Cette réponse est assez précise. Alors je vais compléter un peu . Sur ce serveur il y a 2 cartes réseaux en activité. Celle qui est connectée au routeur avec une adresse de type 192.168.0.1 et une autre qui est destinée au  réseau local. (type adresse : 192.9.230.0)
EN effet sur le routeur je n'ai redirigé que le port destiné au VPN en UDP de l'IP externe vers l'IP interne du serveur soir la 192.168.0.1
Je pense effectivement que certaines requêtes sont bloquées , quand tu me parlesdu ransfert de port TCP duquel parles tu? Je n'en ai redirigé qu'un vers l'intérieur du réseau celui du VPN...
En fait lorsque le VPN se connecte sur l'interface reliée au routeur il attribue directement une IP en 10.8.0.0 puisque le but est d'acéder uniquement à cette machine...
Je vais essayer de tenter ta solution... SI tu en as une autre avec ce que je viens de dire...

Reply

Marsh Posté le 12-03-2013 à 16:56:05    

Wireshark est bien sur à utiliser sur le serveur vpn .... non?

Reply

Marsh Posté le 12-03-2013 à 17:15:55    

mathcyber a écrit :

RE,  
 
Cette réponse est assez précise. Alors je vais compléter un peu . Sur ce serveur il y a 2 cartes réseaux en activité. Celle qui est connectée au routeur avec une adresse de type 192.168.0.1 et une autre qui est destinée au  réseau local. (type adresse : 192.9.230.0)
EN effet sur le routeur je n'ai redirigé que le port destiné au VPN en UDP de l'IP externe vers l'IP interne du serveur soir la 192.168.0.1
Je pense effectivement que certaines requêtes sont bloquées , quand tu me parlesdu ransfert de port TCP duquel parles tu? Je n'en ai redirigé qu'un vers l'intérieur du réseau celui du VPN...
En fait lorsque le VPN se connecte sur l'interface reliée au routeur il attribue directement une IP en 10.8.0.0 puisque le but est d'acéder uniquement à cette machine...
Je vais essayer de tenter ta solution... SI tu en as une autre avec ce que je viens de dire...


 
Hello,
 
Merci pour ces petites précisions. Alors, maintenant quand tu dis que cela fonctionne en interne, tu visais bien la 192.168.0.1? et non pas celle du LAn? (192.9.230.x) Je demande cela pour vérifier si celle visée depuis l'externe est bien celle qui a marché lors de ton test.
Il se peut que l'OpenVPN n'écoute que sur ta carte LAN suivant la conf.
Pour l'histoire du port, je parle bien du port d'écoute du serveur OpenVPN.
Je ne quote pas, mais pour le second message, il faut bien sniffer sur le serveur VPN comme tu y as pensé.
 
Cordialement,

Reply

Marsh Posté le 12-03-2013 à 17:27:32    

Au fait j'ai oublié de préciser, pour l'IP interne, il vaudrait mieux mettre 192.168.x.x au lieu de 192.9.x.x car il s'agit d'un adressage privé.
(je ne sais pas si ce n'était qu'un exemple..)

Reply

Marsh Posté le 12-03-2013 à 17:44:38    

Re,  
 
ALors pour le deuxième message si tu savais le travail qu'il y a à réaliser sur ce réseau.... tu serais fou, d'ailleurs soit dit en passant je vais pas tarder à chercher un mec qui m'aide à auditer les réseau car c'est vraiment une cata...
Pour le VPN qd je me connecte au LAN de la boite, j'ai une IP fixe type 192.9.230.X et j'appelle le serveur sur l'interface à laquelle je peux accéder soit disons que le serveur est en 192.9.230.200 (ETH1 - Carte du réseau interne). Là pas de soucis ça marche.
Maintenant le serveur VPN (OPENVPN) tourne bien sur le serveur, une interface virtuelle est créée (donc 3e interface) je pense car il attribue comme adresse au serveur la 10.8.0.1.
ET il y a ETH2 qui elle est reliée directement au routeur. L'adresse de ETH2 est 192.168.0.2 (par exemple). Le routeur à l'adresse IP externe (donc 88.XX.XX.XX) et je le ping bien en adresse 192.168.0.1 (par exemple).
Donc je visais celle du LAN pas celle de la carte qui recoit la connexion externe....
Effectivement tu m'y fait pensé .. Celle que je vise lros du test par l'exterieur est ETH2 alors qu'en test interne c'était ETH1...

Reply

Marsh Posté le 12-03-2013 à 17:44:50    

Y a t il un début de solution ?

Reply

Marsh Posté le 12-03-2013 à 17:44:50   

Reply

Marsh Posté le 12-03-2013 à 18:22:27    

mathcyber a écrit :

Y a t il un début de solution ?


 
Oui ton problème semble venir de là mais il peut encore y avoir autre chose.
Alors il faut changer sur pour celle côté routeur.
Je ne connais pas openvpn, mais si cela est change et que le problème continue, un petit wireshark devrait t'éclaircir.. À savoir si le trafic arrive sur la carte externe.
 
Bonne soirée


Message édité par Charon_ le 12-03-2013 à 18:25:54
Reply

Marsh Posté le 14-03-2013 à 15:51:43    

RE,  
 
Alors, j'ai installé Wire... Lorsque je me connecte sur l'IP externe (soit 88.1.1.1 par exemple), je vois bien le traffic arriver sur le pc de destination avec une ip 192.168.0.2 les données provenant de OpenVPN.  
 
Cependant j'ai quand meme effectué un test probant... J'ai branché ce serveur directement sur le net .. Sans firewall windows, et là logiquement tout aurait du fonctionner .. c'est a dire que j'ai supprimé le routeur entre la box internet et le serveur open vpn... ET là oh surprise, tout est identique ça ne marche pas j'ai toujours la même erreur... ALors qu'en interne ca marche...
Je dois me rapprocher mais bon ...
 
EN fait si je schématise :  
 
Cas actuel :  
OPENVPN_client -> se connecte à 88.X.X.X (IP externe du routeur, port 1165 (exemple) redirigé vers 192.168.0.2 (adresse du serveur OpenVPN) depuis l'interface interne du routeur qui elle a l'ip 192.168.0.1 -> Arrivée des données sur le 192.168.0.2 mais message TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)  
 
Je précise que cette société possède plusieurs IP externe , que le modem LIVEBOX PRO distribue plusieurs IP sur un switch (basique) et que l'on branche le routeur sur ce switch en lui attribuant l'adresse IP externe libre et son adresse IP...
 
Là je ne sais plus quoi faire .... HELPPPPPP!!

Reply

Marsh Posté le 14-03-2013 à 17:00:44    

Hello,
 
Donc si je comprends bien, à partir des 2 lignes du début, tu vois bien le traffic arriver sur ton serveur OpenVPN dont l'IP est 192.168.0.2. qui a été envoyé du client Mac?
au niveau des data sur wireshark que tu aurais lancé depuis ce serveur, tu es arrivé à voir quelque chose de parlant au niveau de l'échange crypté?Présentation de la CA, échange des SA?
 
Pour le moment, avec ton erreur, l'enventualité serait :
 
Une fois que tu as généré ta PKI, tu as bien respecté cette étape?
If you are using Ethernet bridging, you must use server-bridge and dev tap instead of server and dev tun
(source OpenVPN)
 
En espérant que cela t'aide..
 
EDIT: j'ai rajouté une erreur concernant côté client sur l'ip à atteindre


Message édité par Charon_ le 14-03-2013 à 17:13:21
Reply

Marsh Posté le 14-03-2013 à 17:19:38    

Je viens de te répondre un peu à la va vite après ce que je t'ai demandé sur les échanges. L'ethernet bridge ne te concerne pas vu que tu as 2 cartes, il faut faire une route.
Je n'ai vraiment pas le temps ce soir d'y regarder plus.. Je devrai avoir un moment demain matin.

Reply

Marsh Posté le 14-03-2013 à 17:26:43    

Ce que je n'arrive pas à comprendre c'est que tout est ok quand je suis en interne. Je suis vraiment en train de me demander si les livebox business n'ont pas une couche de protection VPN....

Reply

Marsh Posté le 14-03-2013 à 17:28:58    

c'est vraiment cool de ta part...
Je vais regarder un peu plus les sorties de wire et te dire tt ça demain...
 
Un réseau d'entreprise fait par des nuls ça donne un réseau bancal et on ne sait rien de ce qu'il y a dessus.... pfff

Reply

Marsh Posté le 15-03-2013 à 10:03:30    

Si jamais,
regarde ce lien, le tutoriel est assez bien fait http://openmaniak.com/fr/openvpn.php
Je t'ai envoyé un message privé pour t'aider un peu mieux

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed