[RESOLU] connexion openvpn ok mais…

Risen

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.8

Dé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

baalserv

Question à 2 Sesterces : Firewall soft sur le PC client ?

Risen

Négatif, FW Windows désactivé également pour lever le doute.

baalserv

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 ?

ccnet

@baalserv:

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 ?

Risen

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 server

Le 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

pfsense-udp-1194-test.txt

chris4916

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'

ccnet

Par ailleurs :

route-method exe
route-delay 2

Pour pouvoir appliquer les modifications de la table de routage dans Windows.

calamarz

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.

ccnet

Nouveau problème, nouveau post. Merci.

Risen

@calamarz:

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

chris4916

C'est une bonne nouvelle.
N'hésite pas à modifier le titre du premier message pour marquer le sujet comme [RESOLU] ;)