Problème Openvpn sur IPCOP

[yakety]

Bonjour,

Nouveau venu dans le monde d'OpenVPN, je souhaite l'utiliser pour les connexions VPN de mon entreprise.
Version : 1.4.16
Version ZERINA : 0.9.5.a

Jusqu'à aujourd'hui, nous utilisions le serveur interne au routeur NERIM que nous avons mais qui est limité à 16 connexions..... ce qui devient trop peu aujourd'hui.

J'ai donc installé IPCOP sur une machine qui est aujourd'hui sur une deuxième ligne ADSL de secours et qui me sert pour l'occasion de ligne de test.

Voici la configuration exacte du réseau aujourd'hui :

http://www.monsterup.com/upload/1196335258.jpg

Les clients OpenVPN prennet donc une adresse IP en 10.30.10.x lorsqu'ils se connectent.
Aujourd'hui, les clients qui se connectent en PPTP sur la liaison SDSL ont accès sans soucis au serveur 10.10.10.100 (bureau à distance...Etc....)

Cependant, du côté IPCOP, la connexion OpenVPN se fait bien, je peux pinger l'interface 10.10.10.10 mais impossible de pinger ou d'accéder au serveur (10.10.10.100) ou toute autre machine présente sur le réseau en 10.10.10.x

J'ai bien accès à l'interface Web IPCOP lorsque mon PC est connecté sur le switch donc pas de soucis de communication de ce côté là.

Voici la config de mon fichier ovpn sur mon poste client (nous passons par le port 80 et mon PC est sous VISTA, ce qui explique les deux dernières lignes) :

#OpenVPN Server conf
tls-client
client
dev tun
proto udp
tun-mtu 1400
remote 217.128.xx.xx 80
pkcs12 christophe.p12
cipher BF-CBC
comp-lzo
verb 3
ns-cert-type server
route-method exe
route-delay 2

Voici le log de connexion (de la connexion à la deconnexion) :

Thu Nov 29 11:28:23 2007 OpenVPN 2.0.9 Win32-MinGW [SSL] [LZO] built on Oct 1 2006
Thu Nov 29 11:28:23 2007 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.
Thu Nov 29 11:28:29 2007 LZO compression initialized
Thu Nov 29 11:28:29 2007 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400)
Thu Nov 29 11:28:29 2007 Control Channel MTU parms [ L:1442 D:138 EF:38 EB:0 ET:0 EL:0 ]
Thu Nov 29 11:28:29 2007 Data Channel MTU parms [ L:1442 D:1442 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Thu Nov 29 11:28:29 2007 Local Options hash (VER=V4): 'a6ae7d69'
Thu Nov 29 11:28:29 2007 Expected Remote Options hash (VER=V4): '006a55ce'
Thu Nov 29 11:28:29 2007 UDPv4 link local (bound): [undef]:1194
Thu Nov 29 11:28:29 2007 UDPv4 link remote: 217.128.33.97:80
Thu Nov 29 11:28:29 2007 TLS: Initial packet from 217.128.33.97:80, sid=097a5193 c48e735d
Thu Nov 29 11:28:29 2007 VERIFY OK: depth=1, /C=FR/O=RHONETRADING/CN=RHONETRADING_CA
Thu Nov 29 11:28:29 2007 VERIFY OK: nsCertType=SERVER
Thu Nov 29 11:28:29 2007 VERIFY OK: depth=0, /C=FR/O=RHONETRADING/CN=217.128.33.97
Thu Nov 29 11:28:29 2007 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Nov 29 11:28:29 2007 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 29 11:28:29 2007 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Nov 29 11:28:29 2007 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 29 11:28:29 2007 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Thu Nov 29 11:28:29 2007 [217.128.33.97] Peer Connection Initiated with 217.128.33.97:80
Thu Nov 29 11:28:31 2007 SENT CONTROL [217.128.33.97]: 'PUSH_REQUEST' (status=1)
Thu Nov 29 11:28:31 2007 PUSH: Received control message: 'PUSH_REPLY,route 10.10.10.0 255.255.255.0,route 10.30.10.1,ifconfig 10.30.10.6 10.30.10.5'
Thu Nov 29 11:28:31 2007 OPTIONS IMPORT: --ifconfig/up options modified
Thu Nov 29 11:28:31 2007 OPTIONS IMPORT: route options modified
Thu Nov 29 11:28:31 2007 TAP-WIN32 device [Connexion au réseau local 5] opened: \\.\Global\{B7CBC82D-A66F-4DFF-91C7-F4AD861578B5}.tap
Thu Nov 29 11:28:31 2007 TAP-Win32 Driver Version 8.4
Thu Nov 29 11:28:31 2007 TAP-Win32 MTU=1500
Thu Nov 29 11:28:31 2007 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.30.10.6/255.255.255.252 on interface {B7CBC82D-A66F-4DFF-91C7-F4AD861578B5} [DHCP-serv: 10.30.10.5, lease-time: 31536000]
Thu Nov 29 11:28:31 2007 Successful ARP Flush on interface [29] {B7CBC82D-A66F-4DFF-91C7-F4AD861578B5}
Thu Nov 29 11:28:33 2007 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
Thu Nov 29 11:28:33 2007 route ADD 10.10.10.0 MASK 255.255.255.0 10.30.10.5
OK!
Thu Nov 29 11:28:33 2007 route ADD 10.30.10.1 MASK 255.255.255.255 10.30.10.5
OK!
Thu Nov 29 11:28:33 2007 Initialization Sequence Completed
Thu Nov 29 11:31:22 2007 [217.128.33.97] Inactivity timeout (--ping-restart), restarting
Thu Nov 29 11:31:22 2007 TCP/UDP: Closing socket
Thu Nov 29 11:31:22 2007 route DELETE 10.30.10.1 MASK 255.255.255.255 10.30.10.5
OK!
Thu Nov 29 11:31:22 2007 route DELETE 10.10.10.0 MASK 255.255.255.0 10.30.10.5
OK!
Thu Nov 29 11:31:22 2007 Closing TUN/TAP interface
Thu Nov 29 11:31:22 2007 SIGUSR1[soft,ping-restart] received, process restarting
Thu Nov 29 11:31:22 2007 Restart pause, 2 second(s)
Thu Nov 29 11:31:24 2007 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.
Thu Nov 29 11:31:25 2007 LZO compression initialized
Thu Nov 29 11:31:25 2007 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400)
Thu Nov 29 11:31:25 2007 Control Channel MTU parms [ L:1442 D:138 EF:38 EB:0 ET:0 EL:0 ]
Thu Nov 29 11:31:25 2007 Data Channel MTU parms [ L:1442 D:1442 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Thu Nov 29 11:31:25 2007 Local Options hash (VER=V4): 'a6ae7d69'
Thu Nov 29 11:31:25 2007 Expected Remote Options hash (VER=V4): '006a55ce'
Thu Nov 29 11:31:25 2007 UDPv4 link local (bound): [undef]:1194
Thu Nov 29 11:31:25 2007 UDPv4 link remote: 217.128.33.97:80
Thu Nov 29 11:31:25 2007 TLS: Initial packet from 217.128.33.97:80, sid=fedb2ddf ef2b61c7
Thu Nov 29 11:31:25 2007 VERIFY OK: depth=1, /C=FR/O=RHONETRADING/CN=RHONETRADING_CA
Thu Nov 29 11:31:25 2007 VERIFY OK: nsCertType=SERVER
Thu Nov 29 11:31:25 2007 VERIFY OK: depth=0, /C=FR/O=RHONETRADING/CN=217.128.33.97
Thu Nov 29 11:31:25 2007 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Nov 29 11:31:25 2007 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 29 11:31:25 2007 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Nov 29 11:31:25 2007 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 29 11:31:25 2007 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Thu Nov 29 11:31:25 2007 [217.128.33.97] Peer Connection Initiated with 217.128.33.97:80
Thu Nov 29 11:31:26 2007 SENT CONTROL [217.128.33.97]: 'PUSH_REQUEST' (status=1)
Thu Nov 29 11:31:26 2007 PUSH: Received control message: 'PUSH_REPLY,route 10.10.10.0 255.255.255.0,route 10.30.10.1,ifconfig 10.30.10.6 10.30.10.5'
Thu Nov 29 11:31:26 2007 OPTIONS IMPORT: --ifconfig/up options modified
Thu Nov 29 11:31:26 2007 OPTIONS IMPORT: route options modified
Thu Nov 29 11:31:26 2007 TAP-WIN32 device [Connexion au réseau local 5] opened: \\.\Global\{B7CBC82D-A66F-4DFF-91C7-F4AD861578B5}.tap
Thu Nov 29 11:31:26 2007 TAP-Win32 Driver Version 8.4
Thu Nov 29 11:31:26 2007 TAP-Win32 MTU=1500
Thu Nov 29 11:31:26 2007 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.30.10.6/255.255.255.252 on interface {B7CBC82D-A66F-4DFF-91C7-F4AD861578B5} [DHCP-serv: 10.30.10.5, lease-time: 31536000]
Thu Nov 29 11:31:26 2007 Successful ARP Flush on interface [29] {B7CBC82D-A66F-4DFF-91C7-F4AD861578B5}
Thu Nov 29 11:31:28 2007 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Thu Nov 29 11:31:28 2007 Route: Waiting for TUN/TAP interface to come up...
Thu Nov 29 11:31:30 2007 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Thu Nov 29 11:31:30 2007 Route: Waiting for TUN/TAP interface to come up...
Thu Nov 29 11:31:31 2007 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Thu Nov 29 11:31:31 2007 Route: Waiting for TUN/TAP interface to come up...
Thu Nov 29 11:31:32 2007 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Thu Nov 29 11:31:32 2007 Route: Waiting for TUN/TAP interface to come up...
Thu Nov 29 11:31:33 2007 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Thu Nov 29 11:31:33 2007 Route: Waiting for TUN/TAP interface to come up...
Thu Nov 29 11:31:34 2007 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Thu Nov 29 11:31:34 2007 Route: Waiting for TUN/TAP interface to come up...
Thu Nov 29 11:31:35 2007 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Thu Nov 29 11:31:35 2007 Route: Waiting for TUN/TAP interface to come up...
Thu Nov 29 11:31:36 2007 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Thu Nov 29 11:31:36 2007 Route: Waiting for TUN/TAP interface to come up...
Thu Nov 29 11:31:37 2007 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
Thu Nov 29 11:31:37 2007 route ADD 10.10.10.0 MASK 255.255.255.0 10.30.10.5
OK!
Thu Nov 29 11:31:37 2007 route ADD 10.30.10.1 MASK 255.255.255.255 10.30.10.5
OK!
Thu Nov 29 11:31:37 2007 Initialization Sequence Completed
Thu Nov 29 11:32:13 2007 TCP/UDP: Closing socket
Thu Nov 29 11:32:13 2007 route DELETE 10.30.10.1 MASK 255.255.255.255 10.30.10.5
OK!
Thu Nov 29 11:32:13 2007 route DELETE 10.10.10.0 MASK 255.255.255.0 10.30.10.5
OK!
Thu Nov 29 11:32:13 2007 Closing TUN/TAP interface
Thu Nov 29 11:32:13 2007 SIGTERM[hard,] received, process exiting

Voilà la situation.....

Si cela parle à quelqu'un et que vous voyez un semblant de réponse, je suis preneur pour un peu d'aide.

Merci beaucoup.

[jdh]

Bonsoir,

On peut imaginer que le serveur (10.10.10.100) ne connait pas la route vers 10.30.10.x (addresses attribuées aux clients OpenVPN.

Au choix ajout d'une route directement sur le serveur (et tous PC ayant besoin d'être accédés), ajout d'une route au niveau du routeur par défaut (qui n'est pas l'IPCOP).

[yakety]

J'ai trouvé après avoir beaucoup cherché......

Il suffit de faire d'IPCOP le serveur DHCP............Et on a ensuite accès à totu ce qui se trouve derriere et dont l'adresse est fournie pas IPCOP

[staples]

Salut Yakety,

merci de nous faire partagé la solution

Pense à mettre dans le sujet [Résolu], ça permet de voir que la solution a été trouvé.

A+

[jdh]

Bien sur, passer les PC en DHCP sur l'IPCOP revient à ce qu'il y ait seulement IPCOP en passerelle et, partant, OpenVPN va fonctionner. Mais alors quid de l'ancienne passerelle par défaut ?

J'avais compris que les 2 passerelles demeuraient ... (et alors la question des routes est claire).

[yakety]

En fait la solution actelle n'ait que transitoire pour que personne n'ait de deconnexion jusqu'à reconfiguration de tous les postes avec OpenVPN. De cette façon, les clients ayant l'ancienne confiuration peuvent continuer à se conencter par la liaison SDSL, et les PC reconfigurés se connectent via la Livebox.

Dès que tout le monde aura l'installation d'OpenVPN, je passe IPCOP sur la SDSL et vire la ligne Orange

La ligne SDSL sera la seule a subsister à terme.

Je ne mets pas résolu car ça me dérange que toutes les machines soient en DHCP..... J'aurai souhaité laissé le serveur qui est DC en IP Fixe...........

Donc, pour l'instant, je me contente de cela, mais si quelqu'un sait comment faire en sorte que je puisse accéder à mon DC qui serait en IP FIXE et non fournie par le DHCP (même si je lui alloue toujorus la même IP)

Je dirai que pour l'instant, c'est résolu à 50% pour moi.....

[DWAM2]

Salut

le problème est résolu ! JDH a clairement indiqué quel est le problème : le choix de la route en présence de 2 passerelles.

Maintenant il te reste à configurer convenablement ton système en fonction, même (et à plus forte raison) pour une phase transitoire...

- Tu peux remettre ton DC en ip fixe à condition de modifier sa table de routage
- Tu peux configurer ton DHCP sur le DC pour qu'il informe correctement ses clients de la passerelle par défaut et des routes supplémentaires dispos.

Encore faut-il le faire ! ;o)

Guillaume

[yakety]

Ok, je tenterai...

Masi avant de tout remodifier, je souhaiterai savoir pourquoi, en utilisant le même adressage (10.10.10.x) j'arrive à accéder avec une connexion OpenVPN à ce qui est derrière IPCOP lorsque ce dernier est serveur DHCP et non lorsque le DC est serveur DHCP....

Parce que pour les routes, je comprends bien pour les requetes des utilisateurs vers l'extérieur, mais lorsqu'il s'agit de requets en sens inverse (à savoir : depuis IPCOP vers l'intérieur du réseau puisque finalement, lorsque je suis connecté en VPN, les infos rentrent sur le réseau depuis IPCOP) je n'arrive à rien...

Maintenant, je trouve le DHCP d'IPCOP assez pratique, donc je pense continuer à l'utiliser, même par la suite.

Par contre, ça ne change pas que je ne sais toujours pas comment remettre mon DC en IPFixe (il a aujourd'hui l'IP en dure 10.10.10.100 mais donnée pas le DHCP d'IPCOP) et que je puisse continuer à y accéder depuis une session OpenVPN.

Du routage, ok....mais où ?????

[jdh]

Comme on peut l'observer, OpenVPN attribue une adresse ip 10.30.10.x au client.

Il est donc clair que l'IPCOP sait comment accéder à ces clients.

Un peu de réflexion !

Il faut donc avoir une route vers 10.30.10.x via l'IPCOP.

QED

[yakety]

Oui, mais si on regarde le log de connexion.... Cette route apparait bien, surtout que j'ai bien accès à l'interface 10.10.10.10....

Ce qui pose soucis, c'est tout ce qu'il y a derrière !

J'ai bien déjà un push de ce type du côté IPCop

[jdh]

Je ne parle pas de l'IPCOP (qui a FORCEMENT une route vers 10.30.10.x).

Je parle des autres PC .........