Path : infrastructure/pfsense
pfSense CE est la pièce centrale du réseau LORVA. Il tourne en VM sur l'hyperviseur Proxmox (OVH KS-16, Beauharnois CA) et assure quatre rôles fondamentaux :
lorva.dev en IP internes pour les containers Docker| Champ | Valeur |
|---|---|
| VM ID Proxmox | 100 |
| Nom | pfsense |
| Hyperviseur | Proxmox 9 — OVH KS-16 (192.99.35.93, Beauharnois CA) |
| Version | pfSense CE (ref. 2.8.1) |
| RAM | 2 GB (fixe, balloon désactivé) |
| Disque | 20 GB VirtIO SCSI |
| CPU | 2 vCPU |
| Interface pfSense | NIC Proxmox | Réseau | IP |
|---|---|---|---|
WAN (vtnet0) |
vmbr1 (lien p2p) |
10.255.255.0/30 |
10.255.255.2/30 |
LAN trunk (vtnet1) |
vmbr2 (VLAN-aware) |
trunk 802.1q | sous-interfaces VLAN (voir ci-dessous) |
Confirmations live :
# ARP depuis lorva-infra
10.10.10.1 → MAC bc:24:11:5d:08:9d (interface eth0, REACHABLE)
# Route depuis lorva-public
default via 10.10.30.1 ← gateway pfSense VLAN 30, active et joignable
OVH applique un filtre anti-spoofing strict : il est impossible de bridger l'IP publique directement vers une VM. L'architecture utilise donc un double NAT via un lien point-à-point :
Internet
│
▼
192.99.35.93 (Proxmox host — enp4s0 / vmbr0)
│ iptables DNAT — ports 1-8005 + 8007-65535
▼
10.255.255.1/30 (Proxmox side — vmbr1)
│
▼
10.255.255.2/30 (pfSense WAN — vtnet0)
│ NAT / firewall / routage
▼
vmbr2 (VLAN-aware trunk)
├── VLAN 10 — INFRA
├── VLAN 20 — PROD
├── VLAN 30 — PUBLIC
└── VLAN 40 — MGMT
Points critiques :
https://pve.lorva.dev depuis le VPNMASQUERADE est actif sur Proxmox pour le retour pfSense → internet (trafic sortant depuis 10.255.255.0/30 sur vmbr0)Tous les VLANs sont créés sur vtnet1 (trunk vmbr2). pfSense est la gateway unique pour l'ensemble du réseau LORVA.
| VLAN | Nom | Subnet | Gateway pfSense | VM principale |
|---|---|---|---|---|
| 10 | INFRA | 10.10.10.0/24 |
10.10.10.1 |
lorva-infra — 10.10.10.10 |
| 20 | PROD | 10.10.20.0/24 |
10.10.20.1 |
taskori-prod — 10.10.20.10 |
| 30 | PUBLIC | 10.10.30.0/24 |
10.10.30.1 |
lorva-public — 10.10.30.10 |
| 40 | MGMT | 10.10.40.0/24 |
10.10.40.1 |
Proxmox host — 10.10.40.10 |
Politique par défaut : BLOCK tout ce qui n'est pas explicitement autorisé.
| Proto | Port ext. | Description |
|---|---|---|
| TCP | 80 | HTTP → Traefik (lorva-public) |
| TCP | 443 | HTTPS → Traefik (lorva-public) |
| TCP | 25 | SMTP Mailcow |
| TCP | 465 | SMTPS Mailcow |
| TCP | 993 | IMAPS Mailcow |
| UDP | 500 | IPsec IKE (pfSense self) |
| UDP | 4500 | IPsec NAT-T (pfSense self) |
| ESP | — | IPsec ESP (pfSense self) |
| any | any | BLOCK (règle finale implicite) |
| Interface | Proto | Port ext. | Destination | Port int. | Service |
|---|---|---|---|---|---|
| WAN | TCP | 80 | 10.10.30.10 |
80 | Traefik HTTP |
| WAN | TCP | 443 | 10.10.30.10 |
443 | Traefik HTTPS |
| WAN | TCP | 25 | 10.10.30.10 |
25 | Mailcow SMTP |
| WAN | TCP | 465 | 10.10.30.10 |
465 | Mailcow SMTPS |
| WAN | TCP | 993 | 10.10.30.10 |
993 | Mailcow IMAPS |
Tout le trafic public entrant arrive sur lorva-public (10.10.30.10) qui porte Traefik et Mailcow. Traefik redirige ensuite vers les services sur les autres VLANs selon les règles inter-VLAN ci-dessous.
| Source | Destination | Action | Justification |
|---|---|---|---|
| INFRA (10) | WAN | Pass | GitLab pulls, Let's Encrypt, mises à jour |
| INFRA (10) | PROD (20) | Block | GitLab isolé de la DB Taskori |
| PROD (20) | WAN | Block | Apps sans accès internet direct |
| PROD (20) | PROD (20) | Pass | Trafic Docker interne |
| PUBLIC (30) | WAN | Pass | Let's Encrypt DNS-01, Chatwoot webhooks |
| PUBLIC (30) | INFRA (10) ports 80/443 | Pass | Traefik → GitLab |
| PUBLIC (30) | PROD (20) port 80 | Pass | Traefik → apps Taskori |
| MGMT (40) | any | Pass | Accès admin total depuis VPN |
Tunnel IKEv2 vers un réseau distant de confiance.
| Paramètre | Valeur |
|---|---|
| Type | IKEv2, Pre-Shared Key |
| Phase 1 chiffrement | AES-256 / SHA-256 / DH Group 14 |
| Phase 2 — réseau LORVA | 10.10.0.0/16 |
| Statut | Actif |
PSK : voir Flatnotes (note
taskori-infraou secret CI/CD GitLab LORVA).
Le MSS clamping n'est pas encore configuré sur l'interface IPsec pfSense (valeur cible : ~1360). En conséquence, les grosses trames sont silencieusement droppées (PMTUD black-hole). Symptôme observé : SSH bloque sur gros paquets à travers le tunnel.
Fix définitif : configurer TCP Maximum Segment Size à 1360 sur l'interface IPsec dans pfSense (VPN → IPsec → Advanced Settings).
pfSense résout les noms lorva.dev en IP internes pour que les containers Docker n'aient pas à sortir sur internet pour se joindre entre eux.
| Nom | IP interne |
|---|---|
mail.lorva.dev |
10.10.30.10 |
registry.lorva.dev |
10.10.30.10 |
gitlab.lorva.dev |
10.10.30.10 |
Chaque VM pointe sur la gateway de son VLAN comme résolveur DNS (/etc/resolv.conf ou configuration Docker daemon dns).
// /etc/docker/daemon.json sur lorva-infra (exemple)
{
"dns": ["10.10.10.1"]
}
| Méthode | Commande / URL |
|---|---|
| Via VPN IPsec | https://10.10.40.1 |
| Via tunnel SSH (sans VPN actif) | ssh -L 8443:10.255.255.2:443 [email protected] → https://localhost:8443 |
| Credentials | Voir Flatnotes (admin — note taskori-infra) |
L'UI pfSense n'est jamais exposée sur internet. Le port 443 WAN est réservé à Traefik.
pfSense n'est pas directement accessible par SSH depuis internet. Deux chemins possibles :
Via le VPN (chemin normal) :
# Depuis n'importe quelle machine connectée au tunnel VPN
ssh [email protected]
Via console Proxmox (accès de secours) :
# Sur l'hyperviseur OVH
qm terminal 100
# ou via https://pve.lorva.dev → VM 100 → Console
User dédié netbox-sync :
Le script sync-pfsense.py se connecte avec l'utilisateur netbox-sync et la clé /data/id_ansible pour lire /cf/conf/config.xml sans passer par l'UI.
pfSense est référencé dans NetBox avec les éléments suivants :
pfsense sur le devicessh_hostname pour l'accès programmatiquesync-pfsense.py synchronise automatiquement :
config.lorva.dev/nat.html| Fichier | Description |
|---|---|
projects/LORVA/netbox-sync-lorva/scripts/sync-pfsense.py |
Script de synchronisation pfSense → NetBox |
projects/LORVA/Company/plans/2026-05-25-phase1-proxmox-pfsense.md |
Plan d'implémentation détaillé (procédures, commandes) |
projects/LORVA/Company/2026-05-25-lorva-infra-design.md |
Design général de l'infra LORVA incluant pfSense |
| Priorité | Tâche |
|---|---|
| Haute | Configurer MSS clamping IPsec (~1360) pour corriger le black-hole PMTUD |
| Moyenne | RADIUS pour l'authentification admin pfSense (FreeRADIUS sur lorva-infra) |
| Basse | Audit et nettoyage des règles WAN après stabilisation complète de l'infra |