🔐 OpenVPN Remote Access Lab — pfSense

Architecture OpenVPN pfSense

Sommaire

Description

Ce lab documente la mise en place complète d’un VPN d’accès à distance utilisant OpenVPN sur pfSense. Il couvre l’intégralité de la chaîne : création d’une autorité de certification interne (root-CA), émission d’un certificat serveur et d’un certificat client, configuration du serveur OpenVPN via le Wizard pfSense, export du profil client, et quelques tests de validation par capture réseau Wireshark.

⚠️ Contrairement à un VPN site-à-site où il aurait fallu mettre en place au moins deux pfSense, le présent scénario met en lumière un utilisateur mobile se connectant à un serveur distant typiquement le réseau d’entreprise (télétravailleur / télétravailleuse). on peut modéliser la connexion comme suit utilisateur ↔ serveur . Par ailleurs, pfSense endossera la fonction de serveur d’authentififaction (local user authentication) bien qu’il soit tout à fait possible d’utiliser LDAP/Radius. Ce choix se justifie par une gestion plus simple au travers de la section User manager du GUI aussi, le test sera effectué avec un seul utilisateur (user).


🏗️ Architecture

Remote access openvpn architecture

Il s’agit ici de l’environnement du lab dans son entièreté incluant un acteur malveillant.


🧰 Stack technique

ComposantDétail
Firewall/VPN GatewaypfSense Community Edition
Protocole VPNOpenVPN
AuthentificationLocal User Access (pfSense User Manager)
PKIRoot-CA interne pfSense
Algorithme de cléRSA 2048 bits
DigestSHA-256
Chiffrement donnéesAES-256-GCM / AES-128-GCM / CHACHA20-POLY1305
Chiffrement fallbackAES-256-CBC
Échange de clésDiffie-Hellman 2048 bits
Authentification TLSClé TLS partagée (auto-générée)
Client OSKali Linux (OpenVPN CLI)
Analyse réseauWireshark

📋 Étapes de configuration

1. Création de l’autorité de certification

System → Certificates → Authorities → Add

ChampValeur
Descriptive NameRoot-CA
MethodCreate an internal Certificate Authority
Randomize Serial✅ Activé
Key TypeRSA
Key Length2048 bits (minimum recommandé)
Digest AlgorithmSHA256
Lifetime3650 jours (10 ans)
Common NameRoot-CA

💡 RSA 2048 est de facto la longueur de clé la plus utilisée par les CA. SHA-256 est considéré comme assez robuste face aux attaques du type arc-en-ciel (ou plus simplement collision).

Configuration de l’autorité de certification
Configuration de l’autorité de certification


2. Création du certificat serveur

System → Certificates → Certificates → Add

ChampValeur
MethodCreate an internal Certificate
Descriptive NameAuthority-server
Certificate AuthorityRoot-CA
Key TypeRSA 2048
Digest AlgorithmSHA256
Lifetime≤ 398 jours ⚠️
Certificate TypeServer (pas Client !)
Common NameAuthority-server

⚠️ La durée de vie du certificat serveur ne doit pas dépasser 398 jours — au-delà, certains clients TLS le rejettent.

configuration du certificat serveur
configuration du certificat serveur


3. Configuration du serveur VPN via Wizard

VPN → OpenVPN → Wizards Du fait que nous venons de créer la CA et le serveur, certaines étapes sont sautés par pfSense.

Étape 1/11 — Authentication Backend

  • Type of Server : Local User Access

configuration du certificat serveur

Étape 5/11 — Certificate Authority

  • Sélectionner Root-CA

configuration du certificat serveur

Étape 7/11 — Server Certificate

  • Sélectionner Authority-server

configuration du certificat serveur

Étape 9/11 — Server Setup

ChampValeur
DescriptionRemote workers from home
ProtocolUDP on IPv4 only
InterfaceWAN
Local Port1194
TLS Authentication✅ Activé
Generate TLS Key✅ Auto-généré
DH Parameters Length2048 bits
Data EncryptionAES-256-GCM, AES-128-GCM, CHACHA20-POLY1305
IPv4 Tunnel Network10.0.8.0/24
IPv4 Local Network192.168.110.0/24
Allow CompressionRefuse (Most Secure)
DNS Default Domaingoogle.com (exemple)
DNS Server 18.8.8.8

configuration du certificat serveur
configuration du certificat serveur
configuration du certificat serveur
configuration du certificat serveur
configuration du certificat serveur

Étape 10/11 — Firewall Rules

  • ✅ Firewall Rule (Traffic from clients to server)
  • ✅ OpenVPN rule (Traffic from clients through VPN)

💡 Par défaut pfSense applique un default block. Or les deux précédentes règles sont indispensables pour que le trafic VPN passe, il faut donc qu’ils soient explicitement mentionnées. On peut constater que les utilisateurs autorisés à se connecter n’ont pas été explicitement identifiés ce qui pourrait constituer une surface d’attaque potentielle. En production, affiner la règle WAN dans Firewall → Rules → WAN pour restreindre les IPs sources autorisées.

configuration du certificat serveur
configuration du certificat serveur


4. Création de l’utilisateur et du certificat client

System → User Manager → Users → Add

ChampValeur
Usernameedi (exemple)
Password(mot de passe fort)
Certificate✅ Cocher pour créer
Certificate NameIdentique au Username
Certificate AuthorityRoot-CA
Key TypeRSA 2048
Digest AlgorithmSHA256

configuration du certificat serveur
configuration du certificat serveur
configuration du certificat serveur


5. Export du profil client

VPN → OpenVPN → Export Client

  1. Installer le package OpenVPN Client Export via System → Package Manager
  2. Dans Client Connection Behavior → Bind Mode : Use a random local source port (permet des clients concurrents)
  3. Cliquer Save as default
  4. Dans OpenVPN Clients → colonne Export → télécharger Most Clients (.ovpn)

configuration du certificat serveur
configuration du certificat serveur
configuration du certificat serveur


6. Connexion depuis le client Linux

# Installation du client OpenVPN
sudo apt update && sudo apt install openvpn

# Connexion avec le profil exporté
sudo openvpn --config /chemin/vers/pfSense-UDP4-1194-edi-config.ovpn
# → Enter Auth Username: edi
# → Enter Auth Password: ****

Indicateur de succès :

InitializationSequenceCompleted

configuration du certificat serveur

⚠️ Vérifier que la règle Block Private Networks (l’interface WAN de pfSense) n’empeche pas l’établissement de la connexion avec le serveur.


🔬 Validation — Wireshark

Test 1 : Sniff sur l’interface tunnel tun0

Capture effectuée à l’intérieur du tunnel depuis l’interface virtuelle tun0 du client. À ce niveau, OpenVPN a déjà déchiffré les paquets — on observe donc le trafic applicatif en clair (HTTP, TCP…). C’est un comportement attendu et normal : les adresses source appartiennent au subnet 10.0.8.0/24, ce qui confirme l’attribution d’adresse tunnel et le bon fonctionnement du routage vers le LAN.

configuration du certificat serveur

Test 2 : Sniff sur l’interface WAN de pfSense

Capture effectuée côté WAN, avant déchiffrement. Tout le trafic apparaît en OpenVPN P_DATA_V2 — le contenu est illisible, ce qui confirme que l’encapsulation OpenVPN fonctionne.

configuration du certificat serveur
Voir l’analyse détaillée → docs/wireshark-analysis.md


📁 Structure du repo

openvRcddspEoiocnAnacr-DfgserMicra/wteReEglarirnEm.simcrosAom/esheuhDtdn/isboMetthltE--eaes.accrsmcotkhdcnu-oefraosientsg.ai--mlnledygaxs.baim/msdp.lmed.ovpn

⚠️ Avertissement

Ce lab est réalisé dans un environnement virtualisé isolé à des fins éducatives. Les configurations présentées (règles de pare-feu larges, mots de passe de test) ne doivent pas être reproduites en production sans durcissement approprié.


📎 Ressources