Documentation Technique :

Projet PFSENSE

Haissam Abdeldayem
Rapport d'Installation et de Configuration pfSense

1.​ Initialisation et Attribution des Interfaces

Au démarrage de la machine virtuelle sous VMware, la première étape a consisté à identifier
et assigner les cartes réseau physiques aux interfaces logiques du pare-feu. L'interface em0
a été désignée pour le réseau WAN, tandis que l'interface em1 a été configurée pour le
réseau local (LAN). Lors de cette phase, le WAN a été paramétré pour solliciter une adresse
via DHCP, ce qui lui a permis de récupérer l'adresse IP [Link] sur le segment
réseau de l'hyperviseur.

2.​ Configuration Statique du Réseau Local (LAN)

Une fois l'accès à l'interface de gestion Web établi, la configuration du LAN a été
personnalisée selon les exigences du laboratoire. L'interface a été fixée sur l'adresse IP
statique [Link] avec un masque de sous-réseau /24. Pour éviter tout conflit lors de la
validation, le type de configuration IPv6 a été positionné sur None, résolvant ainsi les erreurs
de suivi d'interface ("Track Interface") initialement rencontrées lors de l'enregistrement.
 3.​ Mise en place des Services Réseau
Pour assurer l'autonomie du réseau interne, deux services essentiels ont été activés. Le
serveur DHCP a été configuré pour distribuer automatiquement des adresses IP aux
machines clientes sur une plage allant de [Link] à [Link]. Parallèlement, le
service DNS Resolver a été activé et couplé à l'ajout manuel des serveurs DNS de Google
([Link]) et Cloudflare ([Link]) dans les paramètres généraux du système, garantissant
ainsi la résolution des noms de domaine pour tous les équipements connectés.

4.​ Paramétrage du Pare-feu et Sécurité

La gestion des flux a nécessité une attention particulière sur les deux interfaces. Sur le
WAN, les options de blocage des réseaux privés et "bogons" ont été décochées pour
permettre la communication avec l'hôte physique dans cet environnement de test. Sur le
LAN, les règles de filtrage ont été vérifiées pour s'assurer de la présence de la règle
Anti-Lockout, protégeant l'accès à l'administration, ainsi que des règles Default Allow,
autorisant le trafic IPv4 et IPv6 à sortir vers l'extérieur.

5.​ Validation et Tests de Connectivité

La phase finale a validé le bon fonctionnement de l'ensemble de la chaîne réseau. Des tests
de ping ont été effectués avec succès depuis la console pfSense et l'interface de diagnostic
vers l'adresse [Link], confirmant l'accès internet du routeur. Enfin, le raccordement de la
machine Client 1 sur le segment LAN a permis de confirmer la réception d'une adresse IP
par DHCP et la possibilité de naviguer sur l'interface de gestion, validant ainsi l'étanchéité et
l'efficacité de la configuration.

Test ping vers le client :

1 A. Mise en place de la segmentation (VLANs & Cartes réseau)

​ Pour ce projet, j'ai commencé par découper le réseau en trois zones bien distinctes
pour que tout ne soit pas mélangé. Le but, c'est que la Direction, les Employés et les
Invités soient chacun dans leur coin pour plus de sécurité. Côté matériel virtuel, j'ai
configuré 5 cartes réseau au total sur mon pfSense. C'est ce qui permet de séparer
physiquement (virtuellement) les flux sans qu'ils se croisent par erreur. J'ai utilisé les
segments LAN de VMware pour brancher chaque carte sur le bon réseau :
​ • Direction (VLAN 10) : Connecté sur l'interface ens38 du client (côté pfSense c'est
l'em2) avec le réseau [Link]/24.
​ • Employés (VLAN 20) : Sur le réseau [Link]/24.
​ • Invités (VLAN 99) : Sur le réseau [Link]/24.
B. Règles de filtrage (Firewall Rules)
​ Une fois les cartes branchées, il a fallu définir qui a le droit de parler à qui. Par
défaut, pfSense bloque tout, donc j'ai dû créer des règles de pare-feu pour chaque
interface :
​ • J'ai autorisé les clients à sortir vers le WAN pour qu'ils aient internet.
​ • J'ai permis aux clients de contacter le pfSense pour les services de base (DNS et
DHCP).
C. Validation par Test de Ping
​ Pour être sûr que ma segmentation et mes règles fonctionnent, j'ai fait des tests de
connectivité. • Ping Passerelle : Depuis mon client Debian, j'ai lancé un ping
[Link]. Ça répond direct, ce qui prouve que ma carte réseau est bien configurée
et que le pfSense me voit.
​
​ • Ping Inter-VLAN : J'ai aussi testé de pinger une machine d'un autre service. Si la
règle de blocage est active, ça ne doit pas passer, ce qui valide que l'isolation est
réelle.

2.​ Fixer les adresses IP

Plutôt que de passer sur chaque machine pour mettre une IP à la main, j'ai tout centralisé
sur le pfSense avec des baux statiques (Static Mappings). Le principe est simple, le serveur
reconnaît l'adresse MAC de la carte réseau et lui donne toujours la même IP. Le petit détail
important : pour respecter la "Règle d'Or", j'ai choisi des adresses au-dessus de .200
(comme [Link]). Comme ça, elles ne risquent pas de percuter les adresses
automatiques que le pfSense distribue normalement.
 3.​ Le DNS
Enfin, j'ai activé le DNS Resolver. C'est ce qui permet de faire un ping debian-direction au
lieu de taper l'IP. J'ai bien coché la case pour que pfSense enregistre tout seul les noms des
machines dès qu'il leur donne une IP statique. J'ai aussi testé les Host Overrides pour créer
des noms personnalisés comme [Link], et ça répond nickel au ping.
J’ai effectuer un ping comme vous pouvez le voir depuis mon client 1 (Vlan 10 ) au client 2
(Vlan 20) Sans taper aucune adresse ip seulement les hostnames
 1.​ Définition des objets Aliases
La première étape a consisté à centraliser la gestion des adresses IP via des Aliases. Cette
méthode permet de rendre les règles de pare-feu plus lisibles et d'en faciliter la maintenance
:
• Alias RESEAUX_INTERNES : Regroupement des plages d'adresses privées afin de
définir une base de blocage pour l'isolation des VLANs.
• Alias IP_EXT_AUTORISEES : Liste blanche contenant les adresses IP publiques
spécifiques autorisées à accéder aux ressources internes depuis le WAN.

VLAN 10 : Direction

C’est le réseau qui possède le plus de droits, mais il reste strictement encadré.
• Les règles en place : On autorise l'accès au serveur Web (VLAN 20), l'administration
complète du pfSense (port 443) et les requêtes DNS.
• Le but : Permettre aux cadres de piloter l'infrastructure et de consulter les outils internes.
La sécurité est assurée par la règle de blocage vers les autres réseaux privés située juste
avant l'ouverture vers Internet, garantissant que la Direction peut sortir sur le web sans pour
autant pouvoir "pinguer" inutilement les autres VLANs.
VLAN 20 : Employés & Serveurs web

Ce réseau est plus restrictif car il héberge des ressources sensibles comme le serveur
Apache.
• Les règles en place : On autorise uniquement les flux DNS et l'accès local au serveur Web.
• Le but : Les employés peuvent travailler sur le serveur web interne et naviguer sur Internet.
Cependant, toute tentative de connexion vers le VLAN Direction ou le VLAN Invités est
immédiatement bloquée. Le serveur est ainsi protégé dans une zone grise où seuls les ports
nécessaires sont ouverts.

VLAN 99 : Invités

C’est le niveau de sécurité le plus bas, conçu pour les visiteurs.

• Les règles en place : Une règle autorise le DNS, suivie d'une règle "Inverse Match" sur
l'alias des réseaux internes.
• Le but : On offre un accès Internet. L'invité peut aller sur le web pour ses besoins
personnels, mais il est techniquement impossible pour lui de voir ou de toucher à la moindre
machine de l'entreprise (Direction ou Serveurs). C'est une isolation totale par rapport au
reste de l'infrastructure.
Configuration du NAT et Validation du Service

1.​ Publication du serveur Web

Une fois les réseaux internes isolés, l'objectif était de rendre le serveur Apache accessible
depuis l'extérieur (le WAN), mais de manière strictement contrôlée. • Mise en place du NAT :
J'ai configuré une règle de redirection de port (Port Forward) sur l'interface WAN. Ce
mécanisme permet de faire le pont entre l'adresse publique du pare-feu et l'adresse privée
du serveur ([Link]). • Sécurisation par Alias : Pour ne pas exposer le serveur à
n'importe quel utilisateur, j'ai utilisé l'alias IP_EXT_AUTORISEES. Seules les machines dont
l'IP est listée ici peuvent franchir la barrière du NAT.

2.​ Origine de l'IP [Link] (Le rôle du poste physique)

Dans notre environnement de test, l'adresse [Link] joue un rôle crucial Il s'agit de
l'adresse de la carte réseau virtuelle de mon PC physique (hôte). Pour le pfSense, cette
adresse représente "l'Internet" ou le réseau extérieur, car elle se trouve du côté de son
interface WAN.

3.​ Validation du service et preuves de fonctionnement

En tapant l'adresse WAN du pfSense ([Link] dans le navigateur de mon

vrai PC, la requête traverse le WAN, passe par la règle de NAT, est filtrée par l'alias, puis est
redirigée vers le serveur Debian. L'affichage de la page Apache confirme que toute la chaîne
de sécurité est bien configurée. Cela valide que le serveur est protégé contre le monde
entier, sauf pour les adresses de confiance que nous avons nous-mêmes définies.
Analyse des Logs :

Les logs me permettent de voir en temps réel si mes règles de sécurité fonctionnent bien.
Sur mes captures d'écran, on peut observer deux types d'événements importants :

• Trafic bloqué : On voit qu'une tentative de connexion venant de l'IP [Link] vers
[Link] a été rejetée. Cela prouve que mes règles de cloisonnement entre les différents
réseaux sont bien actives et bloquent les accès non autorisés.

• Trafic autorisé : On voit une connexion réussie venant de l'extérieur ([Link]) vers
mon serveur web ([Link]) sur le port 80 (HTTP). Cela confirme que ma règle de "Port
Forwarding" (NAT) et ma règle d'ouverture de flux sur le WAN sont opérationnelles.
Mise en place de l'accès OpenVPN

Pour sécuriser l'accès des employés en télétravail, j'ai mis en place une solution OpenVPN
basée sur une infrastructure de clés publiques (PKI) interne.

• Gestion des Certificats : J'ai d'abord créé une Autorité de Certification interne nommée
StartUpSecure-Internal-CA. C'est elle qui délivre les certificats nécessaires:

• Un certificat serveur (VPN_Server_Cert) pour authentifier le pare-feu.

• Un certificat utilisateur unique (Cert_Employe_Nomade) lié à l'utilisateur. Cette méthode

est beaucoup plus sûre qu'un simple mot de passe, car la possession du certificat est
obligatoire pour établir la connexion.

• Création de l'utilisateur : Pour permettre la connexion, j'ai créé un compte utilisateur

spécifique nommé employe_nomade dans le gestionnaire d'utilisateurs de pfSense. Ce
compte est directement associé au certificat utilisateur précédemment généré, créant ainsi
un lien fort entre l'identité de la personne et sa clé de connexion.

• Configuration du serveur : Le serveur écoute sur l'interface WAN en UDP. J'ai choisi un
chiffrement fort en AES-256-GCM avec un condensé SHA256. Le réseau attribué aux clients
VPN est le [Link]/24.

• Règles de Pare-feu : On voit dans l'onglet des règles qu'une règle spécifique a été créée
avec la description "OpenVPN Serveur_VPN_Nomade wizard". Cette règle est configurée
en "Any" (tout protocole, toute source, toute destination) pour l'interface OpenVPN. Cela
permet de s'assurer que l'utilisateur, une fois connecté au tunnel, ne soit pas bloqué par le
pare-feu pour accéder aux ressources du réseau interne.

• Authentification et Test : L'accès est protégé par une double sécurité, le certificat utilisateur
+ l'identifiant avec son mot de passe. Sur ma capture d'écran de l'application OpenVPN
Connect, on voit que la connexion est établie avec succès. L'utilisateur est alors
virtuellement présent dans le réseau de l'entreprise avec une IP du tunnel.
IPSEC

Connexion Inter-Sites (VPN IPsec)

Pour interconnecter notre infrastructure principale avec une agence distante, j'ai mis en
place un tunnel IPsec IKEv2. Cette configuration permet de faire communiquer les réseaux
locaux de manière totalement sécurisée à travers internet.

​
​ • Adressage du Site Distant (pfSense 3) : Comme on le voit sur la console de la
troisième machine, l'agence distante utilise l'IP [Link] sur son interface
WAN pour nous joindre. Son réseau local (LAN) est configuré en [Link]/24.
​
​ • Configuration de la Phase 1 : Sur mon Master, j'ai paramétré la Phase 1 en utilisant
l'adresse virtuelle CARP [Link] comme interface locale. Cela garantit que
le tunnel restera opérationnel même en cas de basculement du cluster. La passerelle
distante (Remote Gateway) est bien pointée sur l'IP du pfSense 3 ([Link]).
Pour la sécurité, j'ai utilisé une clé pré-partagée (PSK) très complexe ainsi que le
chiffrement AES (256 bits) avec un groupe Diffie-Hellman 14 (2048 bit) pour protéger
l'échange des clés.
​
​ • Flux de données : Dans la Phase 2, j'ai défini que le trafic doit circuler entre notre
LAN local et le subnet distant [Link]/24. Le protocole ESP est utilisé avec les
algorithmes AES et AES-GCM pour garantir l'intégrité et la confidentialité des
données échangées.
​
 ​ • Règles de Pare-feu : Pour que le tunnel puisse s'établir, j'ai ajouté des règles
spécifiques sur l'interface WAN afin d'autoriser les flux ISAKMP (port 500) et IPsec
NAT-T (port 4500). Une règle supplémentaire intitulée "Autoriser flux interne tunnel
ipsec" a été créée pour permettre la libre circulation des paquets une fois qu'ils sont
à l'intérieur du tunnel sécurisé.
​
​ • État de la connexion : Sur le tableau de bord (Status IPsec), on peut confirmer que
le tunnel est en cours de connexion (Connecting) entre notre IP virtuelle .150 et l'IP
distante .143. Cela valide que les deux sites tentent bien de négocier la sécurité pour
monter le pont réseau.

Haute disponibilité

Mise en place de la Haute Disponibilité (Cluster HA)

Pour garantir que le réseau ne coupe jamais, j'ai configuré un cluster avec un
deuxième pare-feu (pfSense Backup). L'idée est que si le Master tombe, le Backup
prend le relais instantanément.

• Configuration du CARP (IP Virtuelle) : J'ai mis en place le protocole CARP pour
créer une adresse IP virtuelle (VIP) en [Link]. C'est cette adresse qui sert
de passerelle unique pour tout le réseau. Sur mes screens, on voit que cette IP est
bien attribuée à l'interface WAN du cluster pour que le basculement soit transparent.

• Synchronisation et Auto-Configuration : Pour éviter de refaire tout le travail deux

fois, j'ai activé la synchronisation XMLRPC. Cela permet de copier automatiquement
toutes les règles et configurations du Master vers le Backup. J'ai aussi utilisé la
partie Restore / Auto Configuration Backup pour m'assurer que les fichiers de
configuration sont bien sauvegardés et prêts à être restaurés en cas de sinistre total
sur une machine.

• Test de connectivité (Ping [Link]) : Pour valider que le cluster fonctionne et que
l'accès internet est opérationnel, j'ai effectué un test de ping vers [Link]. Le succès
de ce test confirme que les adresses sont bien attribuées, que le routage passe
correctement par l'IP virtuelle et que le pare-feu laisse bien sortir le trafic.
• Adressage du pfSense Backup : Le Backup a été configuré avec ses propres
adresses physiques (différentes du Master) mais il "écoute" en permanence l'état du
Master via l'interface de synchronisation pour savoir quand il doit devenir actif.

Test de Basculement et Validation de la Haute Disponibilité Pour vérifier que mon

cluster est réellement opérationnel, j'ai réalisé un test de continuité de service en
simulant une panne critique du nœud principal.

• Étape 1 : Test de connectivité initial : Depuis le client 1 du réseau, j'ai lancé un ping
vers [Link]. Le trafic passait normalement à travers le pfSense Master, confirmant
que l'accès internet et les règles de sortie étaient corrects.
• Étape 2 : Simulation de panne : J'ai ensuite éteint brutalement la VM du pfSense
Master. L'objectif était de vérifier si l'IP virtuelle basculait instantanément sur la
machine de secours.
• Étape 3 : Vérification sur le Backup : En me connectant à l'interface du pfSense
Backup, j'ai pu observer que son état CARP était passé de "Backup" à "Master" (état
original). Le pare-feu secondaire a immédiatement repris la gestion de l'IP virtuelle
[Link].
• Étape 4 : Confirmation du flux : Malgré l'arrêt du Master, les pings vers [Link] ont
continué de répondre sans interruption majeure.