pfSense : accès distant sécurisé avec OpenVPN

📍 Guide principal : Réseau d’entreprise : MikroTik, pfSense, OPNsense, FortiGate
Ce tutoriel fait partie d’une série sur le cœur de réseau professionnel. Pour la vue d’ensemble, lisez d’abord le guide principal.

Le télétravail et les déplacements imposent un besoin précis : permettre à un employé, depuis n’importe quel point d’accès Internet, de joindre les ressources internes de l’entreprise comme s’il était au bureau, en toute confidentialité. C’est le rôle de l’accès distant, et OpenVPN sur pfSense en est une mise en œuvre robuste et gratuite. Dans ce tutoriel, vous allez configurer un serveur OpenVPN d’accès distant sur pfSense, créer un utilisateur, générer son profil de connexion et tester l’accès chiffré au réseau interne.

🎯 Ce que vous allez apprendre

• Distinguer le VPN d’accès distant (un utilisateur vers le réseau) du VPN site à site (deux réseaux entre eux).
• Mettre en place l’autorité de certification et le serveur OpenVPN via l’assistant pfSense.
• Créer un utilisateur et son certificat, puis exporter un profil de connexion prêt à l’emploi.
• Écrire la règle de pare-feu qui autorise le trafic du tunnel et tester la connexion.

🛠️ Ce que vous allez construire

À la fin, un utilisateur nomade pourra lancer un client OpenVPN sur son ordinateur portable, se connecter au pare-feu pfSense de l’entreprise par un tunnel chiffré, et accéder aux serveurs internes. Vous saurez ajouter, retirer et gérer ces accès distants de façon contrôlée.

Prérequis

• Une installation pfSense CE fonctionnelle (2.8.x) avec un accès Internet et une adresse publique joignable sur le WAN.
• Le paquet OpenVPN Client Export, installé depuis System → Package Manager, qui simplifie la génération des profils.
• Un client OpenVPN sur le poste distant (OpenVPN Connect ou OpenVPN GUI).
• Niveau : intermédiaire. Test express : si vous savez naviguer dans l’interface pfSense et installer un paquet, vous êtes prêt.
• ⏱️ Temps estimé : ~40 minutes.

Étape 1 — Comprendre l’accès distant face au site à site

Une clarification s’impose avant de configurer. Un VPN site à site relie deux réseaux entiers de façon permanente, comme deux agences. Un VPN d’accès distant connecte un utilisateur individuel et son seul appareil au réseau de l’entreprise, de manière ponctuelle. Les besoins diffèrent : l’accès distant exige une authentification par utilisateur, une gestion fine des droits et la possibilité de révoquer un accès si un portable est perdu.

OpenVPN excelle dans ce rôle pour une raison concrète : il peut s’encapsuler dans une connexion chiffrée sur le port 443, le même que la navigation web sécurisée. Cela lui permet de fonctionner depuis des réseaux très restrictifs — hôtels, aéroports, points d’accès publics — où d’autres protocoles VPN seraient bloqués. C’est ce qui en fait le couteau suisse de l’accès nomade.

Étape 2 — Créer l’autorité de certification

OpenVPN sur pfSense s’appuie sur des certificats pour authentifier le serveur et les utilisateurs. Il faut donc d’abord une autorité de certification (CA) qui signera ces certificats. Rendez-vous dans System → Certificate Manager → CAs et créez une nouvelle autorité de méthode « Create an internal Certificate Authority ».

Renseignez un nom descriptif, par exemple VPN-CA, une longueur de clé d’au moins 2048 bits, et les champs d’identité (pays, organisation). Cette autorité reste interne à pfSense ; elle est la racine de confiance de tout votre dispositif VPN. Une fois créée, elle apparaît dans la liste : c’est la pierre angulaire sur laquelle tout le reste s’appuie. Ne la supprimez jamais tant que des certificats en dépendent.

Étape 3 — Lancer l’assistant OpenVPN

pfSense fournit un assistant dédié qui automatise la création du serveur. Allez dans VPN → OpenVPN → Wizards. À la première question sur le type d’authentification, choisissez « Local User Access » pour gérer les comptes directement dans pfSense. Sélectionnez ensuite l’autorité de certification créée à l’étape précédente, puis laissez l’assistant générer le certificat du serveur.

L’assistant demande les paramètres du serveur : l’interface d’écoute (le WAN), le protocole et le port. Pour maximiser la compatibilité depuis les réseaux restrictifs, on choisit souvent le protocole UDP sur un port standard ; si vous visez la traversée des pare-feu les plus stricts, TCP sur 443 est l’option la plus permissive. Définissez surtout le Tunnel Network — un sous-réseau réservé aux clients VPN, par exemple 10.8.0.0/24 — et le Local Network, c’est-à-dire le réseau interne que les clients pourront joindre, par exemple 192.168.1.0/24.

VPN → OpenVPN → Wizards
  Type:            Local User Access
  CA / Server cert: VPN-CA / généré par l'assistant
  Interface:       WAN
  Protocol/Port:   UDP / 1194 (ou TCP / 443 pour réseaux stricts)
  Tunnel Network:  10.8.0.0/24
  Local Network:   192.168.1.0/24

Le Tunnel Network est l’espace d’adressage attribué aux clients connectés ; le Local Network indique ce qu’ils ont le droit d’atteindre une fois dans le tunnel. À la fin de l’assistant, pfSense propose de créer automatiquement les règles de pare-feu nécessaires : acceptez, cela vous évitera des oublis.

Étape 4 — Créer un utilisateur et son certificat

Le serveur est prêt, il manque les comptes. Allez dans System → User Manager et ajoutez un utilisateur, par exemple jdupont, avec un mot de passe solide. Le point crucial : lors de la création, cochez l’option qui génère un certificat utilisateur signé par votre autorité VPN-CA. Ce certificat est l’identité numérique de l’utilisateur ; couplé à son mot de passe, il forme une authentification à deux éléments.

Une fois l’utilisateur créé avec son certificat, vous disposez de tout ce qu’il faut pour générer son profil de connexion. La gestion par utilisateur est ce qui distingue un accès distant professionnel d’un partage de secret unique : on peut révoquer le certificat d’un seul employé sans impacter les autres, par exemple si son ordinateur est volé.

Étape 5 — Exporter le profil de connexion

C’est ici que le paquet OpenVPN Client Export installé en prérequis prend tout son sens. Rendez-vous dans VPN → OpenVPN → Client Export. Vous y trouverez votre serveur et, en bas, la liste des utilisateurs disposant d’un certificat.

Pour l’utilisateur voulu, choisissez le format d’export adapté à son système. L’option « Inline Configurations » génère un fichier .ovpn unique embarquant le certificat de l’autorité, le certificat et la clé de l’utilisateur, ainsi que tous les paramètres du serveur. Ce fichier autonome se transmet à l’employé, qui l’importe dans son client OpenVPN.

VPN → OpenVPN → Client Export
  Utilisateur:  jdupont
  Format:       Inline Configurations (.ovpn)
  → Télécharger le fichier jdupont.ovpn

Transmettez ce fichier de façon sécurisée — jamais par un canal public, car il contient la clé privée de l’utilisateur. Sur son poste, l’employé importe le .ovpn dans OpenVPN Connect et lance la connexion en saisissant son mot de passe. Le tunnel s’établit, et son ordinateur reçoit une adresse dans le réseau 10.8.0.0/24.

Étape 6 — Vérifier l’accès et le pare-feu

Vérifions que tout fonctionne. Une fois l’utilisateur connecté, son statut apparaît dans Status → OpenVPN, avec son adresse de tunnel et le volume de données échangées. Depuis son poste, il doit pouvoir joindre une ressource interne.

# Depuis le poste distant connecté au VPN
ping 192.168.1.10        # un serveur interne

Si le ping aboutit, le tunnel achemine bien le trafic vers le réseau interne. Si la connexion s’établit mais que rien ne passe ensuite, le coupable est presque toujours une règle de pare-feu manquante. L’assistant en crée normalement deux : une sur le WAN autorisant le port OpenVPN, et une sur l’onglet OpenVPN autorisant le trafic des clients vers le réseau interne. Vérifiez-les dans Firewall → Rules, onglets WAN et OpenVPN.

En production, on resserre la règle de l’onglet OpenVPN pour n’autoriser que les services réellement nécessaires aux nomades, plutôt qu’un accès total au réseau interne. C’est l’application du moindre privilège : un accès distant ne doit pas ouvrir plus que ce dont l’utilisateur a besoin.

Gérer les accès dans la durée

Mettre en place un serveur OpenVPN est une chose ; le gérer proprement au fil des mois en est une autre, et c’est là que se joue la sécurité réelle. Le principe fondateur est qu’un accès distant n’est jamais permanent par nature : un employé part, un portable est volé, un prestataire termine sa mission. Le dispositif doit donc permettre de retirer un accès précis sans rien casser pour les autres. C’est exactement ce qu’offre le modèle par certificat individuel : chaque utilisateur possède son identité numérique propre, qu’on peut révoquer isolément.

La révocation passe par une liste de révocation de certificats, gérée dans le Certificate Manager de pfSense. Quand on ajoute un certificat à cette liste et qu’on l’associe au serveur OpenVPN, toute tentative de connexion avec ce certificat est refusée immédiatement. C’est radicalement plus sûr qu’un secret partagé entre plusieurs personnes, qu’il faudrait changer pour tout le monde dès qu’une seule quitte l’organisation. La règle d’or se résume ainsi : un utilisateur, un certificat, une révocation possible.

On complète cette hygiène par une revue périodique des comptes. Tous les quelques mois, on parcourt la liste des utilisateurs VPN et on désactive ceux qui n’ont plus lieu d’exister. Un compte d’accès distant oublié est une porte dérobée qui n’attend qu’un mot de passe faible pour devenir une brèche. La gestion du cycle de vie des accès vaut autant que leur création.

Choisir le bon modèle d’authentification

OpenVPN sur pfSense offre plusieurs niveaux d’authentification, et bien les comprendre permet d’ajuster la sécurité au contexte. Le plus simple repose sur le seul certificat : la possession du fichier suffit à se connecter. C’est commode mais fragile, car un fichier volé donne un accès. On renforce en exigeant en plus un mot de passe propre à l’utilisateur, ce qui combine quelque chose qu’on possède (le certificat) et quelque chose qu’on sait (le mot de passe).

Pour les environnements les plus exigeants, on ajoute un troisième facteur via un code à usage unique généré par une application d’authentification. pfSense sait s’interfacer avec ce type de mécanisme, transformant l’accès distant en authentification forte. Le bon niveau dépend de la sensibilité des ressources exposées : un accès à des serveurs critiques justifie l’authentification à plusieurs facteurs, là où un usage interne limité peut se contenter du certificat plus mot de passe. L’essentiel est de faire ce choix consciemment, plutôt que de retenir le réglage par défaut sans l’interroger.

🐞 Pièges fréquents

✅ Récapitulatif

Vous avez déployé un serveur OpenVPN d’accès distant sur pfSense : création de l’autorité de certification, configuration du serveur par l’assistant, gestion d’un utilisateur avec son certificat, export d’un profil de connexion autonome, puis vérification de l’accès chiffré au réseau interne. Vous savez désormais offrir aux employés nomades un accès sûr et contrôlé, et surtout gérer ces accès individuellement — l’élément qui distingue un dispositif professionnel d’un bricolage. Couplé à la segmentation et au filtrage vus précédemment, cet accès distant complète un cœur de réseau d’entreprise cohérent.

🧾 Aide-mémoire

💪 À vous de jouer

Configurez le serveur pour pousser automatiquement le serveur DNS interne aux clients, afin qu’ils résolvent les noms de machines de l’entreprise une fois connectés.

Tutoriels de la même série

• Installer et configurer pfSense — le socle sur lequel repose ce serveur VPN.
• FortiGate : VPN IPsec site à site — relier des réseaux entiers plutôt que des utilisateurs.

Pour aller plus loin

• 🔝 Retour au guide principal : Réseau d’entreprise : MikroTik, pfSense, OPNsense, FortiGate
• Documentation officielle : docs.netgate.com, section « OpenVPN ».
• Aboutissement de la série : combiner segmentation, détection d’intrusion et VPN en une architecture complète.

FAQ

OpenVPN ou WireGuard pour l’accès distant ?
WireGuard est plus rapide, mais OpenVPN reste imbattable pour traverser les réseaux très restrictifs grâce à son encapsulation sur le port 443. Pour des employés qui se connectent depuis des lieux variés et parfois bridés, OpenVPN offre la meilleure compatibilité.

Comment révoquer l’accès d’un employé ?
On révoque son certificat dans le Certificate Manager de pfSense et on l’ajoute à la liste de révocation associée au serveur. Sa prochaine tentative de connexion sera refusée, sans affecter les autres utilisateurs.

Faut-il un mot de passe en plus du certificat ?
C’est recommandé. Le certificat prouve la possession de l’appareil autorisé, le mot de passe prouve l’identité de la personne. La combinaison des deux constitue une authentification nettement plus solide qu’un seul facteur.

Le paquet Client Export est-il indispensable ?
Non, mais il simplifie énormément la vie en générant un profil autonome prêt à l’emploi. Sans lui, il faudrait assembler manuellement les certificats et la configuration, opération fastidieuse et source d’erreurs.

Mots-clés : pfSense OpenVPN, accès distant, VPN nomade, autorité de certification, Client Export, profil ovpn, télétravail sécurisé, tunnel chiffré.