Jan 10

MiKroTik, VPN IPsec pour client nomade

MAJ :

Le passage en version 6.39 a apporté son lot de modifications :

Plusieurs onglets sont maintenant disponibles

L’activation de NAT-T doit se faire via ligne de commande suite à la disparition de la case à cocher …

Support de IKEv2 (les utilisateurs de windows seront contents)

 

Les points de configuration présentés dans l’article restent valables.

 

Au menu du jour :

Création d’un tunnel VPN IPsec via le logiciel Shrew entre un client windows et notre routeur MiKro Tik. Nous serons donc en mode Tunnel, mode conf, authentification par certificat (à savoir qu’à qqls différences, l’authentification par clefs partagées est identique).

 

Nous allons pour cela utiliser les certificats créés dans cet article pour une authentification mutuelle.

 

Voici un schéma de notre affaire :

Nous allons traiter deux cas de figure en parallèle, avec et sans NAT.

Le but du jeux est bien entendu que les clients accèdent aux ressources du Rasp dans le Lan 192.168.0.0/24.

 

Dans un premier temps nous créons un pool d’adresses IP

Une adresse IP de ce pool VPN sera donc attribuée aux clients.

Passons maintenant aux propositions IPsec

 

Protocoles utilisés pour la phase 2 de ISAKMP

Ceci n’est qu’un exemple de propositions, vous pouvez mixer comme bon vous semble. Attention tout de même au groupe DH qui est limité à 16 (autrement erreur sur le client Shrew)

Les paramètres de configuration pour les clients :

On retrouve ici une référence au pool d’adresses créé un peu plus tôt.

Pour pouvoir accéder aux ressources de notre Lan mais dans un même temps surfer sur le Net, nous configurons le « split« . Il définit le trafic qui transitera via le tunnel, le reste prenant un chemin « standard ».

 

Dans l’onglet Group on créer un groupe nommé IPsec

 

On peut alors configurer les policies.

Il y en a deux (une dans chaque sens) et elles reprennent des éléments configurés plus tôt :

On trouve ici :

  • L’adresse source du trafic (notre Lan) vers l’adresse de destination (notre pool VPN)
  • Cette police est un template qui va créer des règles dynamiques.
  • Nous utilisons le Group IPsec créé précédemment
  • Nous utilisons le Proposal IPsec_Proposal créé plus tôt également
  • Nous sommes en mode tunnel (donc esp)
  • SA Src et SA Dst sont laissées à 0.0.0.0. En effet, nous ne connaissons pas les adresses IP publiques qui seront utilisées lors de la connexion.

 

La deuxième règle est similaire, seule les adresses Src et Dst sont inversées.

Au moment d’écrire l’aticle, je ne suis pas complètement certain que les deux règles soient nécessaires.

 

Nous terminons avec la négociation des paramètres de connexion :

  • On utilise une méthode d’authentification mutuelle via certificats
  • On spécifie le certificat utilisé pour le serveur. Le distant est laissé à none : le certificat client sera validé grâce au CA.
  • Policy Template Group reprend les polices créées plus tôt

Client1 (derrière une box) utilisera cette règle pour se connecter grâce au NAT-T. On copiera les mêmes éléments sans NAT-T pour client2.

  • Comme précédemment les différents protocoles de chiffrement sont laissés à votre choix. Idem, DH limité à 16. Attention à bien reprendre le Mode Config IPsec_Conf.
  • Ici DPD est configuré à 15s, il peut être préférable d’augmenter la valeur pour ne pas surcharger le réseau.
Dernier élément à configurer : le Pare-feu !

Deux règles en Input qui vont autoriser les flux UDP sur les ports 500 et 1500 :

 

Configuration du client Shrew

 

Disponible ici (dans un ou deux jours ….)

 

 

 

 

 

Lien Permanent pour cet article : http://rsocisco.fr/microtik-vpn-ipsec-pour-client-nomade/

(6 commentaires)

Passer au formulaire de commentaire

  1. Ahaa, its fastidious dialogue concerning this piece
    of writing at this place at this webpage, I have read all that, so at this
    time me also commenting here.

    Also visit my weblog: root canal (en.gravatar.com) https://en.gravatar.com/barrysmeithg

    1. Lol « fastidious » !!! I’ve tried to do it as short as possible !
      Anyway, thanks for your comment as it is the first one on the entire site

    • Edouard ERNOULD on 3 avril 2017 at 17 h 14 min
    • Répondre

    Bonjour,
    je viens de tomber sur votre article, très clair et mis en place.
    Je rencontre par contre un souci.

    État des lieu : le tunnel est bien créé et je récupère une adresse IP conforme aux paramètres.
    le réseau à rejoindre : 192.168.1.0/24
    l’adresse IP distribué : 192.168.10.1

    Par contre, impossible de pinger quoique ce soit dans les deux sens. Histoire de route, je ne sais pas, je ne suis pas très compétent en réseau 🙁

    Cordialement
    Edouard

    1. Bonjour,
      Obtenir une @IP via le DHCP du routeur signifierait que la négociation des 2 phases d’ ISAKMP se déroule bien.
      Vous pourriez avoir un problème au niveau de la configuration du split ou des polices :
      192.168.1/24 -> 192.168.10.0/24
      192.168.10.0/24->192.168.1.0/24
      Utilisez vous le logiciel Shrew pour vous connecter ? Si oui, utilisez l’outil VPN Trace Utility à partir duquel vous aurez accès aux logs détaillés.

        • Edouard ERNOULD on 4 avril 2017 at 6 h 50 min
        • Répondre

        Bonjour,
        merci pour votre réponse et… vous aviez raison 🙂

        C’était l’adresse du split qui n’était pas bonne, j’avais raté le /24 (Faut que je mette des lunettes)

        Dans tous les cas merci beaucoup.

        Cordialement.

        1. Bonjour,
          je vous en prie !

          Bonne continuation

Laisser un commentaire

Your email address will not be published.