Objectif : déployer pfSense comme pare-feu/routeur central afin de sécuriser le périmètre, segmenter le réseau interne et contrôler finement l’accès aux applis (GLPI, Heimdall…).

Livrables : VM pfSense opérationnelle (WAN/LAN), plan d’adressage, règles (blocage Internet global + blocage applicatif), batteries de tests avec logs, runbook d’exploitation.

Contexte professionnel

• Renforcer la sécurité périmétrique et la conformité réglementaire.
• Centraliser l’administration des règles via une interface Web unique.
• S’intégrer naturellement à un environnement virtualisé (lab VirtualBox, extensible à Proxmox/VMware).

Objectifs mesurables

• Toutes les VMs du LAN utilisent pfSense comme passerelle par défaut.
• Règles LAN démontrées : blocage Internet global + blocage applicatif (Heimdall:8080).
• Traçabilité : journaux de firewall cohérents durant les tests.
• Exploitation : doc & procédures Day-2 (sauvegarde, MAJ, ajout de règles).

Inclus : VM pfSense (WAN+LAN), VMs clientes (dont Heimdall), règles firewall, tests, journalisation, doc & runbook.

Hors-scope (prévu en évolutions) : VLANs, VPN site-à-site/nomade, HA CARP, portail captif, IDS/IPS avancé.

                      Internet
                         │
                 (VirtualBox NAT)
                         │  (WAN DHCP)
                  ┌──────▼────────┐
                  │   pfSense     │
                  │  WAN: 10.0.2.x│
                  │  LAN: 192.168.1.1/24
                  └──────┬────────┘
                         │  (LAN - réseau interne "intnet")
        ┌────────────────┼─────────────────┐
        │                │                 │
   VM Client A      VM Heimdall       VM GLPI ...
  192.168.1.10      192.168.1.20      192.168.1.30
  GW 192.168.1.1    GW 192.168.1.1    GW 192.168.1.1

Plan d’adressage : WAN en DHCP (10.0.2.0/24, VirtualBox NAT), LAN 192.168.1.0/24 (pfSense = 192.168.1.1). Clients : 192.168.1.10..200. Heimdall 192.168.1.20:8080, GLPI 192.168.1.30:80.

Point clé : la passerelle de toutes les VMs LAN = 192.168.1.1 (pfSense), sinon les règles ne s’appliquent pas.

• Hyperviseur : VirtualBox (lab).
• Image : pfSense CE amd64 (ISO officielle).
• Hôte : accès Internet (pour la VM pfSense via NAT).
• Connaissances : bases TCP/IP, routage, NAT, firewall stateful.

1) Création de la VM pfSense (VirtualBox)

• VM pfSense.home.arpa — FreeBSD 64-bit, 2 vCPU, 2 Go RAM, disque 20 Go.
• Cartes réseau : Adapter 1 = WAN: NAT ; Adapter 2 = LAN: Réseau interne (ex. intnet).
• Installation : boot sur ISO, partitionnement auto, redémarrage.

2) Affectation interfaces & config initiale

• Console : em0 → WAN ; em1 → LAN (par défaut LAN = 192.168.1.1/24).
• Depuis une VM LAN : IP 192.168.1.10/24, GW 192.168.1.1 → accéder à https://192.168.1.1 (certificat autosigné).
• Login admin/pfsense → changement de mot de passe, timezone Europe/Paris, WAN en DHCP, DNS Resolver actif.

3) Aliases (lisibilité & maintenance)

Firewall → Aliases
- HEIMDALL_HOST = 192.168.1.20
- HEIMDALL_PORT = 8080

4) Règles Firewall (interface LAN)

pfSense évalue les règles de haut en bas (première correspondante = appliquée).

1. (auto) Anti-lockout (HTTP/HTTPS vers pfSense) — toujours en tête.
2. Blocage Internet global : Interface=LAN ; Action=Block ; Source=LAN net ; Destination=any ; Proto=any ; Position=juste après l’anti-lockout ; Description=Block all LAN → Internet.
3. Blocage applicatif Heimdall : Interface=LAN ; Action=Block ; Source=LAN net ; Destination=HEIMDALL_HOST ; Proto=TCP ; Port dest=HEIMDALL_PORT ; Position=au-dessus des règles permissives ; Description=Block LAN → Heimdall:8080.
4. (Optionnel) Autoriser LAN→LAN pour services internes (GLPI, DB…).

5) NAT & routage

• NAT IPv4 automatique sur le WAN (par défaut pfSense).
• Vérifier que toutes les VMs LAN ont 192.168.1.1 en passerelle.
• Attention aux VMs multi-NIC : risque de bypass dpfSense.

Pré-conditions

• Client LAN : 192.168.1.10/24 ; GW 192.168.1.1.
• Règles en bon ordre (blocages au-dessus des passes).

Cas de tests

1. Accès GUI pfSense — https://192.168.1.1 → OK.
2. Blocage Internet global — Navigateur vers google.com/amazon.fr → bloqué. ping 8.8.8.8 → bloqué (sauf règle ICMP spécifique).
3. Blocage Heimdall — http://192.168.1.20:8080 → bloqué.
4. Accès interne autorisé — GLPI http://192.168.1.30:80 → OK (si règle prévue).

Traçabilité (preuves)

• Status → System Logs → Firewall : entrées Blocked pour B et C (source, destination, proto/port, règle appliquée).
• (Optionnel) Diagnostics → Packet Capture : génération de PCAP et vérification sous Wireshark.

Comptes & accès

• Changer le mot de passe admin, limiter l’accès GUI au LAN (ne jamais exposer sur WAN).
• Désactiver SSH si inutile ou restreindre par clés/règles.

Sauvegarde / restauration

• Diagnostics → Backup/Restore : exporter config.xml (contient des secrets).
• Ne jamais publier config.xml.

Mises à jour

• System → Update : politique de patching, créneau de maintenance.

Gestion de règles (Day-2)

• Créer/éditer les Aliases (hosts/ports) pour lisibilité.
• Firewall → Rules (interface) : ajouter/modifier, positionner, sauvegarder et Apply Changes.
• Tester, lire les logs, valider.

Journalisation & supervision

• System Logs → Firewall pour l’audit.
• Intégrations possibles : syslog distant, Zabbix/Prometheus (évolution).

• Règle de blocage inopérante — La VM ne passait pas par pfSense (gateway erronée, autre NIC prioritaire). Fix : forcer GW = 192.168.1.1 ; désactiver la seconde NIC ou ajuster la métrique.
• Ordre des règles — Une règle permissive au-dessus court-circuitait le blocage. Fix : remonter les règles de blocage au-dessus.
• Multi-NIC & routage — Bypass via une autre sortie. Fix : simplifier la connectique, vérifier ip route/route print, corriger les routes.