Vous cherchez à sécuriser le WiFi invité de votre PME au Maroc avec du matériel MikroTik ? Ce guide 2026 vous explique comment déployer un captive portal professionnel sur RouterOS, quels pièges éviter (six écueils que vous ne trouverez pas dans la documentation officielle), et combien coûte réellement une mise en production. Nous nous appuyons sur un cas client concret — l’infrastructure Shadhavar-Guest déployée à Rabat — pour rendre chaque étape actionnable.

Pourquoi un vrai captive portal (et pas juste un mot de passe WiFi)

Un mot de passe WPA2 partagé sur votre SSID guest ne suffit plus en 2026. Voici les quatre raisons pour lesquelles les PME marocaines investissent dans un vrai captive portal :

• Loi 09-08 sur la protection des données personnelles — un simple mot de passe ne trace pas qui s’est connecté, quand, ni depuis quel appareil. En cas d’incident (attaque, harcèlement, piratage), l’entreprise doit pouvoir fournir des logs.
• Obligation de conserver les logs de connexion — les fournisseurs d’accès marocains doivent le faire, mais un WiFi ouvert dans vos locaux vous met dans une zone grise réglementaire.
• Isolation du réseau de production — un invité connecté à votre WiFi ne doit jamais pouvoir atteindre votre NAS interne, votre serveur ERP ou vos caméras IP. Un portail captif force le passage par une politique de segmentation.
• Traçabilité marketing — nom, téléphone, email récoltés à l’inscription permettent un CRM léger (à intégrer avec Zoho par exemple).

Architecture cible : ce qu’on veut construire

Le pattern standard pour une PME marocaine (10 à 200 collaborateurs) tient sur trois briques :

• Un routeur MikroTik qui héberge le hotspot RouterOS — RB951, hAP ac3, ou CCR selon le débit — plus le SSID guest physiquement isolé du LAN prod.
• Un serveur portail léger — une VM ou un container Docker qui expose la page HTML de connexion, gère la base de données des invités validés, et pilote le MikroTik via son API REST.
• Une politique de firewall stricte — le subnet guest ne parle qu’à internet (après auth) et au serveur portail (pré-auth pour afficher le formulaire).

Chez Shadhavar-Guest, nous avons choisi RouterBoard RB951Ui-2HnD pour le hotspot (600 MHz MIPS, largement suffisant pour 50 utilisateurs simultanés) + une petite VM Ubuntu Docker sur ESXi pour héberger le container captive-portal en PHP-SQLite. Coût matériel total : moins de 1 500 MAD hors serveur mutualisé.

Configuration RouterOS : les étapes clés

La configuration du hotspot MikroTik se fait via l’assistant /ip hotspot setup, mais il y a plusieurs paramètres critiques que l’assistant ne configure pas correctement pour un usage professionnel. Voici les commandes CLI essentielles :

1. Créer le bridge et l’interface WiFi guest

/interface bridge add name=bridge-guest
/interface wireless set wlan-guest ssid="shadhavar-guest" security-profile=open
/interface bridge port add bridge=bridge-guest interface=wlan-guest
/ip address add address=192.168.34.1/24 interface=bridge-guest

2. DHCP server sur bridge-guest

/ip pool add name=guest-pool ranges=192.168.34.100-192.168.34.240
/ip dhcp-server add name=guest-dhcp interface=bridge-guest address-pool=guest-pool
/ip dhcp-server network add address=192.168.34.0/24 gateway=192.168.34.1 dns-server=192.168.34.1

3. Activer le hotspot

/ip hotspot profile add name=guest-profile hotspot-address=192.168.34.1 dns-name=guest.shadhavar.local html-directory=hotspot login-by=mac,http-chap,http-pap http-cookie-lifetime=0s
/ip hotspot add name=hotspot-guest interface=bridge-guest profile=guest-profile disabled=no

4. Walled-garden : autoriser l’accès au serveur portail sans authentification

/ip hotspot walled-garden ip add dst-address=192.168.11.53 action=accept comment="Portal server"

Cette règle permet à l’invité non-authentifié d’atteindre le serveur qui héberge le formulaire d’inscription. Sans elle, le navigateur de l’utilisateur ne pourra jamais charger le portail.

Les six pièges qui vous font perdre des jours (et qu’on ne trouve pas dans la doc)

Voici les six écueils que nous avons rencontrés en déployant Shadhavar-Guest, et qui ne figurent pas dans la documentation officielle de RouterOS.

Piège 1 · Le fasttrack qui bypasse totalement votre firewall

Par défaut, RouterOS active fasttrack-connection sur les flux established. Résultat : quand un invité s’est authentifié une fois, ses futurs paquets contournent la chaîne hs-unauth. S’il change de contexte (session expirée, révocation admin), il reste connecté à Internet pendant des minutes voire des heures. Solution : exclure explicitement l’interface guest du fasttrack.

/ip firewall filter set [find action=fasttrack-connection] in-interface=!bridge-guest
/ip firewall filter set [find action=accept comment~"established"] in-interface=!bridge-guest

Piège 2 · Le QUIC (UDP 443) qui échappe à l’interception HTTP

Le hotspot RouterOS n’intercepte que TCP 80 et 443. Or, iOS et Android modernes utilisent QUIC (UDP 443) pour HTTPS. Résultat : Instagram, WhatsApp, YouTube fonctionnent sans authentification parce que leurs paquets QUIC passent tranquillement. Solution : ajouter une règle de drop explicite avant les chaînes hotspot.

/ip firewall filter add chain=forward action=drop in-interface=bridge-guest \
    src-address-list=!guest-authorized dst-address=!192.168.11.53 \
    comment="Bloque tout guest non-auth, y compris QUIC/UDP-443"

La liste guest-authorized se remplit automatiquement à l’authentification via un on-login script du user profile, et se vide à la révocation.

Piège 3 · La MAC-cookie qui rend la révocation impossible

Le mode mac-cookie dans login-by mémorise un cookie côté RouterOS pour reconnecter l’utilisateur automatiquement pendant 3 jours par défaut. Problème : quand un admin révoque un utilisateur, le cookie reste actif. L’utilisateur revient sur le WiFi, RouterOS le re-authentifie tout seul. Solution : désactiver mac-cookie et forcer un vrai passage par le portail.

/ip hotspot profile set guest-profile login-by=mac,http-chap,http-pap http-cookie-lifetime=0s

Notez qu’on garde mac (sans dash) qui est le mode d’auto-authentification à partir de la table /ip hotspot user — utile quand l’admin approuve un device et qu’on veut que le retour soit fluide.

Piège 4 · Le bug REST API sur html-directory

Ceci nous a coûté plusieurs heures : quand on modifie le profile via PATCH /rest/ip/hotspot/profile/*, RouterOS 7 re-préfixe automatiquement flash/ au champ html-directory. Résultat : après plusieurs modifications, le champ devient flash/flash/hotspot qui n’existe pas, et le hotspot sert le template MikroTik par défaut au lieu de votre portail custom. Solution : ne jamais toucher à ce champ via l’API REST. Utilisez SSH avec la valeur sans préfixe :

/ip hotspot profile set guest-profile html-directory=hotspot

Piège 5 · La DHCP option 114 pour ouvrir le portail automatiquement

iOS 14+ et Android 11+ supportent la RFC 7710 : la DHCP option 114 leur indique directement l’URL du portail captif, ce qui ouvre le popup Wi-Fi captif automatiquement dès que le device rejoint le WiFi. Sans elle, l’utilisateur doit ouvrir manuellement Safari ou Chrome pour déclencher le portail — ce qui est catastrophique en UX. Solution :

/ip dhcp-server option add code=114 name=captive-portal-uri value="'http://192.168.11.53/'"
/ip dhcp-server network set [find address=192.168.34.0/24] dhcp-option=captive-portal-uri

Piège 6 · Le walled-garden qui autorise trop

Ne jamais mettre captive.apple.com ni connectivitycheck.gstatic.com dans le walled-garden. Ces domaines sont utilisés par iOS et Android pour détecter qu’un captive portal est présent : si vous les autorisez, l’appareil obtient une réponse « OK » des vrais serveurs Apple/Google et conclut qu’il n’y a pas de captive portal — donc il n’ouvre jamais le popup d’inscription. Solution : le walled-garden ne contient que l’IP de votre serveur portail.

Le rôle du serveur portail : au-delà du simple HTML

Le serveur portail ne se contente pas d’afficher un formulaire. Chez Shadhavar-Guest, il héberge un container Docker léger (PHP 8.3 + SQLite en mode WAL) qui gère :

• Trois modes d’inscription : (a) token pré-généré fourni par l’hôte, (b) formulaire nom + téléphone + password avec validation admin, (c) accès rapide juste nom + téléphone (password auto-généré) pour les visites courtes.
• Une interface d’administration avec rôles multi-utilisateurs — admin full accès + approver (approbation queue uniquement). Utile quand la réception valide les demandes sans avoir accès aux configurations sensibles.
• Une API d’appel vers le RouterOS — quand l’admin approuve, le serveur crée un /ip hotspot user avec le MAC binding, ajoute l’IP à la guest-authorized address-list, et pilote la révocation en cascade (kick session + delete cookie + flush conntrack + remove address-list) pour couper Internet en moins d’une seconde.
• Une politique de bannissement — un utilisateur abusif se voit ajouté à la /interface wireless access-list avec authentication=no : son appareil est deauth’d et ne peut plus rejoindre le SSID.

Le tout tourne sur un container Docker de 200 Mo qui consomme moins de 100 Mo de RAM en production.

Isolation réseau : la couche de sécurité invisible

La règle d’or : un invité ne doit voir rien d’autre que son propre subnet et Internet. Chez Shadhavar, nous avons trois subnets internes distincts :

• 11.x — famille et infrastructure familiale (TV, NAS Plex, IoT domotique)
• 33.x — WiFi work + LAN filaire pour l’équipe
• 55.x — VMs sur ESXi (Docker-Station, Runner-Android, hypervisor management)
• 34.x — invités (le subnet dont on parle ici)

Le firewall CHR bloque explicitement chaque traversée non-autorisée. Un invité 34.x ne peut atteindre que 192.168.11.53 (portail) et Internet. Aucune fuite vers 11.x, 33.x, 55.x — pas même en ICMP. C’est cette rigueur qui permet à un dirigeant de PME de dormir tranquille en 2026.

Cas client Shadhavar-Guest : les chiffres

L’infrastructure captive portal Shadhavar-Guest est en production à Rabat depuis juillet 2026. Quelques données réelles :

• Débit : jusqu’à 50 connexions simultanées sur RB951, latence WiFi < 5 ms
• Uptime portail : 99.98% sur 30 jours (une seule interruption, planifiée)
• Temps moyen d’inscription invité : 45 secondes (formulaire quick access)
• Approbation admin : temps médian 12 secondes depuis mobile
• Faux positifs bannissement : 0 sur 200+ invités traités

Combien ça coûte, combien de temps ça prend

Pour une PME marocaine standard (30-100 collaborateurs, 2-4 points d’accès WiFi), la mise en production d’une solution comparable coûte :

• Matériel MikroTik : 800 MAD (RB951) à 4 500 MAD (hAP ac³ + switch CRS) selon la couverture
• Serveur portail : container Docker sur un serveur existant, ou VPS 4€/mois si aucune infra
• Prestation d’intégration : entre 2 et 5 jours de conseil (configuration RouterOS, personnalisation du portail, tests, formation admin) — soit 12 000 à 35 000 MAD selon le périmètre

Délai typique de mise en production : 10 jours ouvrés depuis la commande jusqu’à la mise en service, formation incluse.

Envie de déployer un captive portal MikroTik dans votre entreprise ?

Shadhavar est DSI externalisée au Maroc, en Arabie Saoudite et au Canada. Nous accompagnons plus de 180 PME sur l’intégration Zoho + MikroTik + gouvernance IT. Le captive portal décrit dans cet article est reproductible pour votre entreprise avec les adaptations propres à votre topologie réseau.

Demander un audit gratuit — nous analysons votre situation actuelle et proposons une architecture cible sous 48 heures.