Déploiement d'un pare-feu pfSense dans un laboratoire virtualisé

Présentation du projet

Dans le cadre de ma formation en cybersécurité, j'ai réalisé un laboratoire pratique consacré à l'installation et à la configuration de pfSense CE, une solution de pare-feu permettant de contrôler les communications réseau entre différents segments.

L'objectif était de mettre en place une infrastructure virtualisée comprenant un pare-feu et un poste client Windows 11, afin d'expérimenter la segmentation réseau, le routage, le NAT et l'attribution automatique des adresses IP.

Ce laboratoire m'a également permis de travailler sur la configuration des interfaces réseau virtuelles et de valider le fonctionnement de l'infrastructure à l'aide de tests de connectivité.

Environnement technique

• Pare-feu : pfSense CE
• Virtualisation : Oracle VirtualBox
• Système client : Windows 11
• Réseau : interfaces WAN et LAN séparées
• Services réseau : NAT et DHCP
• Tests : ipconfig, ping et accès à l'interface Web d'administration

1. Architecture réseau

La première étape a consisté à concevoir une architecture simple permettant d'isoler le poste client derrière le pare-feu.

pfSense dispose de deux interfaces réseau virtuelles :

• WAN (em0) : interface connectée au réseau NAT de VirtualBox pour accéder à Internet.
• LAN (em1) : interface connectée à un réseau interne VirtualBox, destiné au poste Windows 11.

Le poste client utilise l'interface LAN de pfSense comme passerelle par défaut.

Métriques de l'architecture

2. Installation et configuration de pfSense

J'ai commencé par télécharger l'image d'installation de pfSense CE depuis la source officielle, puis créé une machine virtuelle dans VirtualBox.

La machine virtuelle a été configurée avec deux interfaces réseau distinctes : une interface WAN en mode NAT et une interface LAN rattachée à un réseau interne.

Après l'installation du système, j'ai vérifié l'assignation des interfaces et configuré le réseau LAN avec l'adresse IP statique 192.168.1.1/24.

Le serveur DHCP intégré à pfSense a ensuite été activé afin de permettre aux machines clientes du réseau interne d'obtenir automatiquement leur configuration IP.

3. Mise en place du NAT et du routage

Le NAT (Network Address Translation) permet aux machines du réseau LAN privé d'accéder à Internet en utilisant l'adresse de l'interface WAN de pfSense.

Dans cette architecture, le poste Windows 11 utilise 192.168.1.1 comme passerelle. Le trafic destiné à l'extérieur passe par pfSense, qui assure le routage entre les deux interfaces.

Cette configuration permet de comprendre le rôle du pare-feu comme point de passage entre le réseau interne et le réseau extérieur.

4. Attribution automatique des adresses IP

Après avoir configuré le réseau interne de Windows 11 dans VirtualBox, j'ai vérifié la configuration IP du poste client à l'aide de la commande :

ipconfig

Le poste a reçu automatiquement l'adresse 192.168.1.102, avec un masque de sous-réseau 255.255.255.0 et la passerelle 192.168.1.1.

Cette vérification a permis de confirmer que le service DHCP de pfSense attribuait correctement une configuration réseau au client.

5. Tests de connectivité

Une fois la configuration réseau terminée, j'ai effectué plusieurs tests pour valider la communication entre le poste client et le pare-feu.

Le premier test consistait à envoyer des requêtes ICMP vers l'adresse LAN de pfSense :

ping 192.168.1.1

Les réponses reçues ont confirmé que le poste client pouvait communiquer avec l'interface LAN du pare-feu.

J'ai ensuite accédé à l'interface Web d'administration de pfSense depuis le navigateur de Windows 11 en utilisant l'adresse 192.168.1.1.

Ces tests ont permis de vérifier la connectivité locale et l'accessibilité de l'interface d'administration.

6. Filtrage du trafic et sécurité réseau

Les règles du pare-feu déterminent les communications autorisées ou refusées entre les réseaux.

Dans l'architecture étudiée, le trafic entre le réseau interne et Internet passe par pfSense. Le laboratoire présente notamment les flux nécessaires à la navigation Web et à la résolution DNS :

• DNS : port 53
• HTTP : port 80
• HTTPS : port 443

L'interface d'administration de pfSense est accessible depuis le réseau LAN.

Le laboratoire aborde également le principe selon lequel les connexions initiées depuis le WAN vers le LAN doivent être bloquées par défaut. La validation détaillée de chaque règle et des tentatives de connexion non autorisées n'étant pas documentée dans le rapport, je ne présente pas ces contrôles comme des tests d'intrusion réalisés.

7. Difficultés rencontrées et dépannage

La configuration des interfaces réseau virtuelles a nécessité plusieurs vérifications pour assurer la communication entre pfSense et le poste client.

Le diagnostic s'est appuyé sur les éléments suivants :

• vérification de l'assignation des interfaces WAN et LAN ;
• contrôle de l'adressage IP du poste client ;
• vérification de la passerelle par défaut ;
• test de connectivité avec ping ;
• accès à l'interface Web d'administration.

Cette démarche m'a permis de mieux comprendre les dépendances entre la configuration de l'hyperviseur, les interfaces du pare-feu et le réseau du système client.

8. Résultats et compétences acquises

À l'issue du laboratoire, l'infrastructure virtualisée comprenait un pare-feu pfSense et un poste client Windows 11 connecté au réseau LAN.

Les vérifications réalisées ont confirmé l'attribution d'une adresse IP par DHCP, la connectivité avec l'interface LAN du pare-feu et l'accès à son interface d'administration.

Synthèse technique

Ce laboratoire m'a permis de mettre en pratique les notions de segmentation réseau, de NAT, de DHCP, de routage et de filtrage du trafic. Il constitue une première étape dans l'apprentissage de l'administration et de la sécurisation des infrastructures réseau.

Pistes d'amélioration

Pour approfondir ce laboratoire, les prochaines étapes pourraient consister à créer des règles de filtrage personnalisées, à tester explicitement les flux autorisés et refusés, puis à documenter les résultats de ces tests. Une extension avec plusieurs sous-réseaux ou un second poste client permettrait également d'étudier plus précisément la segmentation et le contrôle des communications.