Discussion :

[Damlouf]

Bonjour à toutes et à tous,

Je suis actuellement confronté à un problème avec OpenVPN et sa configuration. Voila mon infra réseau pour commencer :

Infra réseau :



Explications :

Le client OpenVPN est un routeur DLINK DSR 150N et le serveur OpenVPN est un pc sous Windows. Pour les besoins de l'entreprise, la configuration doit resté comme telle même si c'est une configuration compliquée et non traditionnelle.


Configuration du serveur OpenVPN :

port 1194
proto udp
dev tun
ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"
cert "C:\\Program Files\\OpenVPN\\config\\serveur.crt"
key "C:\\Program Files\\OpenVPN\\config\\serveur.key"
dh "C:\\Program Files\\OpenVPN\\config\\dh1024.pem"
server 192.168.5.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"
push "route 192.168.0.0 255.255.255.0"
client-config-dir ccd
route 192.168.10.0 255.255.255.0
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
ifconfig-pool-persist ipp.txt
#client-to-client
keepalive 10 120
;tls-auth ta.key 0 # This file is secret
cipher BF-CBC # Blowfish (default)
;comp-lzo
;max-clients 100
;user nobody
;group nobody
persist-key
persist-tun
status openvpn-status.log
;log openvpn.log
;log-append openvpn.log
verb 5
mute 20


Configuration du client OpenVPN :





Le serveur OpenVPN se met correctement en place mais lorsque le client se connecte voila ce qu'il se passe :

Mon Apr 18 16:21:36 2016 MANAGEMENT: >STATE:1460989296,CONNECTED,SUCCESS,192.168.5.1,
Mon Apr 18 16:21:43 2016 MULTI: multi_create_instance called
Mon Apr 18 16:21:43 2016 A.B.C.D:1194 Re-using SSL/TLS context
Mon Apr 18 16:21:43 2016 A.B.C.D:1194 Control Channel MTU parms [ L:1541 D:1212 EF:38 EB:0 ET:0 EL:3 ]
Mon Apr 18 16:21:43 2016 A.B.C.D:1194 Data Channel MTU parms [ L:1541 D:1450 EF:41 EB:12 ET:0 EL:3 ]
Mon Apr 18 16:21:43 2016 A.B.C.D:1194 Local Options String: 'V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Mon Apr 18 16:21:43 2016 A.B.C.D:1194 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Mon Apr 18 16:21:43 2016 A.B.C.D:1194 Local Options hash (VER=V4): '239669a8'
Mon Apr 18 16:21:43 2016 A.B.C.D:1194 Expected Remote Options hash (VER=V4): '3514370b'
Mon Apr 18 16:21:43 2016 A.B.C.D:1194 TLS: Initial packet from [AF_INET]A.B.C.D:1194, sid=a46f3109 706f333b
Mon Apr 18 16:21:45 2016 A.B.C.D:1194 TLS: new session incoming connection from [AF_INET]82.127.101.53:1194
Mon Apr 18 16:21:46 2016 A.B.C.D:1194 TLS: new session incoming connection from [AF_INET]82.127.101.53:1194
Mon Apr 18 16:21:48 2016 A.B.C.D:1194 VERIFY OK: depth=1, C=FR, ST=BDR, L=SaintMartinDeCrau, O=TafInterim, OU=TafInfo, CN=TafInterim, name=TafInterim, emailAddress=contact@taf-interim.fr
Mon Apr 18 16:21:48 2016 A.B.C.D:1194 VERIFY OK: depth=0, C=FR, ST=BDR, L=SaintMartinDeCrau, O=TafInterim, OU=TafInfo, CN=smc, name=TafInterim, emailAddress=contact@taf-interim.fr
Mon Apr 18 16:21:48 2016 A.B.C.D:1194 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Apr 18 16:21:48 2016 A.B.C.D:1194 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Apr 18 16:21:48 2016 A.B.C.D:1194 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Apr 18 16:21:48 2016 A.B.C.D:1194 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Apr 18 16:21:48 2016 A.B.C.D:1194 TLS: move_session: dest=TM_ACTIVE src=TM_UNTRUSTED reinit_src=1
Mon Apr 18 16:21:48 2016 A.B.C.D:1194 TLS: tls_multi_process: untrusted session promoted to semi-trusted
Mon Apr 18 16:21:48 2016 A.B.C.D:1194 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Mon Apr 18 16:21:48 2016 A.B.C.D:1194 [smc] Peer Connection Initiated with [AF_INET]A.B.C.D:1194
Mon Apr 18 16:21:48 2016 smc/A.B.C.D1194 MULTI_sva: pool returned IPv4=192.168.5.10, IPv6=(Not enabled)
Mon Apr 18 16:21:48 2016 smc/A.B.C.D:1194 MULTI: Learn: 192.168.5.10 -> smc/A.B.C.D:1194
Mon Apr 18 16:21:48 2016 smc/A.B.C.D:1194 MULTI: primary virtual IP for smc/A.B.C.D:1194: 192.168.5.10
Mon Apr 18 16:21:50 2016 smc/A.B.C.D:1194 PUSH: Received control message: 'PUSH_REQUEST'
Mon Apr 18 16:21:50 2016 smc/A.B.C.D:1194 send_push_reply(): safe_cap=940
Mon Apr 18 16:21:50 2016 smc/A.B.C.D:1194 SENT CONTROL [smc]: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,route 192.168.0.0 255.255.255.0,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,route 192.168.5.1,topology net30,ping 10,ping-restart 120,ifconfig 192.168.5.10 192.168.5.9' (status=1)
Mon Apr 18 16:22:15 2016 smc/A.B.C.D:1194 MULTI: bad source address from client [192.168.1.45], packet dropped
Mon Apr 18 16:22:52 2016 smc/A.B.C.D:1194 MULTI: bad source address from client [192.168.10.3], packet dropped
Mon Apr 18 16:22:52 2016 smc/A.B.C.D:1194 MULTI: bad source address from client [192.168.10.3], packet dropped
Mon Apr 18 16:22:55 2016 smc/A.B.C.D:1194 MULTI: bad source address from client [192.168.10.3], packet dropped
Mon Apr 18 16:22:55 2016 smc/A.B.C.D:1194 MULTI: bad source address from client [192.168.10.3], packet dropped
Mon Apr 18 16:23:00 2016 smc/A.B.C.D:1194 MULTI: bad source address from client [192.168.1.45], packet dropped
Mon Apr 18 16:23:00 2016 smc/A.B.C.D:1194 MULTI: bad source address from client [192.168.10.3], packet dropped
Mon Apr 18 16:23:01 2016 smc/A.B.C.D:1194 MULTI: bad source address from client [192.168.10.3], packet dropped
Mon Apr 18 16:23:46 2016 smc/A.B.C.D:1194 MULTI: bad source address from client [192.168.1.45], packet dropped
Mon Apr 18 16:23:56 2016 smc/A.B.C.D:1194 MULTI: bad source address from client [192.168.10.3], packet dropped
Mon Apr 18 16:23:56 2016 smc/A.B.C.D:1194 MULTI: bad source address from client [192.168.10.3], packet dropped
Mon Apr 18 16:24:05 2016 smc/A.B.C.D:1194 MULTI: bad source address from client [192.168.10.3], packet dropped
Mon Apr 18 16:24:30 2016 smc/A.B.C.D:1194 MULTI: bad source address from client [192.168.1.45], packet dropped

Le problème est connu et il y a beaucoup de forum ou ce problème est traité et résolu mais je n'arrive toujours pas à le résoudre pour ma part, même en appliquant à la lettre les conseils de certains..

D’après OpenVPN et plusieurs forums, cela viendrait du fait qu'OpenVPN n'aurait pas de route pour ces adresse et le problème se résoudrait grâce à client-config-dir cdd..

J'ai donc rajouter la ligne :
client-config-dir ccd
route 192.168.10.0 255.255.255.0

Ainsi que le fichier C:\Program Files\OpenVPN\config\cdd\smc.txt qui contient :

iroute 192.168.10.0 255.255.255.0

Mais le message d'erreur s'affiche toujours..

En ce qui concerne les deux Livebox, elle route bien les paquets OpenVPN utilisant le proto udp et port 1194 vers les routeurs VPN.

En ce qui concenre les deux VPN, le VPN de gauche (192.168.1.45) a comme règle Firewall :



Et celui de droite (192.168.1.33) :



Merci d'avance pour votre aide !

Thomas.

[razmous]

Salut,

Comme tu l'as dis, l'infra est peut être compliquée pour peut être pas grande chose ;-)

Voilà ce qui est sur le site d'OpenVPN, j'espère que tu es bon en anglais ;-)

"MULTI: bad source address from client , packet dropped" or "GET INST BY VIRT: [failed]"?
These errors occur because OpenVPN doesn't have an internal route for 192.168.100.249. Consequently, it doesn't know how to route the packet to this machine, so it drops the packet.
Use client-config-dir and create a ccd file for your client containing the iroute option to tell OpenVPN that the 192.168.100.0/24 network is available behind this client.
"MULTI: bad source address from client [192.168.100.249], packet dropped" or "GET INST BY VIRT: 192.168.100.249 [failed]"?

En gros c'est les fichiers CCD -> si tu l'as fait ...

https://community.openvpn.net/openvpn/wiki/NatHack
De préférence il faut router et ne pas utiliser du NAT ...

A ta place (ou de l'entreprise), j'irai dans cette direction :
- Je monterai un VPN site to site entre les deux WAN (peut être c'est le cas) dans lequel tu déclares les réseaux LAN des deux côtés,
- Puis si les besoins de sécurités l'exige, je monterai un autre entre VPN site-to-site qui passe via le premier, ça fait de l'overhead mais c'est plus sécurisant dans le sens où toute la communication à travers Internet est sécurisé par défaut ... et tu n'as pas à jouer avec du NAT au milieu de VPN ... après ça reste mon point de vue

revérifie les tables de routages, puis si cela ne suffit pas un coup de wireshark ...

NB Sur les logs d'OpenVPN tu as laissé l'IP publique ;-)

Bon courage

[Damlouf]

Bonjour,

J'ai réalisé une infra plus simple en supprimant toutes les contraintes lié a l'infra lourde et cela marche.. Pourquoi faire compliqué quand on peut faire simple

Je n'ai donc pas réussi à résoudre le problème de ce message d'erreur mais en effet la solution serait donc de spécifier l'adresse dans le fichier OpenVPN serveur avec un client-config-dir.

Merci quand même pour votre aide !

[scoody]

Bonjour,

j'ai exactement la même erreur, la même "infra".

"MULTI: bad source address from client" packet dropped avec le Dlink en client OpenVPN

le fichier ccd ne corrige pas l'erreur.

Qu'appelles tu "simplifier l'infra" ?