Context

This part describes the complete migration of the Proxmox/VMs network infrastructure to the pfSense subnet, the advanced configuration of IP/DNS filtering using pfBlockerNG, the management of technical complications, and the solutions found for each problem, while keeping all real IP addresses masked.

Steps Performed

1. Backup and Preparation

  • Manual backup of the pfSense .xml configuration file before any migration.
  • Inventory and documentation of existing IP addresses.
  • Stopping critical services on the VMs (e.g., n8n) before network modification.

2. Advanced pfBlockerNG Configuration

  • IP Blocking (Inbound Only):
    • Activating pfBlockerNG only on the WAN interface, Block action.
    • Adding a PRI1 set with 9 recognized sources (FeodoTracker, CINSArmy, ET, ISC, Spamhaus, Blocklist.de, URLhaus...).
    • Problem: automatic creation of rules on LAN → network blockage.
    • Solution: Removal of LAN/outbound in the general config, manual deletion of rules on LAN. Only rules on WAN (inbound) are kept.
  • GeoIP Blocking:
    • Disabled for all countries, decision to analyze logs for several days before applying any geolocated blocking.

3. DNSBL Implementation & Feedback

  • Problem: choice of DNSBL VIP IP
    • Attempted with several IPs in the LAN subnet rejected by pfBlockerNG (“Address must be in an isolated Range”).
    • Attempt with an IP outside /24 (failure: not routed).
    • Temporary solution: Using 127.0.0.1 (loopback) as the DNSBL VIP → accepted by pfBlockerNG and functional in this context.
  • Configured DNSBL Groups:
    • Ads_Basic (StevenBlack hosts)
    • Ads_EasyList (compatible format only, not the original easyprivacy.txt)
    • Malware (URLhaus)
    • Phishing (Phishing Army)
  • DNSBL Whitelist Problem:
    • Unable to find the classic “global” whitelist.
    • Troubleshooting: Added exceptions (Microsoft, Ubuntu, Docker, Cloudflare…) directly into each group via the “Custom Domain Whitelist” section.

4. Migration of Proxmox + VMs to the New LAN

  • Step-by-step Orchestration:
    1. Migration of the Proxmox host first (modification of interfaces/bridge/gateway/dns).
    2. Reconnection via new IP, check Web access.
    3. Successive migration of VMs. For Ubuntu VMs using Netplan, switch to DHCP4 (then static assignment via pfSense mapping for production).
  • Main Tests:
    • Ping gateway pfSense
    • Test DNS, external resolution, apt update, docker pull…
    • Validate that all pfBlockerNG rules do not block Linux repos, Docker, or npm.

5. Special Case n8n / Docker / Cloudflare Tunnel

  • Problem 1: n8n inaccessible after migration
    • Cause: Docker n8n binds by default on 443 and a domain name, does not listen on 0.0.0.0, nor on HTTP on 5678.
    • Solution: Reworking the docker-compose.yml to force the bind on 0.0.0.0:5678, abandoning SSL on the Docker side (managed by Cloudflare), safe reboot via docker-compose down/up (data preserved via Docker volume).
  • Problem 2: Cloudflare Tunnel
    • Cause: tunnel pointed to an obsolete IP/port, and the tunnel was still configured for HTTPS.
    • Solution: Modification of the Tunnel config for HTTP, new VM IP, disabling unnecessary noTLSVerify.

6. Post-Migration Tests

  • Accessibility :
    • LAN access to all services (n8n, Proxmox, pfSense WebGUI, AP).
    • External n8n access via Cloudflare Tunnel.
  • pfBlockerNG Blocking :
    • Logs/alerts, blocked DNS queries (~35% average), no critical false positives (thanks to incremental whitelist).
    • Ping/DNS/network tests OK for all VMs and LAN hosts.

Complications and Solutions

Issue Encountered Symptom Solution Applied
pfBlockerNG Rule on LAN LAN blocked, loss of access Removal of Outbound LAN, rules manually deleted
DNSBL VIP rejected in LAN /24 “isolated range” error, block page ping failed VIP set to 127.0.0.1 (temporary, functional)
easyprivacy.txt incompatible Invalid URL error Substitution with domain-compatible sources
No global DNSBL whitelist Inability to whitelist worldwide Whitelists added to each group
n8n / Docker inaccessible No container listening on 5678 ports fixed, HTTP enabled, SSL disabled locally
Cloudflare Tunnel not routed HTTPS fail, incorrect internal destination Set to HTTP, update target URL/IP in tunnel dashboard

Technical Diagram (masked)

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

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

[Cloudflare Tunnel]

text

Post-Migration Metrics

  • DNS Query Block Rate: ≈ 35%
  • No notable downtime (>15 min) on critical services
  • pfBlockerNG IPv4: ~30 to 50k active blocked IPs
  • Total time (Part 3): ≈ 3-4h
  • No false positives blocking production (only ads/trackers)

Proposed Next Steps

  • Daily monitoring of pfBlockerNG logs
  • Long-term load/latency validation
  • Documentation of upcoming migrations (VLAN, IOT/Prod segmentation)
  • Extend monitoring usage (Grafana, Prometheus, etc.)

Written in Markdown format, part 3 of the personalized pfsense/proxmox/cloudflare homelab project, IPs and credentials voluntarily masked.