[Résolu] Connection Timeout avec OpenVPN Connect Mobile Client sur pfSense 2.4.3

jdh

Puisque la solution n'est pas trouvée, je vais la donner ...

Le 'INLINE FILE SUPPORT' est arrivé tard dans OpenVPN mais doit nécessairement respecter un syntaxe simple et très logique : les fichiers inclus sont à la fin ! Autrement dit, en début de fichier la config OpenVPN standard, puis les différents fichiers inclus entre leur tag respectifs <tag> ... </tag>.

Or vous avez une ligne qui fait partie de la config et qui est après un premier fichier !

Ce n'était que ça ! Beh oui (avant que ce soit testé)

Le lien vers 'OpenVPN 2 Cookbook' donne la bonne syntaxe : https://www.packtpub.com/mapt/book/networking_and_servers/9781849510103/12/ch12lvl1sec114/inline-certificates

Ce fil est la démonstration que

les nouveaux (et les autres !) DOIVENT utiliser le formulaire (quand bien même toutes les rubriques ne sont pas justifiées ou utiles)
entamer un fil sur OpenVPN sans fournir ni log ni config n'est juste pas acceptable

En outre, un fil ne devrait pas avoir été initié sans que

une recherche préalable DOIT être effectuée : sur le forum, dans la doc, et sur le web, et elle SOIT mentionnée dans le formulaire
la vérification et re-vérification du paramétrage, des logs DOIT avoir été faite

Enfin il est souhaitable que

ceux qui se donnent la peine de répondre ne soit pas systématiquement caricaturé ou rabroué
ceux qui posent des questions ne se sentent pas agressés dès qu'on n'est pas de leur avis ou qu'on leur indique les insuffisances de leur question !

Je ne suis pas mécontent d'avoir ici décrit la juste situation actuelle du forum français.

Les mots clés sont

VTPA et RVTPA : Vérifie Ton Paramétrage d'Abord et Re-Vérifie Ton Paramétrage d'Abord
LLDA : Lis La Doc d'Abord
RDLFA : Recherches Dans Le Forum d'Abord
FDIU et RLF : Fournis Des Informations Utiles et Remplis Le Formulaire

Merci Tatave de ta juste intervention de répondeur actif ... (déjà 10 ans sur le forum !)

pHoEnIxFuRy

En imaginant que j'ai bien compris vos explications, j'ai donc remonté la ligne "key-direction 1" au dessus des fichiers inclus soit juste en dessous de "remote-cert-tls server".

Malheureusement ça ne fonctionne pas.

J'ajouterai aussi que dans mon ancienne config mobile qui était fonctionnelle sur l'ancien serveur, "key-direction 1" se trouvait même en toute fin après les fichiers inclus sans que cela pose problème.

Merci en tout cas et je continue de chercher.

Autre piste, j'ai lancé le VPN par erreur avec une connexion WiFi sur le même réseau local que le serveur et là ça fonctionne étrangement.

Tatave

salut salut

sauf erreur de ma part cela ne devrait pas. il doit y avoir d'autre erreur, ce comportement de vpn m'intrigue

cordialement.

jdh

D'abord, il faut avoir la config avant les fichiers inline, ça c'est certain.
Ensuite, il faut un verb 2 ou 3 pour voir le même volume de logs.
Ensuite du côté PC, je vois un pkcs12 contre un cert côté Smartphone. Or un cert devrait avoir un key !
Comme vous n'utiliser que la protection par mot de passe, le reste est identique, donc pourquoi un pkcs12 et de l'autre cert + key.

Qui dit essai, dit vérification des logs

Il y a plus méthodique à faire ... prenez le temps de faire des tests précis et vérifiés ...

La même config doit fonctionner sur PC et Smartphone ...

pHoEnIxFuRy

J'utilise ce que fourni Client Export Utility (oui je sais ce n'est pas l'idéal).

Dans le cas du client PC, Client Export Utility fournit directement un package d'installation qui contient un fichier .ovpn, un .p12 et un .key.

Dans le cas du client mobile avec OpenVPN Connect (iOS/Android), la configuration est fournie au format inline et donc sans fichier annexe mais avec le <ca>, <cert>, <key> et <tls-auth> intégré.

Je referai des tests demain en épluchant les logs.

J'ai encore une autre piste que j'avais suivi sans succès en imaginant le problème lié à la nouvelle version côté serveur.

Client Export Utility précise ceci depuis la nouvelle version :
"Servers configured with features that require OpenVPN 2.4 will not work with OpenVPN 2.3.x or older clients. These features include: AEAD encryption such as AES-GCM, TLS Encryption+Authentication, ECDH, LZ4 Compression and other non-legacy compression choices, IPv6 DNS servers, and more."

A priori vu mon paramétrage, je ne suis pas concerné mais je me trompe peut-être.

Tatave

salut salut

bonne résolution de reprendre a tete reposer le probleme

ce qui fonctionne d'un coté
élément de listece qui ne fonctionne pas
élément de listequelles sont les différences

et se documenter ^^

pHoEnIxFuRy

Bon j'ai tenté des configs clients dans tous les sens en suivant les divers conseils mais je finissais toujours en "tls-error".

J'ai vu a plusieurs reprises lors de mes recherches le paramétrage se faire en TCP au lieu de l'UDP (chacun ayant ses avantages et inconvénients).

J'ai donc essayé à tout hazard de changer pour TCP :

Changement de la config OpenVPN Server
Changement de la config OpenVPN Client
Changement de la règle de pare-feu

J'injecte la nouvelle config dans le smartphone et je lance un test sans grande conviction :

Aug 23 14:51:14	openvpn	16389	TCP connection established with [AF_INET]XXX.XXX.XXX.XXX:60574
Aug 23 14:51:14	openvpn	16389	XXX.XXX.XXX.XXX:60574 TLS: Initial packet from [AF_INET]XXX.XXX.XXX.XXX:60574, sid=bd9e7587 bc03a3b8
Aug 23 14:51:14	openvpn	16389	XXX.XXX.XXX.XXX:60574 VERIFY SCRIPT OK: depth=1, C=FR, ST=IDF, L=XXX, O=XXX, emailAddress=XXX@XXX.XXX, CN=XXX, OU=IR
Aug 23 14:51:14	openvpn	16389	XXX.XXX.XXX.XXX:60574 VERIFY OK: depth=1, C=FR, ST=IDF, L=XXX, O=XXX, emailAddress=XXX@XXX.XXX, CN=XXX, OU=IR
Aug 23 14:51:14	openvpn	16389	XXX.XXX.XXX.XXX:60574 VERIFY SCRIPT OK: depth=0, C=FR, ST=IDF, L=XXX, O=XXX, emailAddress=XXX@XXX.XXX, CN=Yannick
Aug 23 14:51:14	openvpn	16389	XXX.XXX.XXX.XXX:60574 VERIFY OK: depth=0, C=FR, ST=IDF, L=XXX, O=XXX, emailAddress=XXX@XXX.XXX, CN=Yannick
Aug 23 14:51:14	openvpn	16389	XXX.XXX.XXX.XXX:60574 peer info: IV_GUI_VER=net.openvpn.connect.ios_1.2.9-0
Aug 23 14:51:14	openvpn	16389	XXX.XXX.XXX.XXX:60574 peer info: IV_VER=3.2
Aug 23 14:51:14	openvpn	16389	XXX.XXX.XXX.XXX:60574 peer info: IV_PLAT=ios
Aug 23 14:51:14	openvpn	16389	XXX.XXX.XXX.XXX:60574 peer info: IV_NCP=2
Aug 23 14:51:14	openvpn	16389	XXX.XXX.XXX.XXX:60574 peer info: IV_TCPNL=1
Aug 23 14:51:14	openvpn	16389	XXX.XXX.XXX.XXX:60574 peer info: IV_PROTO=2
Aug 23 14:51:14	openvpn		user 'Yannick' authenticated
Aug 23 14:51:14	openvpn	16389	XXX.XXX.XXX.XXX:60574 TLS: Username/Password authentication succeeded for username 'Yannick' [CN SET]
Aug 23 14:51:14	openvpn	16389	XXX.XXX.XXX.XXX:60574 Outgoing Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
Aug 23 14:51:14	openvpn	16389	XXX.XXX.XXX.XXX:60574 Outgoing Data Channel: Using 256 bit message hash 'SHA256' for HMAC authentication
Aug 23 14:51:14	openvpn	16389	XXX.XXX.XXX.XXX:60574 Incoming Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
Aug 23 14:51:14	openvpn	16389	XXX.XXX.XXX.XXX:60574 Incoming Data Channel: Using 256 bit message hash 'SHA256' for HMAC authentication
Aug 23 14:51:15	openvpn	16389	XXX.XXX.XXX.XXX:60574 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Aug 23 14:51:15	openvpn	16389	XXX.XXX.XXX.XXX:60574 [Yannick] Peer Connection Initiated with [AF_INET]XXX.XXX.XXX.XXX:60574
Aug 23 14:51:15	openvpn	16389	Yannick/XXX.XXX.XXX.XXX:60574 MULTI_sva: pool returned IPv4=192.168.95.2, IPv6=(Not enabled)
Aug 23 14:51:15	openvpn	16389	Yannick/XXX.XXX.XXX.XXX:60574 OPTIONS IMPORT: reading client specific options from: /tmp/openvpn_cc_423abbb4fef29ebc298bf79513f5c7d5.tmp
Aug 23 14:51:15	openvpn	16389	Yannick/XXX.XXX.XXX.XXX:60574 MULTI: Learn: 192.168.95.2 -> Yannick/XXX.XXX.XXX.XXX:60574
Aug 23 14:51:15	openvpn	16389	Yannick/XXX.XXX.XXX.XXX:60574 MULTI: primary virtual IP for Yannick/XXX.XXX.XXX.XXX:60574: 192.168.95.2
Aug 23 14:51:15	openvpn	16389	Yannick/XXX.XXX.XXX.XXX:60574 PUSH: Received control message: 'PUSH_REQUEST'
Aug 23 14:51:15	openvpn	16389	Yannick/XXX.XXX.XXX.XXX:60574 SENT CONTROL [Yannick]: 'PUSH_REPLY,dhcp-option DNS 10.99.1.99,redirect-gateway def1,route-gateway 192.168.95.1,topology subnet,ping 10,ping-restart 60,ifconfig 192.168.95.2 255.255.255.0,peer-id 0' (status=1)

Je ne sais pas pourquoi mais ça fonctionne !

J'ai essayé de revenir sur l'UDP pour valider que ça ne venait pas d'ailleurs mais rien à faire ça ne veut pas en UDP.

Voilà merci pour le coup de main malgré les prises de bec !

awebster

@pHoEnIxFuRy, la raison la plus probable que cela marche pas en UDP est fréquemment relié à l'une des deux choses suivantes:

La longueur du certificat client ou serveur dépasse 1472 octets;
Il y a un élément dans le réseau entre ton serveur et ton Smartphone qui bloque les paquets UDP fragmentés, ou plus précisément les paquets ICMP indiquant que la fragmentation est nécessaire, et donc par conséquent toute donnée UDP dépassant 1472 octets. En utilisant plutôt TCP la fragmentation est gérée automatiquement par le protocole, mais en générale, en bout de ligne, c'est moins efficace.

Tu peux essayer les éléments suivants dans la config client pour voir si en réduisant la taille des paquets ça aide. 1200 c'est drastique mais c'est un essai avant tout, si ça marche tu peux essayer des valeurs plus élevées.

mssfix 1200
tun-mtu 1200

Je suggère aussi de faire une recherche sur OpenVPN et MTU.