Echec connexion VPN

[mick.ch]

J'ai souhaiter installer open VPN sur mon IPCOP et j'ai un problème lors de ma connexion depuis un client Windows.

Voici le message d'erreur que j'obtient lorsque j'essai de me connecter :

Tue Jan 20 11:48:53 2009 OpenVPN 2.0.9 Win32-MinGW [SSL] [LZO] built on Oct 1 2006
Tue Jan 20 11:48:53 2009 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Tue Jan 20 11:48:55 2009 LZO compression initialized
Tue Jan 20 11:48:55 2009 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400)
Tue Jan 20 11:48:55 2009 Control Channel MTU parms [ L:1442 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Jan 20 11:48:55 2009 Data Channel MTU parms [ L:1442 D:1442 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Jan 20 11:48:55 2009 Local Options hash (VER=V4): 'a6ae7d69'
Tue Jan 20 11:48:55 2009 Expected Remote Options hash (VER=V4): '006a55ce'
Tue Jan 20 11:48:55 2009 UDPv4 link local (bound): [undef]:1194
Tue Jan 20 11:48:55 2009 UDPv4 link remote: 10.10.10.2:1194
Tue Jan 20 11:48:55 2009 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Jan 20 11:48:57 2009 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Jan 20 11:48:59 2009 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Jan 20 11:49:02 2009 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Jan 20 11:49:04 2009 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Jan 20 11:49:06 2009 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Jan 20 11:49:08 2009 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Jan 20 11:49:10 2009 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Jan 20 11:49:12 2009 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Jan 20 11:49:14 2009 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Jan 20 11:49:15 2009 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Jan 20 11:49:18 2009 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Jan 20 11:49:20 2009 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Jan 20 11:49:22 2009 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Jan 20 11:49:24 2009 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Jan 20 11:49:27 2009 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Jan 20 11:49:29 2009 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Jan 20 11:49:31 2009 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Jan 20 11:49:33 2009 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Jan 20 11:49:35 2009 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Jan 20 11:49:37 2009 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Jan 20 11:49:39 2009 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Jan 20 11:49:41 2009 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Jan 20 11:49:43 2009 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Jan 20 11:49:45 2009 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Jan 20 11:49:47 2009 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Jan 20 11:49:50 2009 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Jan 20 11:49:52 2009 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Jan 20 11:49:54 2009 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Jan 20 11:49:55 2009 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Jan 20 11:49:55 2009 TLS Error: TLS handshake failed
Tue Jan 20 11:49:55 2009 TCP/UDP: Closing socket
Tue Jan 20 11:49:55 2009 SIGUSR1[soft,tls-error] received, process restarting
Tue Jan 20 11:49:55 2009 Restart pause, 2 second(s)
Tue Jan 20 11:49:57 2009 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Tue Jan 20 11:49:57 2009 LZO compression initialized
Tue Jan 20 11:49:57 2009 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400)
Tue Jan 20 11:49:57 2009 Control Channel MTU parms [ L:1442 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Jan 20 11:49:57 2009 Data Channel MTU parms [ L:1442 D:1442 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Jan 20 11:49:57 2009 Local Options hash (VER=V4): 'a6ae7d69'
Tue Jan 20 11:49:57 2009 Expected Remote Options hash (VER=V4): '006a55ce'
Tue Jan 20 11:49:57 2009 UDPv4 link local (bound): [undef]:1194
Tue Jan 20 11:49:57 2009 UDPv4 link remote: 10.10.10.2:1194
Tue Jan 20 11:49:57 2009 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Jan 20 11:49:58 2009 TCP/UDP: Closing socket
Tue Jan 20 11:49:58 2009 SIGTERM[hard,] received, process exiting

Voici également ma configuration sur ipcop :

Paramètres généraux

ZERINA-0.9.5b

Current OpenVPN Server Status: En Fonction
OpenVPN on RED OUI
OpenVPN on BLUE NON
OpenVPN on ORANGE NON
Nom d'hôte ou IP locale du RPV: Mon Interface Red
OpenVPN Subnet(e.g. 10.0.10.0/255.255.255.0): 10.179.173.0/255.255.255.0
OpenVPN device : TUN
Protocole: UDP
Port destination: 1194
MTU Size:1400
LZO-Compression: OUI
Encryption: BF-CBC



[/img]

[ccnet]

Si vous vous connectez depuis internet, ce qui devrait être le cas puisque vous avez paramétré Openvpn pour un fonctionnement sur RED, il est normal que rien ne fonctionne. Vous ne pouvez pas espérer atteindre le vpn avec l'ip 10.10.10.2. Il faut une adresse publique, routable sur internet. Cette ip a manifestement été insérée dans le fichier openvpn.conf.

Tue Jan 20 11:48:55 2009 UDPv4 link remote: 10.10.10.2:1194

Si vous essayez cette connexion depuis GREEN, cela ne peut pas fonctionner non plus. Ipcop + Zerina ne sont pas fait pour gérer un vpn sur Green. Green ne gère qu'un seul réseau, or la connexion vpn utilise son propre numéro de réseau.

La première chose serait de décrire vos conditions de tests. L'expérience m'a montré en ce domaine que c'est souvent les conditions de test qui sont erronées et non le vpn qui ne fonctionne pas. Un mauvais test conduit à des conclusions fausses.

La seconde serait poster le fichier openvpn.conf du client de test.

[shwing]

une petite précision,

A la place d'une ip public qui peut changer selon le type de contrat avec le FAI, un dyndns, ou un no-ip fonctionnent très bien aussi. ceci bien entendu pour lutter contre les IPs du FAI qui pourraient changer.

[mick.ch]

Bonjour et merci pour vos réponses,

ccnet: l'adresse dont vous parlez (10.10.10.2) est en faite l'adresse ip de mon interface rouge.
Je l'ai saisis dans l'onglet VPN (Nom d'hôte ou IP locale du RPV)



J'ai ensuite généré un certificat avec les coordonées de ma société.

J'ai installer la partie cliente en incluant le certificat dans programFiles\openVPN\config

Je ne sais pas trop si j'ai oublié quelque chose car c'est la première fois que j'utilise le VPN.

Je ne trouve pas le fichier OpenVPN.conf où est il situé svp?

shwing: Je connais déja le principe du dns dynamique et je pense à le mettre en place égalment mais j'attendait de passé sur un systeme en production car pour l'instand nous sommes seulement en phase de test, mais merci quand même

Autre point à quoi correspond le champ OpenVPN Subnet? Pour ma part j'ai laissé la valeur par défaut!

Merci

[ccnet]

Il va être difficile de vous aider. Je vous ai demandé et je vous demande à nouveau d'indiquer vos conditions de tests.

Le fichier de configuration du client se trouve en général dans c:\Program Files\OPenvnp\config selon l'installation que vous avez réalisé pour le client OpenVPN. Il peut porter un nom différent tel que : admin-TO-IPCop.ovpn. Si vous avez installé à partir du package que l'on peut télécharger depuis l'interface d'administration le nom est <username>-TO-IPCop.ovpn.

L'ip 10.10.10.2 n'est pas routable sur internet. En comprenez vous les conséquences ? Votre passerelle vpn n'est pas accessible avec cette ip.

Si vous ne comprenez pas à quoi correspoond le OpenVPN Subnet, il est temps de lire la documentation. L'ip affectée au client vpn sera issue dans ce sous réseau.

Il est impossible d'aider les personnes qui ne fournissent pas les informations nécessaires.

[mick.ch]

Excusé moi de ne pas maîtriser l'outil IPCOP aussi bien que vous et que mes analyses ne soit pas forcement très bien détaillées mais je débute sur IPCOP...

Mes conditions de tests sont les suivantes:

Je travaille pour l'instand sur un réseau de test qui est basé sur une livebox, (adresse 10.10.10.1) derrière elle un IPCOP (qu'on appelera IPCOP TEST)
Mon interface rouge IPCOP à elle l'adresse 10.10.10.2
Et mon LAN TEST se trouve sur la plage 192.168.0.50 à 192.168.0.100 /24 par DHCP

Pour vérifier que mon VPN fonctionne j'ai une machine (cliente) dans un autre réseau (notre réseau de production actuelle derrière un IPCOP PROD, en 192.168.0.X) qui va tenter de se connecter à mon vpn pour faire partir de mon LAN TEST!

J'essai de faire au plus simple désolé si je ne suis pas très clair!

Je comprend parfaitement qu'une IP en 10.X.X.X ne peut pas etre routable sur internet mais je ne sais pas pourquoi il tente de se connecter avec cette adresse! Il devrait utiliser l'IP publique de mon réseau TEST pour se connecter.

Voila le fichier demandé:

#OpenVPN Server conf
tls-client
client
dev tun
proto udp
tun-mtu 1400
remote 10.10.10.2 1194
pkcs12 ipnotic.p12
cipher BF-CBC
comp-lzo
verb 3
ns-cert-type server

Si je remplace ici l'IP en 10.XXX et que je met mon IP Publique est ce que sa devrait fonctionner?

[mick.ch]

Je viens de faire le test en question en remplaçant l'ip 10.10.10.2 dans le fichier de conf par mon adresse publique et voila le résultat sur le client :


Tue Jan 20 15:54:39 2009 OpenVPN 2.0.9 Win32-MinGW [SSL] [LZO] built on Oct 1 2006
Tue Jan 20 15:54:39 2009 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Tue Jan 20 15:55:07 2009 LZO compression initialized
Tue Jan 20 15:55:07 2009 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400)
Tue Jan 20 15:55:07 2009 Control Channel MTU parms [ L:1442 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Jan 20 15:55:07 2009 Data Channel MTU parms [ L:1442 D:1442 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Jan 20 15:55:07 2009 Local Options hash (VER=V4): 'a6ae7d69'
Tue Jan 20 15:55:07 2009 Expected Remote Options hash (VER=V4): '006a55ce'
Tue Jan 20 15:55:07 2009 UDPv4 link local (bound): [undef]:1194
Tue Jan 20 15:55:07 2009 UDPv4 link remote: 90.53.234.210:1194
Tue Jan 20 15:56:06 2009 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Jan 20 15:56:06 2009 TLS Error: TLS handshake failed
Tue Jan 20 15:56:06 2009 TCP/UDP: Closing socket
Tue Jan 20 15:56:06 2009 SIGUSR1[soft,tls-error] received, process restarting
Tue Jan 20 15:56:06 2009 Restart pause, 2 second(s)
Tue Jan 20 15:56:08 2009 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Tue Jan 20 15:56:08 2009 LZO compression initialized
Tue Jan 20 15:56:08 2009 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400)
Tue Jan 20 15:56:08 2009 Control Channel MTU parms [ L:1442 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Jan 20 15:56:08 2009 Data Channel MTU parms [ L:1442 D:1442 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Jan 20 15:56:08 2009 Local Options hash (VER=V4): 'a6ae7d69'
Tue Jan 20 15:56:08 2009 Expected Remote Options hash (VER=V4): '006a55ce'
Tue Jan 20 15:56:08 2009 UDPv4 link local (bound): [undef]:1194
Tue Jan 20 15:56:08 2009 UDPv4 link remote: 90.53.234.210:1194

[ccnet]

C'est maintenant clair. Les conditions de test sont globalement valides.

Bien sûr il faut remplacer par l'ip publique dans "remote 10.10.10.2 1194" .

Vous pouvez supprimer comp lzo dans un premier temps.

Il reste à vérifier certains points. Le premier est de valider la sortie du trafic du client pour le port UDP 1194. Même chose de l'autre coté. Il est critique de vérifier que la livebox coté réseau de test, donc à l'arrivée, transmet bien les paquets udp à l'interface RED de l'ipcop de test avec le vpn.

Il faut aussi vérifier vos translations d'adresses.

A priori 90.53.234.210 ne répond tout simplement pas.

[mick.ch]

De mon coté l'adresse 90.53.234.210 répond sans problème au ping (depuis mon réseau de prod)
Pour la sortie des paquet udp 1194 il ne doit pas y avoir de problème (BOT n'est pas installer sur l'IPCOP de PROD, donc celui ou est le client)

Pour le coté de la livebox je ne sais pas trop comment faire pour voir si les paquets arrivent bien jusqu'à l'interface rouge de l'IPCOP de TEST???

Le passage des "paquets VPN" de rouge à vert est fait automatiquement quand on configure le VPN ou l'on doit faire quelque chose?

Vous pouvez voir le message d'erreur que j'ai après la modification de l'adresse dans mon dernier post.

[ccnet]

De mon coté l'adresse 90.53.234.210 répond sans problème au ping (depuis mon réseau de prod)

Ce qui ne prouve rien de la possibilité de recevoir UDP 1194
.

Pour la sortie des paquet udp 1194 il ne doit pas y avoir de problème (BOT n'est pas installer sur l'IPCOP de PROD, donc celui ou est le client)

Danger !!

Pour le coté de la livebox je ne sais pas trop comment faire pour voir si les paquets arrivent bien jusqu'à l'interface rouge de l'IPCOP de TEST???

Examen des logs ipcop de test. TCPDUMP sur ipcop de test.

Le passage des "paquets VPN" de rouge à vert est fait automatiquement quand on configure le VPN ou l'on doit faire quelque chose?

Oui.

Vous pouvez voir le message d'erreur que j'ai après la modification de l'adresse dans mon dernier post.

Non ? Tue Jan 20 15:56:08 2009 UDPv4 link remote: 90.53.234.210:1194 est normal. A ce stade c'est la connectivité réseau qui pose problème semble t il.

[mick.ch]

Citation:
Pour la sortie des paquet udp 1194 il ne doit pas y avoir de problème (BOT n'est pas installer sur l'IPCOP de PROD, donc celui ou est le client)

Danger !!

Je sais c'est pour cette raison que nous avons un second IPCOP en phase de test afin d'améliorer la sécurité de notre réseau.

Pour les test avec TCPDUMP
Est-ce qu'un tcpdump port 1194 va m'afficher le résultat voulu?

Pour les logs es-ce que l'erreur ne serait elle pas ici :

Tue Jan 20 15:56:06 2009 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Jan 20 15:56:06 2009 TLS Error: TLS handshake failed
Tue Jan 20 15:56:06 2009 TCP/UDP: Closing socket

Merci pour votre aide

[ccnet]

Oui, c'est bien se dont je parle :

(check your network connectivity)

Oui vous pourriez voir avec tcpdump si les paquets vers le port UDP 1194 en provenance de l'ip publique de l'autre livebox arrivent et comment ils sont traités.

[mick.ch]

Je sèche sur ce problème :

J'ai lancer un tcpdump port 1194 sur mon IPCOP TEST pour voir si les paquets arrivent mais je n'obtient rien.

J'ai essayé de configurer une route pour le port 1194 de la livebox TEST (10.10.10.1) vers mon IPCOP TEST (10.10.10.2) mais toujours rien!

Je ne vois pas comment je peut déceler d'où vient mon problème.

Si quelqu'un peut me guider dans cette démarche ce serait génial.

[mick.ch]

Un schéma pour mieux comprendre:

[IMG]http://img49.imageshack.us/img4

[mick.ch]

Les magies de l'informatique demeurent car mon problème c'est réglé seul!!!

J'ai pu me connecter au VPN du moment où orange à changé mon IP (qui est dynamique!) j'ai donc modifier le fichier de conf avec ma nouvelle adresse et miracle la connexion c'est établie.
J'ai vérifier mon ancienne IP en passant à une faute de frappe dans cette dernière mais elle était bien la bonne.

Le problème est réglé à par quelques lenteur sur le VPN pour l'instant mais je vais regardé ça de plus près!

Merci pour les aides