Contexte

Cette partie décrit la migration complète de l’infrastructure réseau Proxmox/VMs vers le sous-réseau pfSense, la configuration avancée du filtrage IP/DNS avec pfBlockerNG, la gestion des complications techniques et les solutions trouvées pour chaque problème, en gardant toutes les adresses IP réelles masquées.

Étapes réalisées

1. Sauvegarde et Préparation

  • Sauvegarde manuelle du fichier de configuration pfSense .xml avant toute migration.
  • Inventaire et documentation des adresses IP existantes.
  • Arrêt des services critiques sur les VMs (ex. n8n) avant modification réseau.

2. Configuration avancée pfBlockerNG

  • Blocage IPs (Inbound Only) :
    • Activation pfBlockerNG uniquement sur l’interface WAN, action Block.
    • Ajout d’un ensemble PRI1 avec 9 sources reconnues (FeodoTracker, CINSArmy, ET, ISC, Spamhaus, Blocklist.de, URLhaus…).
    • Problème : création automatique de règles sur LAN → blocage réseau.
    • Solution : Suppression du LAN/outbound dans la config générale, suppression manuelle des règles sur LAN. Seules les règles sur WAN (inbound) sont gardées.
  • Blocage GeoIP :
    • Désactivé pour tous les pays, choix d’analyser les logs plusieurs jours avant tout blocage géolocalisé.

3. Mise en place DNSBL & Retours d’expérience

  • Problème : choix d’IP DNSBL VIP
    • Essai avec plusieurs IPs dans le sous-réseau LAN rejeté par pfBlockerNG (“Address must be in an isolated Range”).
    • Tentative avec une IP hors /24 (échec: pas routée).
    • Solution temporaire : Utilisation de 127.0.0.1 (loopback) comme VIP DNSBL → accepté par pfBlockerNG et fonctionnel dans ce contexte.
  • Groupes DNSBL configurés :
    • Ads_Basic (StevenBlack hosts)
    • Ads_EasyList (format compatible seulement, pas le easyprivacy.txt original)
    • Malware (URLhaus)
    • Phishing (Phishing Army)
  • Problème whitelist DNSBL :
    • Impossible de trouver la whitelist “globale” classique.
    • Dépannage : Ajout d’exceptions (Microsoft, Ubuntu, Docker, Cloudflare…) directement dans chaque groupe via la section “Custom Domain Whitelist”.

4. Migration Proxmox + VMs vers le nouveau LAN

  • Orchestration étape par étape :
    1. Migration du host Proxmox en premier (modification interfaces/bridge/gateway/dns).
    2. Reconnexion via nouvelle IP, contrôle de l’accès Web.
    3. Migration successive des VMs. Pour les VMs Ubuntu avec Netplan, passage en DHCP4 (puis attribution statique via mapping pfSense pour production).
  • Tests principaux :
    • Ping gateway pfSense
    • Test DNS, résolution externe, apt update, docker pull…
    • Valider que toutes les règles pfBlockerNG n’empêchent ni les repos Linux, ni Docker, ni npm.

5. Cas particulier n8n / Docker / Cloudflare Tunnel

  • Problème 1 : n8n inaccessible après migration
    • Origine : Docker n8n bind par défaut sur 443 et un nom de domaine, n’écoute pas sur 0.0.0.0, ni en HTTP sur 5678.
    • Solution : Refonte du docker-compose.yml pour forcer le bind sur 0.0.0.0:5678, abandon du SSL côté Docker (géré par Cloudflare), reboot safe via docker-compose down/up (données conservées via volume Docker).
  • Problème 2 : Cloudflare Tunnel
    • Origine : tunnel pointait sur IP/port obsolète, et tunnel était encore paramétré en HTTPS.
    • Solution : Modification de la config Tunnel pour HTTP, nouvelle IP VM, désactivation noTLSVerify inutile.

6. Tests post-migration

  • Accessibilité :
    • Accès LAN sur tous les services (n8n, Proxmox, WebGUI pfSense, AP).
    • Accès externe n8n via Cloudflare Tunnel.
  • Blocage pfBlockerNG :
    • Log/alertes, requêtes DNS bloquées (~35% en moyenne), pas de faux-positifs critiques (dank à whitelist incrémentale).
    • Tests ping/dns/réseau OK pour toutes les VMs et hôtes LAN.

Complications et solutions

Problème rencontré Symptôme Solution appliquée
Règle pfBlockerNG sur LAN LAN bloqué, perte accès Suppression Outbound LAN, règles supprimées manuellement
DNSBL VIP refusée dans LAN /24 Erreur “isolated range”, ping page bloc KO VIP mis à 127.0.0.1 (temporaire, fonctionne)
easyprivacy.txt incompatible Erreur invalid URL Substitution par sources compatibles domaines
Pas de whitelist globale DNSBL Incapacité whitelister worldwide Whitelists ajoutées dans chaque groupe
n8n / Docker pas accessible Aucun container n’écoute sur 5678 ports fixés, HTTP activé, SSL désactivé local
Tunnel Cloudflare non routé HTTPS KO, mauvaise destination interne Area HTTP, update URL/IP cible dans dashboard tunnel

Schéma technique (masqué)

[Internet] – [Box/FAI] – [pfSense][LAN] – [EW1200 AP] ==Wifi== [Clients]

[Proxmox Host]–[VMs: n8n, autres]

[Tunnel Cloudflare]

text

Metrics post-migration

  • Taux de requêtes DNS bloquées : ≈ 35%
  • Aucun downtime notable (>15 min) sur les services critiques
  • pfBlockerNG IPv4 : ~30 à 50k IPs bloquées actives
  • Temps total (Partie 3) : ≈ 3-4h
  • Aucun faux positif bloquant la production (seulement pubs/trackers)

Prochaines étapes proposées

  • Surveillance quotidienne logs pfBlockerNG
  • Validation charge/latence sur le long terme
  • Documentation des prochaines migrations (VLAN, segmentation IOT/Prod)
  • Étendre l’usage du monitoring (Grafana, Prometheus, etc.)

Rédigé au format Markdown, partie 3 du projet homelab personalisé pfsense/proxmox/cloudflare, IPs et credentials volontairement masqués.