[RESOLU] connexion openvpn ok mais…
-
Bonjour,
Je rencontre un problème avec mon openVPN.
Lorsque je monte mon tunnel, celui-ci arrive bien à se connecter et monte bien.
Sur le client, l'écran de notification d'openVPN est gris, vire au jaune pendant la connexion et passe au vert une fois connecté.
Sur mon serveur pfSense, je vois bien la connexion de mon client. (la config semble être ok)Connexion ok.
Le problème est que je n'arrive pas à me connecter depuis ma machine cliente. Le ping vers pfSense ne passe pas (j'ai ajouté les règles nécessaires dans le firewall), et je n'arrive donc pas à accéder vers l'interface graphique de pfSense.Le client prend bien la configuration donnée par le pfsense.
Certainement un détail qui m'échappe, mais je n'arrive pas à voir ou ça coince, problème de routage ?
Une idée?
D'avance merci,
Risen
-
Lorsque je monte mon tunnel, celui-ci arrive bien à se connecter et monte bien.
Sur le client, l'écran de notification d'openVPN est gris, vire au jaune pendant la connexion et passe au vert une fois connecté.
Sur mon serveur pfSense, je vois bien la connexion de mon client. (la config semble être ok)Connexion ok.
Le problème est que je n'arrive pas à me connecter depuis ma machine cliente. Le ping vers pfSense ne passe pas (j'ai ajouté les règles nécessaires dans le firewall), et je n'arrive donc pas à accéder vers l'interface graphique de pfSense.Le client prend bien la configuration donnée par le pfsense.
Certainement un détail qui m'échappe, mais je n'arrive pas à voir ou ça coince, problème de routage ?
Peux-tu fournir une copie des routes coté client une fois la connexion établie ?
-
Peux-tu fournir une copie des routes coté client une fois la connexion établie ?
IPv4 Table de routage
Itinéraires actifs :
Destination réseau Masque réseau Adr. passerelle Adr. interface Métrique
0.0.0.0 0.0.0.0 192.168.43.1 192.168.43.171 25
10.0.0.1 255.255.255.255 10.0.0.5 10.0.0.6 30
10.0.0.4 255.255.255.252 On-link 10.0.0.6 286
10.0.0.6 255.255.255.255 On-link 10.0.0.6 286
10.0.0.7 255.255.255.255 On-link 10.0.0.6 286
10.10.10.0 255.255.255.0 10.0.0.5 10.0.0.6 30
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
192.168.43.0 255.255.255.0 On-link 192.168.43.171 281
192.168.43.171 255.255.255.255 On-link 192.168.43.171 281
192.168.43.255 255.255.255.255 On-link 192.168.43.171 281
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 192.168.43.171 281
224.0.0.0 240.0.0.0 On-link 10.0.0.6 286
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 192.168.43.171 281
255.255.255.255 255.255.255.255 On-link 10.0.0.6 286(Le ping vers les dns Google fonctionne)
-
Je ne vois pas (en regardant rapidement), de route vers le réseau distant.
Donc tu dois pouvoir joindre l'autre extrémité du tunnel (10.0.0.0/xx) mais la route par défaut passe toujours par ton réseau local.Il doit te manquer un push route sur ta conf serveur.
-
Je ne vois pas (en regardant rapidement), de route vers le réseau distant.
Donc tu dois pouvoir joindre l'autre extrémité du tunnel (10.0.0.0/xx) mais la route par défaut passe toujours par ton réseau local.Il doit te manquer un push route sur ta conf serveur.
Oui oui elle y est bien:
10.10.10.0 255.255.255.0 10.0.0.5 10.0.0.6 30Effectivement je n'avais pas spécifié le push route, bonne remarque.
Même symptôme. -
Oui oui elle y est bien:
10.10.10.0 255.255.255.0 10.0.0.5 10.0.0.6 30Effectivement je n'avais pas spécifié le push route, bonne remarque.
Même symptôme.Effectivement, je ne l'avais pas vue. En lisant en diagonal, j'ai pris ça pour une entrée du tunnel :-[
Du coup, si cette route existe bien, un push route n'est pas nécessaire.
Si tu fais un trace route vers le site distant, ça passe bien par le tunnel ?
As-tu vérifié les règles de FW coté OpenVPN ? -
Le trace route ne donne rien vers mon serveur pfSense, par contre ça passe bien vers les dns google.
C:\WINDOWS\system32>tracert 10.10.10.1
Détermination de l'itinéraire vers 10.10.10.1 avec un maximum de 30 sauts.
1 * * * Délai d'attente de la demande dépassé.
2 * * * Délai d'attente de la demande dépassé.
3 * * * Délai d'attente de la demande dépassé.
4 * ^C
C:\WINDOWS\system32>tracert 8.8.8.8Détermination de l'itinéraire vers google-public-dns-a.google.com [8.8.8.8]
avec un maximum de 30 sauts :1 3 ms 1 ms 1 ms 192.168.43.1
2 114 ms 82 ms 65 ms 10.100.246.13
3 72 ms 94 ms 89 ms ^C
C:\WINDOWS\system32>Concernant les régles du FW, je viens de les vérifier mais elles s'ajoutent automatiquement à la fin de l'assitant de création du serveur openVPN.
ID Proto Source Port Destination Port Gateway Queue Schedule Description
IPv4 * * * * * * none OpenVPN WAN OpenVPN Port UDP wizard -
Question à 2 Sesterces : Firewall soft sur le PC client ?
-
Négatif, FW Windows désactivé également pour lever le doute.
-
L'utilisation du formulaire en début de fil aurait éviter cette question et surement d'autres ^^
Quelles sont vos règles de FW sur l'interface Lan ?
-
L'utilisation du formulaire en début de fil aurait éviter cette question et surement d'autres ^^
Quelles sont vos règles de FW sur l'interface Lan ?
He oui … rien de nouveau. Hélas.
OS client et fichier de configuration client ?
Redirection forcée de tout le trafic via le tunnel lorsque celui-ci est actif ? -
Bonjour,
Lors de mes test, j'active la régle qui autorise tout le trafic vers mon FW, sinon il n'y a pas de règle qui bloque.
Lors de la création du serveur OpenVPN, les règles sont automatiquement créées et ajoutées au FW (si on laisse les 2 cases cochées à la fin du wizard)Voici la config client :
dev tun
persist-tun
persist-key
cipher AES-256-CBC
auth SHA1
tls-client
client
resolv-retry infinite
remote 175.143.125.177 1194 udp
lport 0
verify-x509-name "VPN_Cert" name
auth-user-pass
pkcs12 pfsense-udp-1194-test.p12
tls-auth pfsense-udp-1194-test-tls.key 1
ns-cert-type serverLe client est un Windows 10 (la connexion depuis un Windows 7 a été testé et montre le même résultat)
En PJ le fichier de log lors de la connexion.J'essaye depuis une machine Linux
-
Ta conf client est OK mais est-elle bien alignée avec celle du serveur ?
Tue Mar 01 11:16:23 2016 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1557', remote='link-mtu 1558'
Tue Mar 01 11:16:23 2016 WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo' -
Par ailleurs :
route-method exe
route-delay 2Pour pouvoir appliquer les modifications de la table de routage dans Windows.
-
Bonjour,
Je ne suis pas un spécialiste mais utilises-tu un Iphone en bridge ? Car j'ai un probleme identique avec les iphones (version IOS > 9) mais pas depuis des galets 4G ou des box ADSL.
-
Nouveau problème, nouveau post. Merci.
-
Bonjour,
Je ne suis pas un spécialiste mais utilises-tu un Iphone en bridge ? Car j'ai un probleme identique avec les iphones (version IOS > 9) mais pas depuis des galets 4G ou des box ADSL.
No, j'utilise un téléphone Android comme point d'accès.
Quelques nouvelles de l'avancement du problème…
Ayant vérifié les règles du FW et que tout semblait correct, j'ai mis celui ci hors de cause...
Il ne me restait donc pas beaucoup de possibilités: soit un problème de ma config serveur, soit un problème d'authentification (et donc user ou certif).
La config étant correcte, (vérifiée et comparée à de multiples reprises), j'ai jeté un coup d’œil à mes certificats.
Après avoir fait pleins de modifs, (FW, config serveur, création users...) j'ai préféré supprimer mes certificats/users et les recréer.
Et à ma grande surprise, je suis bien arrivé à me connecter.La cause du problème était (à mon avis) de mauvais paramètres serveur/user (pas le même algo de chiffrement entre le serveur et l'user (sha1/sha256) et pas la même taille de la clé (2048 et 4096 bits).
Je ne suis plus sur de mon ancienne config, mais c'est ce que j'en conclus.
Erreur très très bête....
En tout cas, mon tunnel est fonctionnel à présent,
Merci à tous pour votre aide.Risen
-
C'est une bonne nouvelle.
N'hésite pas à modifier le titre du premier message pour marquer le sujet comme [RESOLU] ;)