Chez DYB, nous voyons souvent des administrateurs utiliser des plages horaires (schedules) dans pfSense. C’est pratique pour restreindre certains usages (RDP, SMB, etc.), mais il existe un piège méconnu : vos flux peuvent être coupés en plein milieu d’une sauvegarde.
Le fonctionnement du moteur pf (stateful firewall)
pfSense repose sur le moteur pf de FreeBSD, qui est stateful :
- Lorsqu’un flux démarre, il est attaché à la règle qui l’a autorisé.
- Une entrée de state est créée ; tant qu’elle existe, les paquets passent sans repasser par l’évaluation des règles.
- Quand la règle expire ou est désactivée (fin d’un horaire, suppression…), pf supprime immédiatement tous les états créés par cette règle.
Résultat :
- La session en cours est coupée net, même si une autre règle plus permissive existe dans le firewall.
- Si cette règle plus permissive a été ajoutée après le début du flux, elle ne sera pas prise en compte tant que le logiciel ne relance pas la connexion.
⚠️ Concrètement : une copie de fichiers Windows classique sera interrompue sans reprise, tandis qu’un logiciel de sauvegarde comme SyncBack ou Veeam saura généralement relancer la connexion et continuer.
Exemple concret : la sauvegarde SMB
- Vous avez une règle qui autorise SMB uniquement en journée (8h–23h).
- À 22h50, une sauvegarde démarre.
- À 23h01, la règle horaire s’éteint → pf supprime l’état associé.
- Le job est interrompu :
- Avec une simple copie Windows → l’opération est annulée.
- Avec Veeam → la tâche repart, mais avec perte de temps et parfois fragmentation du job.
- Dans les logs, vous verrez un block lié au “default deny rule IPv4”.
Bonnes pratiques pour vos sauvegardes et flux critiques
- Anticipez l’impact des schedules
- Toute règle planifiée qui expire supprime les états associés.
- Vérifiez quels flux (SMB, RDP, réplication) risquent d’être affectés.
- Créez vos règles puis testez-les systématiquement
- Créez la règle sur l’interface concernée.
- Faites un flush des states (
Diagnostics > States > Reset States) pour repartir propre. - Testez vos flux en chevauchant les plages horaires.
- Évitez les surprises en production
- Si un flux doit absolument être continu (sauvegarde, réplication, transfert volumineux), ne le soumettez pas à une règle horaire.
- Documentez les règles avec horaires et prévoyez des mécanismes de reprise côté applicatif (logiciel de sauvegarde robuste).
Conclusion
Les règles planifiées dans pfSense ne sont pas “intelligentes” : elles n’attendent pas la fin d’une session pour couper. Elles détruisent les états dès la fin de la plage horaire, quitte à interrompre des opérations critiques.
Chez DYB, nous conseillons à nos clients :
- de tester en environnement de préproduction l’impact des règles horaires,
- de forcer un reset des states après création/modification de règle pour valider le comportement,
- et de sécuriser les sauvegardes avec des logiciels capables de relancer automatiquement une tâche en cas de coupure réseau.