2FA VPN MikroTik : la configuration complète par script

Ce guide vous fait passer d’un VPN MikroTik ordinaire à un VPN où chaque connexion doit être approuvée d’un tap dans l’application Notakey Authenticator, en n’utilisant rien d’autre que le scripting RouterOS. Cette configuration ne comporte aucun serveur RADIUS, aucun proxy d’authentification et rien à déployer dans votre réseau au-delà du routeur dont vous disposez déjà.

Tous les scripts proviennent du dépôt officiel notakey/mikrotik-2fa-vpn.

Comment ça marche

Comprendre le déroulement rend chacune des étapes ci-dessous évidente :

L’utilisateur se connecte au VPN et s’authentifie avec son nom d’utilisateur et son mot de passe comme d’habitude. La session PPP s’établit, mais le pare-feu bloque aussitôt tout son trafic, car son adresse atterrit dans une liste d’adresses vpn_pending.
Le script « up » du profil PPP se déclenche. Il appelle votre Notakey Authentication Server, qui envoie une demande d’approbation sur le téléphone de l’utilisateur : “Log in as <user> from <caller IP>?”
Si l’utilisateur approuve avant l’expiration du délai (60 secondes), le script retire son adresse de vpn_pending : le blocage du pare-feu se lève et le trafic passe.
Si l’utilisateur refuse ou si la demande expire, le script met fin à la session PPP. Le mot de passe seul n’a jamais suffi.

Prérequis

RouterOS 6.46.4 ou version ultérieure (les scripts fonctionnent aussi sous RouterOS 7.x).
Un VPN basé sur PPP opérationnel sur le routeur (L2TP/IPsec, PPTP ou SSTP), auquel les utilisateurs peuvent déjà se connecter avec un nom d’utilisateur et un mot de passe.
Un Notakey Authentication Server joignable depuis le routeur. L’offre cloud gratuite sur signup.notakey.com suffit (6 premiers utilisateurs gratuits), ou déployez l’appliance sur site (10 premiers utilisateurs gratuits).
Un téléphone iOS ou Android équipé de l’application Notakey Authenticator.

Étape 1 – Préparez le côté Notakey

Dans votre tableau de bord Notakey, créez une application (service) pour le VPN : donnez-lui un nom reconnaissable, par exemple “Office VPN” ; c’est ce nom que les utilisateurs verront sur leur téléphone.
Copiez l’Access ID de l’application (un UUID) ; vous le collerez dans le script du routeur à l’étape 4.
Créez l’utilisateur (ou connectez votre source d’utilisateurs) et configurez un prérequis d’enrôlement, puis enrôlez le téléphone : installez Notakey Authenticator, ajoutez votre service et menez l’enrôlement à son terme.

Le nom d’utilisateur dans Notakey doit correspondre exactement au nom d’utilisateur du VPN : le script du routeur utilise le nom d’utilisateur PPP pour adresser la notification push. john sur le routeur et john.doe dans Notakey échoueront silencieusement.

Étape 2 – Installez la bibliothèque JParseFunctions

Les scripts RouterOS ne savent pas analyser le JSON nativement ; cette bibliothèque (issue du projet mikrotik-json-parser) comble ce manque.

Dans WinBox ou WebFig, ouvrez System → Scripts, créez un script nommé exactement JParseFunctions, laissez les cases de politique à leurs valeurs par défaut (aucun privilège particulier n’est requis) et collez-y l’intégralité du contenu du fichier JParseFunctions de ce projet.

Étape 3 – Installez la bibliothèque NotakeyFunctions

Même procédure : créez un second script nommé exactement NotakeyFunctions et collez-y le contenu de NotakeyFunctions.lua du dépôt Notakey. C’est le client qui dialogue avec l’API Notakey : il crée la requête d’authentification et interroge régulièrement le serveur pour obtenir la réponse de l’utilisateur.

Les noms des scripts sont importants : le script de profil de l’étape suivante charge les deux bibliothèques par leur nom.

Étape 4 – Associez les scripts up/down à un profil PPP

Ouvrez le profil PPP de votre VPN (PPP → Profiles), ou créez-en un dédié pour que la 2FA ne s’applique qu’à certains utilisateurs pendant vos tests.

Dans l’onglet General, réglez Address List sur vpn_pending. Chaque nouvelle connexion utilisant ce profil voit désormais son adresse ajoutée à cette liste dès l’établissement de la session.
Dans l’onglet Scripts, collez le script On Up ci-dessous (issu de PppProfileScript.lua) dans le champ On Up, en modifiant deux valeurs selon votre environnement : ntkHost, le nom d’hôte de votre serveur Notakey (sans https://), et ntkAccessId, l’Access ID de l’application que vous avez copié à l’étape 1.

{
    :local localAddr $"local-address";
    :local remoteAddr $"remote-address";
    :local callerId $"caller-id";
    :local calledId $"called-id";

    :log info "$user (srcIp=$callerId, dstIp=$calledId) connected: was given $remoteAddr IP (GW $localAddr)";

    /system script run "JParseFunctions";
    :global JSONUnload;

    /system script run "NotakeyFunctions";
    :global NtkAuthRequest;
    :global NtkWaitFor;
    :global NtkUnload;

    # Change values below to match your Notakey installation
    :local ntkHost "demo.notakey.com";
    :local ntkAccessId "12345645-b32b-4788-a00d-251cd7dc9a03";

    # Custom message in authentication request
    :local authDescMsg "Log in as $user from $callerId\?";

    :local ntkAuthUuid ([$NtkAuthRequest host=$ntkHost accessId=$ntkAccessId authUser=$user authTitle="VPN connection" authDesc=$authDescMsg authTtl=60]);

    :if ([$NtkWaitFor uuid=$ntkAuthUuid host=$ntkHost accessId=$ntkAccessId]) do={
        # Remove blocking rule after successful 2FA authentication
        /ip firewall address-list remove [/ip firewall address-list find where list=vpn_pending address=$remoteAddr]
    } else={
        :log info "VPN 2FA authentication failure for user $user from IP $callerId";
        # Disconnect active session with this IP and user
        /ppp active remove [/ppp active find name="$user" address="$remoteAddr"]
    }

    $NtkUnload
    $JSONUnload
}

Le script On Down du même fichier se contente de journaliser la déconnexion : collez-le dans le champ On Down pour des journaux propres, ou ignorez-le.

Le délai d’approbation (authTtl) est de 60 secondes : assez long pour sortir un téléphone de sa poche, assez court pour qu’une connexion bloquée ne maintienne pas indéfiniment une session à demi ouverte.

Étape 5 – Ajoutez les règles de pare-feu

C’est la règle de rejet (drop) qui donne réellement du sens à la liste d’attente :

/ip firewall filter
add chain=forward src-address-list=vpn_pending action=drop \
    comment="Block VPN clients pending 2FA approval"

Placez-la au-dessus de vos règles générales d’autorisation du VPN afin qu’elle prime tant que l’approbation est en attente. Si les clients VPN doivent aussi être empêchés d’atteindre le routeur lui-même, reproduisez la règle dans la chaîne input.

Un cas particulier : si l’approbation a lieu sur le même appareil que celui qui établit la connexion VPN (le téléphone est lui-même le client VPN), le trafic d’approbation doit pouvoir atteindre le serveur Notakey alors que tout le reste est encore bloqué. Ajoutez une règle d’acceptation au-dessus de la règle de rejet :

/ip firewall filter
add chain=forward src-address-list=vpn_pending dst-address=<notakey-server-ip> \
    action=accept comment="Let pending clients reach Notakey for approval"

(L’approbation depuis un second appareil, le téléphone approuvant pendant qu’un ordinateur portable établit la connexion, ne nécessite aucune règle supplémentaire : le routeur interroge lui-même l’API Notakey, et son propre trafic n’est pas soumis à la chaîne forward.)

Étape 6 – Attribuez le profil et testez

Faites pointer votre utilisateur VPN (PPP → Secrets) vers le profil de l’étape 4, puis connectez-vous au VPN depuis un client :

Le tunnel s’établit, mais rien n’est routé : vous êtes dans vpn_pending.
En une ou deux secondes, la notification push arrive sur le téléphone.
Approuvez → le trafic commence à circuler. Refusez ou ignorez → la session est coupée à l’expiration du délai.

Suivez le déroulement dans Log (les scripts journalisent chaque requête et son résultat) et dans IP → Firewall → Address Lists, où l’adresse du client apparaît dans vpn_pending puis disparaît à l’approbation.

Dépannage

Aucune push n’arrive : presque toujours un nom d’utilisateur qui diffère entre PPP Secrets et le service Notakey, ou un téléphone jamais enrôlé pour cette application précise.
La push arrive mais vous ne pouvez pas l’approuver : vous approuvez probablement depuis le même appareil que celui qui établit la connexion VPN, et la règle de rejet de la liste d’attente bloque le trafic d’approbation. Ajoutez la règle d’acceptation de l’étape 5, ou approuvez depuis un appareil qui n’est pas dans le tunnel.
Le texte de la requête est illisible ou la requête échoue : la bibliothèque d’analyse JSON ne gère pas les parenthèses (et peut-être d’autres signes de ponctuation particuliers) dans le message d’authentification. Gardez un texte de message simple.
Fonctionne pour un utilisateur mais pas pour un autre : vérifiez l’attribution du profil du second utilisateur ; seuls les secrets pointant vers le profil 2FA bénéficient du traitement.

Où cela s’inscrit

Cette approche par script est la voie la plus rapide vers la 2FA d’un VPN MikroTik et ne demande aucune infrastructure supplémentaire. Si vous la dépassez par la suite (nombreux routeurs, autres fournisseurs de VPN ou politique centralisée), le même serveur Notakey prend en charge une configuration basée sur RADIUS où un proxy d’authentification gère le flux d’approbation à la place des scripts du routeur.

2FA VPN MikroTik : la configuration complète par script