Reprise du message précédent :
Merci pour ton temps !
Bonne nuit.

Alors, a tu avancer ?

Bonjour,
 
J'ai installé openVPN sur un serveur Windows 2003 SBE. Et je me connecte dessus depuis l'extérieur avec une machine sous Windows Vista.
 
Lorsque openVPN fonctionne en tant que service sur le service sur le serveur, la connexion se fait correctement, mais impossible de pinger dans un sens, ni dans l'autre. Si je regarde l'activité de la carte TAPI, elle est nulle sur le serveur lorsque je ping depuis le serveur.
 
Par contre, si je lance openVPN avec mon utilisateur et le GUI, le connection se fait bien et les ping fonctionnent correctement.
 
Le problème est que je dois alors toujours laisser ma session ouverte sur le serveur pour que ça fonctionne.
 
Est-ce qu'il y a un changement à faire dans la configuration pour pouvoir utiliser openVPN comme service, puisque c'est seulement dans ce cas que ça ne marche pas ?

Comment fais tu pour le lancer en service ?
A tu vérifier que le service fonctionne (et comment ?) ?
 
Car normalement, aucune motif n'est requise dans les fichiers de config

Bonjour,
 
J'utilise OpenVPN sans problèmes. C'est un excellent outil.
 
Mon problème aujourd'hui vient du fonctionnement des connexions : si deux clients ayant le même certificat se connectent, le second connecté vas déconnecter le premier.
 
J'aimerai bloquer cette fonctionnalité et qu'une fois un client connecté avec un certificat, aucun autre ne puisse venir lui couper sa connection.
 
Je ne peux pas donner un certificat différent à chaque client, et je veux garder toujours la même adresse IP d'attribuée pour ce certificat.
 
Si vous avez une idée.....
 
Merci.
 
Aladin.

Tout simplement en ajoutant la dernière de ces lignes sans la commenter:

Mais c'est une bien mauvaise habitude !!

Par contre pour l'ip, la cela va carrement se corser !!

Une solution consiste a ecrire un bout de code (batch, C, ou autre...)
lisant si le client est connecté et autorisant l'acces ou non au VPN.
Mais helas je crains que le script n'arrive trop tard

Je souhaiterai pouvoir atteindre un serveur (kubuntu) se situant sur un réseau local depuis mes lieux de travail à partir d'un portable sous XP. Pour cela je souhaiterai installer openvpn. La question que je me pose est la suivante:
Est-il possible d'arriver sur ce serveur de l'extérieur et d'avoir une fenêtre sur mon portable en XP qui serait en fait le bureau déporté du serveur kubuntu et d'interagir sur ce serveur en sélectionnant à la souris les éléments disponible dans cette fenêtre.

Tu peut utiliser un VNC like, cela sera plus simple pour toi.
 
Par contre, XP n'étant pas X, tu ne pourra pas afficher seulement la  fenêtre d'une appli. Tu pourra par contre afficher le bureau complet.
 
Sur la configuration, je risque d'avoir du mal a t'aider travaillant majoritairement sur windows.

Hello Olivier.
 
Je prend la suite de nynjardin, je bosse avec lui sur la mise en place du VPN.
J'ai essayé de mettre en place tes recommandations, à savoir:
- Passer en TCP au lieu d'UDP
- Passer en TAP plutôt qu'un TUN
 
Ce sont pour l'instant les seules que j'essaye de mettre en place mais je rencontre déjà un problème.
 
Le passage de TUN à TAP se fait sans soucis, les clients peuvent toujours se connecter au serveur. Par contre en activant le protocole TCP au lieu de l'UDP, rien ne va plus, les clients refusent de se connecter au serveur. Ce qui est assez embettant.
 
J'ai vérifié au niveau du Firewall et à priori ça ne vient pas de là. As-tu une idée?

Je commence par te demander tes fichiers de config... Je pense que tu n'a pas utiliser la directive serveur. Dans un de mes vieux postes, tu doit avoir mon fichier serveur (p13). J'y ai en plus détaillé un petit peu mes options.
Comme cela, je dirai que UDP=>TCP pas de prb. Par contre pour TUN=>TAP, il faut changer les fichiers de config en affectant une plage IP pour les machines du VPN.
C'est la directive ;server 10.69.0.0 255.255.255.0 que j'utilise perso
Tu préfèrera augmenter le masque si tu attend plus de 255/4 client.
et donc passer a 255.255.0.0 par exemple.
Si tu le souhaite, tu peut également créer 2 réseau séparé:
69 => pour les jeux
70 => transfert de fichier
Ainsi, plus facile de les séparer sur 2 machines lors de la monté en charge sans se casser la tête.
Voila tout ce a quoi je pense juste maintenant.

hello,
je cherche les fichier server et client ovpn de Master_Jul car les liens sont morts ds le tutorial en 1ere page
merci

A tu pris le temps de lire le dernier post ?
Regarde p13

bonsoir, et merci pour le tuto qui est simple et semble efficace.
Semble, parce que je n'ai pas pu le mener à bout faute de pouvoir trouver vars.bat
Pour les fichier de config, ok page on fait du copier coller, mais le vars.bat lui, on se le procure comment ?
 
édit : c'est bon g trouvé !
 
Bon alors sa marche, le serveur se connect (ordis verts) mais lorsque j'essaye de connecter un client, il déco le serveur et me dit :  
Sat Nov 24 21:30:46 2007 us=434578 192.168.0.4:4034 CRL: cannot read: crl.pem: Le fichier spcifi est introuvable.   (errno=2)

Dans le fichier de config du serveur (et client ?), tu a une ligne suivi de crl.pem
Il s'agit d'une option permettant de vérifier les certificat rejeté par l'autorité.
Fais précéder la ligne d'un ; ou crée dans ton dossier de config un fichier crl.pem ne contenant rien pour résoudre ton prb.

Okay nikel sa marche
 
Mon Vpn est maintenant parfaitement fonctionnel, j'y accède depuis mon ordi portable, avec mon PDAphone SFR comme modem.
Je peux voir les ordis qui sont sur le meme réseau que le serveur ovpn, aller sur mes partage de fichiers...
 
Mais comment "faire comprendre" à mon ordinateur portable qu'il doit accèder à internet par le vpn, et pas par la connexion dispo par le mobile, qui est bridée ?

Tu peut: Proxy ou  routage passerelle.
1. Installer un serveur Proxy sur le serveur VPN
2. Rediriger la route 0.0.0.0 sur le VPN en sachant qu'elles est utilisé pour le DHCP et le VPN... Donc prendre un papier et un crayon avant pour verifier que tout colle bien au niveau des tables....

bonjour,
 
je rencontre un problème étrange que je n avais jamais remarqué et je ne sais pas si vous l'avez constater
 
En effet, je bosse dans le téléphone et à l'heure de la Voip j'ai testé quelquechose avec Openvpn dans ce sens.
 
Notre central téléphonique est compatible VoIP en H323 (bientot SIP j'espère) et comme logiciel tradionnel fonctionnant en H323 il y a ce bon vieux Netmeeting.
 
J'ai donc via une connexion OpenVPN (testé sous 3G ou sous connexion ADSL classique) lancé netmeeting pour qu'il se connecte sur le central téléphonique et s'authentifie en tant qu'un poste interne ....et la rien ne se fait...comment si il trouve pas le central!
 
Pourtant je le ping tres bien.
Ayant un routeur qui me permet de faire un VPN Ipsec j ai testé et la tout fonctionne sans problème
 
En conclusion, Openvpn semblerait bloquer certaines choses.
 
Qu en pensez vous?
 
Je précise que je suis en mode routed donc 2 plan adressage réseau
 
merci
 
PS: je sais que Netmeeting est vieux et n'est plus développé. je vous demande ca si vous avez des problèmes similaires, je ne pense pas approfondir ce problème car comme je disais plus haut le protocole SIP  est maintenant largement majoritaire en VoIP...par contre j'ignore si meme en SIP j'aurais le meme problème

Sans doute un problème de par-feu a première vue...

L'application peut ne pas écouter sur l'interface OpenVPN mais je pense surtout que certain paquet ne passe pas le VPN.
Le VPN doit bloqué certain paquet. Une des solutions qui peut expliquer cela peut être l'utilisation de protocole particulier.
 Je ne connaît pas assez les protocoles de téléphonie... mais je sais par exemple que le protocole de VPN de Microsoft utilise le protocol GRE. Celui-ci ne s'appuyant pas sur la couche TCP-IP, il ne passerai pas un travers un OpenVPN classique !

Pour contourner ce type de prb, il va te falloir ruser ! C'est un des rare cas où le passage en mode bridged me semble indispensable !!
Attention au changement dans le fichier de config. De plus, il faudra peut-être séparer les reseaux IP et Data si il y a trop de trame en boradcast. Rappel toi que dans ce cas, les trames DHCP seront stoppé par OpenVPN.
Dans tt les cas, n'oublie pas de me tenir au courant, l'expérience m'interresse même si cette semaine le temps me manque pour chercher a ta place ;-)

moui mais le problème c'est que le mode bridge, je ne suis pas chaud!
 
en effet mon serveur openvpn est un win2000 et je n ai pas un XP (ou 2003) allumé 24/24
 
C'est ca le gros reproche que j ai envers Openvpn : le mode bridge limite vraiment trop l'utilisation

je te tiens au courant...j'espère que tres bientot notre ordi de maintenance va revenir de son séjour chez un de nos clients et lui je peux lui mettre ce que je veux comme OS
 
De plus j'ai une petite précision a demander:
Le fait de s'appuyer sur du protocole TCP ou lieu de UDP pour openvpn ne résoudrait pas le problème?
 
Oui il est clair que certain paquet ne passe pas par Openvpn....je n'ai pas d'analyse comparative de trame entre avec openvpn et sans openvpn mais je suis pratiquement sur de ca que des paquet sont bloqués

TCP ou UDP ne changera rien. Il s'agit uniquement du format de l'encapsulation. Le prb si situe au niveau des paquet que l'on encapsule.
 
Je verifierai qd meme que ce n'est pas la config IP qui bloque.
Un coup d'oeil sur la table de routage du serveur VOIP devrai permettre de mieux comprendre ce qui se passe. En plus j'imagine que le serveur VoIP et Serveur VPN sont séparé ? Dans ce cas, un coup d'oeil sur cette table de routage permettra egalement d'eclairer les choses.
Attention egalement au temps de latence introduit par le VPN. En VoIP, le temps de latence peut etre crucial.
Un paquet ayant trop de retard peut-être automatiquement detruit !
(Dsl de pas t'avoir dit cela hier, mais je devais etre trop crevé !!)
 
Derniere chose: Quel est le prb avec windows 2000 ?

le serveur VoIP est un central téléphonique le plus simplement du monde . Par contre pour sa table de routage...
 
Je pense pas que ce soit un pb de latence car avec la meme connexion Internet j ai d'un coté le problème d'authentification sur netmeeting et de l'autre non avec juste la façon de faire le VPN qui change.
 
La table de routage du serveur VPN la voici:
 
===========================================================================
Liste d'Interfaces
0x1 ........................... MS TCP Loopback interface
0x2 ...00 ff e1 b3 a3 cd ...... TAP-Win32 Adapter V8
0x1000004 ...00 40 f4 6b 35 47 ...... VIA Rhine III Fast Ethernet Adapter                          
===========================================================================
===========================================================================
Itinraires actifs:
Destination rseau    Masque rseau  Adr. passerelle   Adr. interface Mtrique
          0.0.0.0          0.0.0.0  192.168.120.254   192.168.120.8   1
         10.8.0.0  255.255.255.252         10.8.0.1        10.8.0.1   1
         10.8.0.0    255.255.255.0         10.8.0.2        10.8.0.1   1
         10.8.0.1  255.255.255.255        127.0.0.1       127.0.0.1   1
   10.255.255.255  255.255.255.255         10.8.0.1        10.8.0.1   1
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1   1
    192.168.120.0    255.255.255.0    192.168.120.8   192.168.120.8   1
    192.168.120.8  255.255.255.255        127.0.0.1       127.0.0.1   1
  192.168.120.255  255.255.255.255    192.168.120.8   192.168.120.8   1
        224.0.0.0        224.0.0.0         10.8.0.1        10.8.0.1   1
        224.0.0.0        224.0.0.0    192.168.120.8   192.168.120.8   1
  255.255.255.255  255.255.255.255         10.8.0.1        10.8.0.1   1
Passerelle par dfaut:   192.168.120.254
===========================================================================
Itinraires persistants:
  Aucun
 
elle est classique...normalement rien ne bloque
 
Le pb de win 2000 est la création des ponts qui loin d'etre simple

je pense que je viens de découvrir d'ou vient le problème avec une trace que je viens de faire d'un coté au niveau de netmeeting (donc coté client) ou j ai bien les demandes de regristration faite sur le central et aucune réponse.
 
En faisait la meme chose coté central j ai vu qu il répond mais à l'adresse 192.168.0.2!!!! et non 10.8.0.6!!!!!! alors qu il recoit bien des trames de 10.8.0.6 en plus
 
bien sur l'adresse 192.168.0.2 (adresse mon réseau local distant) n'est pas routable...

je rajoute que ca explique pourquoi avec le VPN entre routeur ca marche sans soucis.
 
Donc après ca , j'espère que le mode pont devrait résoudre le problème (j'espère)
 
tout dépend du central téléphonique si il verra ce coup-ci la bonne adresse arriver et répondra aussi à la bonne adresse

Sur le serveur, je vérifierai que le routage est bien actif. Une façon simple de procéder est d'utiliser la directive client to client et de pinger le 2 client.
Ce qu'il serait interressant de noter dans la trace c'est l'ip source des messages.
Remarque, le fait qu'il réponde a 10.8.0.2 n'est pas forcement mauvais en soi car tout les paquets doivent transiter par 10.8.0.2 avant d'atteindre 10.8.0.6 (mode point-to-point sous windows). Par contre, si 10.8.0.2 est la seul adresse de destination ... la il y aura prb !
 
Tu peut également essayer de déporter le serveur NetMeeting sur le 2 client, histoire de voir le resultat.
Si le prb concerne uniquement les IP, sous linux une bonne règle de réécriture pourrait corriger le prb. Un grand pas en avant donc !!
 
Juste qq réflexion sans forcement être frais (Je viens de visiter la fête des lumière de Lyon pendant 4h...)
 

tout est parfaitement actif
 
Il ne repond pas a 10.8.0.2....mais a 192.168.0.2!!!

Et l'ip source ? Que donne cette piste ? Il est possible que certaine application mal écrite ne soit pas capable d'écouter sur 2 ip a la fois.
Peut être qu'une application listant les port ouvert sur ta machine permettrait d'en savoir un peu plus ? (Active port par exemple  http://www.ntutility.com)
 
Puis, en y repensant beaucoup, si le paquet passe sur la bonne interface, le mode brdige devrait quand même fonctionner même si les carte ne sont pas ponté... Tu peut donc te faire un essai si tu a le temps.
 
 

je pense justement que netmeeting est mal ecrit et qu il envoi (vu qu il écoute sur plusieurs interfaces) une autre adresse de reponse que celle que je veux....ce qui expliquerais le problème
 
d'ailleurs si on reste sur ce principe et que netmeeting est bien le fautif, mettre openvpn en pont provoquerait le meme problème

Bonsoir,
 
J'ai lu le début de ce topic, j'ai suivi tout et je pense avoir réussi pas mal d'étape.
 
En revanche, le fichier serveur.ovpn n'est plus dispo au téléchargement, et je sais pas comemnt l'éditer moi même...

Dans mes ancien post, page 13 de ce forum, tu trouvera le mien avec des commentaires pour bien le comprendre !

Bonjour, je suis en train de monter un VPN pour essayer d'acceder à tous les ports internet via la connection 3G de mon téléphone.
J'ai configuré un serveur VPN derriere une freebox sur lequel j'arrive à me connecter.
C'est une machine windows XP.
Si j'utilise le téléphone en mode modem j'arrive a accceder à internet (avec un pc portable).
Par contre avec le client openVPN directement sur le téléphone je ne parvient pas à obtenir de gateway et du coup, pas d'internet...
J'arrive à me connecter au VPN, j'arrive à pinger mon serveur, ma freebox (192.168.0.254) mais si je sors du reseau local, ca ne passe plus...
Mes fichiers de config sont les suivants:
(Je précise que je suis en connection bridge comme expliqué au début du tuto...)
SERVEUR:
mode server
port 443
proto tcp-server
dev tap
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
client-to-client
;secret static.key
;server 10.8.0.0 255.255.255.0
server-bridge 192.168.0.1 255.255.255.0 192.168.0.60 192.168.0.70
;ifconfig-pool-persist ipp.txt
push "route-gateway 192.168.0.254"
push "redirect-gateway"
;push "dhcp-option DNS 212.27.54.252"
;push "dhcp-option DNS 212.27.53.252"
;push "dhcp-option WINS 212.27.54.252"
duplicate-cn
keepalive 10 120
persist-key
persist-tun
status openvpn-status.log
verb 3
 
CLIENT :  
client
dev tap
proto tcp
remote xxx.xxx.xxx.xxx 443
route-method exe
route-delay 2
resolv-retry infinite
nobind
persist-key
persist-tun
http-proxy 195.115.25.129 8080
ca ca.crt
cert clientPhone.crt
key clientPhone.key
;route-gateway 192.168.0.254
;redirect-gateway
keepalive 5 600
verb 3

Tu a moyen de nous trouver une table de routage sur le téléphone ?
Moi je dirais que tu a un conflit entre les 2 routes, celle pour acceder a ton ordinateur (connection classique) et celle que tente de mettre le VPN.
 
La solution consiste a retoucher la table de routage manuellement mais attention a ne pas perdre la connectivite vers le serveur ou tous s'effondrera !
Comme tu est chez free pour ton adresse, la solution consiste a insérer une route pour cette IP en utilisant la passerelle courante puis de faire sauter la route par défaut de la passerelle courante afin que le serveur VPN puisse la remplacer. Maintenant, la pratique de ceci en automatique depend des outils a ta dispostion sur le smartphone et de ta table de routage courante !

Hello Olivier,
 
Ouf, j'ai eu le temps de bosser dessus à nouveau, je post ici mes configs pour que tu me dises ce que tu en penses.
 
Etant donné que c'est pour du jeu en réseau et que tout se passe en local (on ne sort pas du pays, donc pings dans tout les cas inférieurs à 50ms) j'ai pensé que l'UDP serait mieux (pas de contrôle d'erreur mais trames plus petites donc un ping plus faible?).
 
Config Serveur :

 
Config Client :

 
Comme tu peux le remarquer je génère un certificat par client, et j'ai activé le TA-KEY.
J'ai aussi baissé le cryptage au minimum (384b) car pour du jeu en réseau on en a pas vraiment besoin.
 
Alors par contre j'ai eu beau essayé avec et sans compression, en TCP comme en UDP, assez souvent au cours de la partie j'ai des montée de ping, alors qu'il n'y a aucune activité particulière sur le serveur ou sur mon client, la bande passante est aussi totallement disponible.
Je n'arrive pas à résoudre ce problème, qui est assez génant pour du jeu en réseau il faut bien l'avouer :-(
 
As-tu une idée d'où peut provenir le problème?

Je suis un peu degouté... Je t'avais tapé une longue reponse il y a 2 jour mais apparament, elle n'est pas passe...
 
Alors je reprend rapidement:
-UDP car 1 seule verification des paquets. Meme si cette verif est faite un peu plus tard, toujours plus efficace que 2 verification quand tres peu de perte.
 
-Tu a baisse la longeur de cle pour le .pem ? Normalement, y'a moyen de choisir l'algo de securité et de baisser encore plus la securité mais franchement, je ne sais pas du tout commen...  
 
-Pour tes monté de ping, peut tu lancer un ping sur l'ip publique pour comparer ? Ce peut etre un routeur intermediaire qui fait grimper le ping.
Dans le même ordre d'idée, j'essayerai de desactiver le ipp.txt et le status.txt le temps d'un essai...
 
-Je pense que les fichiers telle quelle ne marche pas. Il te manque un tls-auth ta.key 1 dans le fichier client.
 
-Tu peut a mon avis remonter le keep alive en doublant les valeurs.
 
Voila.... pas grand chose pour t'aider helas... mais bon gardons espoir !

Oups, j'ai un peu trop vite supprimé les lignes de commentaires de mes fichiers config, j'ai bien un tls-auth ta.key 1 dans mon fichier de config client.
 
J'édite pon message précédent pour remettre les fichiers de config bien comme il faut.
 
J'ai essayé de faire un ping -t sur l'interface publique et sur la virtuelle via le vpn, si je joue à mon jeu en me connectant sur l'ip vpn, j'ai des hausses de ping dans le jeu qui peuvent atteindre les 2000ms, sur l'interface publique j'ai au même moment des petites hausses de ping mlais qui s'arrètent à 200~300ms.
Toujours avec un ping -t, mais en me connectant cette fois-ci sur l'interface publique (sans passer par le vpn donc), les hausses de ping ont disparues.
Je penche donc pour OpenVPN qui n'est pas prévu à cet usage :-(

JOYEUX NOEL A VOUS TOUS
 
Pour vous tenir au courant sur mon problème que j'avais expliqué j ai des nouvelles. En effet, depuis on a pu passer en SIP au lieu de H323, donc on a pu se passer de netmeeting et la tout fonctionne tres bien avec openvpn!
Donc le problème était bien lié a netmeeting avec la gestion (mal faite) des multiples interfaces

Merci pour les nouvelles... et bonne route avec OpenVPN.
 
Joyeux Noël également !

je n ai pas encore pu tester la bonne qualité de la voix...nous avons la carte et les licences que depuis quelques jours (lundi 24 pour etre precis)

bonne année a tous!

 
 
J'ai exactement le meme problème...
 
quand je ping l'interface publique du serveur VPN je suis à 59 ms alors que quand je ping l'ip "VPN" 10.8.0.1 du server vpn j'ai des latences pouvant arriver jusque 2000 ms :x et donc ça se ressent dans les jeux, surf, ....
 
Quelqu'un a t il une solution à ce problème ?

Bonjour à tous,
 
 
Tout d'abord merçi beaucoup pour ce tutoriel très bien réalisé et surtout très complet, une vraie mine d'or!
 
Depuis quelques jours je me penche sur la configuration très simple pour un Vpn (entre deux postes sous Windows), voiçi ma configuration :
 
Poste serveur : 192.168.10.1 <=======> Poste client : 192.168.11.1
 
Le but de mon Vpn est simplement d'autoriser la prise de controle à distance (de manière sécurisée) sur le poste serveur par le poste client...
 
Ca fonctionne parfaitement, sauf que je rencontre quelques problèmes au niveau des performances...
 
 
Au niveau du ping depuis le client :
Ping de l'adresse publique : en moyenne 80 ms / Ping de l'adresse IP VPN (10.0.0.1) en moyenne 81 ms (La tout est ok, différence négligeable)
 
En revanche au niveau du débit lors d'un transfert de fichier, les performances sont environ divisées par deux !
J'ai effectué mon test avec le protocole FTP :
 
Si je me connecte directement sur l'adresse publique du serveur, le transfert s'effectue à une vitesse moyenne de : 190 Ko/s ( Ce qui correspond bien à mon upload moyen).
 
Tandis que si je me connecte avec l'adresse VPN, je me retrouve à 92 Ko/s....
 
 
Pour tester l'influence du cryptage sur la vitesse de transfert, j'ai effectué un test avec l'option "cipher none" sur le client et le serveur afin d'utiliser une connexion non cryptée. Résultat du test: gain de 3 à 4 Ko/s... Je reste donc loin des performances sans le tunnel Vpn.
 
J'ai peut être mal configuré mes paramètres au niveau réseau ?    
 
Quelqu'un a t-il une petite idée par rapport à ma question ? Merçi d'avance pour votre réponse.    
 
 
Sébastien
 
 
PS : Voici mes deux fichiers de configuration :
 
 
Configuration du serveur :
 
port 1194
proto tcp-server
dev tun
ifconfig 10.0.0.1 10.0.0.2
keepalive 10 60
secret key.txt
comp-lzo
status openvpn-status.log
verb 5
 
 
Configuration du client :
 
proto tcp-client
dev tun
remote ******
ifconfig 10.0.0.2 10.0.0.1
keepalive 10 60
secret key.txt
port 1194
comp-lzo
verb 3