Les labos réseau du BTS : pfSense, DMZ, haute disponibilité et Active Directory sur deux sites
Mon premier pare-feu, monté pendant le BTS puis repris en laboratoire jusqu'à l'épreuve pratique : isoler un serveur web en DMZ, supprimer le pare-feu unique, puis faire vivre un même domaine sur deux sites reliés par leurs pfSense.
En bref
Protéger un LAN avec un pare-feu open source, publier un serveur web sans exposer le réseau interne, ne plus dépendre d'un pare-feu unique, puis relier deux sites qui partagent un domaine.
J'ai monté quatre labos : un LAN avec DHCP et résolveur DNS, une DMZ à trois interfaces, deux pfSense en cluster CARP, et deux sites reliés par un réseau de transit avec un contrôleur de domaine chacun.
Trois zones séparées avec un seul port publié, une panne DNS résolue, un cluster maître et secours sur deux IP virtuelles, et un domaine répliqué entre deux sites routés.
Contexte
Quatre travaux de mon BTS SIO, en laboratoire virtualisé, autour d'une même question : protéger et relier des réseaux avec un pare-feu open source. Ordre réel : le pare-feu et son LAN (décembre 2023 – avril 2024), le cluster CARP (décembre 2024 – janvier 2025), le domaine sur deux sites, préparé pour l'épreuve pratique (octobre 2024 – février 2025), puis la DMZ (avril 2025).
Tout y est fictif, adresses et noms compris. En entreprise, le même annuaire a reçu un second contrôleur réel.
Ce que j'ai fait
1. Un pare-feu, un LAN et une panne DNS
Sous VMware Workstation : WAN en pont sur la box, LAN isolé en 192.168.14.0/24, et un client Windows Server 2022 qui ne sort que par pfSense. Une fois la sortie validée, j'ai activé le DHCP (plage .50 à .100) : c'est là qu'est apparue la panne DNS décrite plus bas.
2. Une DMZ pour publier un serveur web
Sur Proxmox, en suivant un TP guidé, pfSense reçoit une troisième interface : un serveur exposé à Internet ne doit pas atteindre le réseau interne s'il est compromis. Le serveur, un conteneur LXC Debian 12, a l'adresse réservée 192.168.10.250 ; il sort pour ses mises à jour (NAT sortant), et le port 80 du WAN est redirigé vers son Apache.
3. Deux pare-feu en cluster CARP
Après avoir comparé pfSense à Cisco ASA et Sophos XG, et analysé cinq risques dont l'échec silencieux de la synchronisation, j'ai monté deux pfSense, maître et secours. Ils partagent une IP virtuelle sur le WAN (192.168.10.1) et une sur le LAN (192.168.1.1) ; le maître pousse au secours les règles, le NAT, le DHCP et les paramètres système.
4. Un domaine Active Directory sur deux sites
Le scénario de l'épreuve pratique : un intégrateur fictif relie deux sites d'un client, protégés chacun par son pfSense, et y installe un seul domaine, lab.local. Si le lien tombe, chaque site doit continuer à authentifier ses utilisateurs.
- Relier les deux pare-feuLAN en .254, une interface sur un réseau de transit et une route statique vers le LAN d'en face ; règle d'autorisation sur le transit, puis pings croisés entre les sites.
- Un contrôleur par siteNouvelle forêt lab.local avec DNS intégré sur le site A, contrôle de la zone et des enregistrements SRV ; sur le site B, DNS pointé vers le premier contrôleur à travers le transit, jonction, puis promotion avec DNS et catalogue global.
- Vérifier la réplicationRéplication forcée depuis la console Sites et services,
repadmin /replsummaryet/showrepl, résolution croisée des deux noms, compte de test créé d'un côté et attendu de l'autre.
Voir les détails techniques
Pare-feu et LAN
Le WAN, en pont sur la box, a une adresse privée, d'où l'option « Block RFC1918 » décochée. Les interfaces ont été réassignées à la main avant de valider la sortie.
DMZ
Conteneur LXC Debian 12 : 1 cœur, 512 Mo de RAM, 8 Go.
Règles de la DMZ, dans l'ordre où je les poserais
| Ordre | Action | Source | Destination | Ports |
|---|---|---|---|---|
| 1 | Bloquer | DMZ net | LAN net | Tous |
| 2 | Autoriser | DMZ net | Tout | 53 (TCP et UDP) |
| 3 | Autoriser | DMZ net | Tout | 80 et 443 (TCP) |
| 4 | Bloquer (implicite) | Tout | Tout | Tous |
Cluster CARP
Procédure de bascule : couper le maître, vérifier dans Status > CARP que le secours passe MASTER et que les clients sortent, puis observer le retour du maître.
Pour départager les nœuds, on règle le décalage CARP (skew 0 et 100) plutôt que la base d'annonce (1 contre 2). Deux règles du cluster sont aussi à reprendre : l'administration HTTPS ouverte sur le WAN, à fermer, et « LAN → tout » placée en tête, qui rend inutiles les règles du dessous puisque pfSense s'arrête à la première qui correspond.
Domaine sur deux sites
| Pare-feu | LAN | Transit | Route statique |
|---|---|---|---|
| pfSense A | 192.168.15.254 | 192.168.99.1 | 192.168.16.0/24 via 192.168.99.2 |
| pfSense B | 192.168.16.254 | 192.168.99.2 | 192.168.15.0/24 via 192.168.99.1 |
Flux à laisser passer entre les deux sites : DNS (53), Kerberos (88), RPC (135 et sa plage dynamique), LDAP (389) et SMB (445). L'erreur typique d'un flux bloqué est la 1722, « serveur RPC indisponible ».
PowerShell · ce que j'ajouterais
# Déclarer les deux sites, leurs sous-réseaux et le lien entre eux
New-ADReplicationSite -Name "Site-A"
New-ADReplicationSite -Name "Site-B"
New-ADReplicationSubnet -Name "192.168.15.0/24" -Site "Site-A"
New-ADReplicationSubnet -Name "192.168.16.0/24" -Site "Site-B"
New-ADReplicationSiteLink -Name "A-B" -SitesIncluded "Site-A","Site-B" -Cost 100 -ReplicationFrequencyInMinutes 15
# Ranger chaque contrôleur dans son site
Move-ADDirectoryServer -Identity "DC1" -Site "Site-A"
Move-ADDirectoryServer -Identity "DC2" -Site "Site-B"
# Garder les preuves
repadmin /replsummary > C:\Preuves\replsummary.txt
dcdiag /e /qL'incident
Internet répond, mais plus aucun nom ne se résout
Après le passage en DHCP, ping 8.8.8.8 répond, ping google.com échoue et nslookup renvoie « Query refused ».
J'ai contrôlé les DNS de pfSense, puis son résolveur (activé, à l'écoute sur le LAN, récursif). Avec les serveurs amont 8.8.8.8 et 1.1.1.1 et le mode forwarding, les noms se résolvent après ipconfig /flushdns et /renew. Leçon : tester par IP et par nom séparément, et ne changer qu'un réglage à la fois.
Résultats
Le LAN sort par pfSense et résout les noms. La page d'Apache, en DMZ, s'affiche depuis le LAN ; l'accès depuis Internet reste à démontrer. Le routage entre les deux sites et les deux contrôleurs sont en place, mais pour l'annuaire ils restent dans un seul site, Default-First-Site-Name.
Ce que ces labos ne prouvent pas : je n'ai gardé de trace ni d'un test de coupure du cluster, ni des sorties de repadmin. C'est ce qui sépare un labo réussi d'un labo démontré.
Ce que j'améliorerais
- J'ajouterais en tête de la DMZ une règle qui bloque tout vers le LAN, puis une sortie limitée aux ports 53, 80 et 443.
- Je ferais passer la synchronisation du cluster sur une interface dédiée, et j'ajouterais le NAT sortant vers l'IP virtuelle 192.168.10.1, pour que l'adresse de sortie ne change pas à la bascule.
- Je déclarerais les deux sites Active Directory, leurs sous-réseaux et leur lien, et je relierais deux vrais sites par un tunnel IPsec ouvert aux seuls ports de l'annuaire.
- Je testerais les coupures, du maître CARP puis du transit entre les sites, sorties datées de
repadminetdcdiagà l'appui.
La suite : éprouver la segmentation en l'attaquant dans un cyber range FortiGate, exposer un service réel dans une DMZ de production, puis auditer un annuaire réel, en 2026.