[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




  • @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 ?



  • @chris4916:

    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.



  • @chris4916:

    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                    30

    Effectivement je n'avais pas spécifié le push route, bonne remarque.
    Même symptôme.



  • @Risen:

    Oui oui elle y est bien:
    10.10.10.0          255.255.255.0            10.0.0.5            10.0.0.6                    30

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



  • 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 ?



  • @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 ?



  • 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



  • 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 2

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



  • @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



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