NAT sortant pfSense : lisez d’abord les règles générées
Les pools VPN d’accès à distance sont souvent déjà couverts par les règles générées par pfSense. Lisez d’abord le mode, puis décidez si une exception Hybrid est justifiée.
Ouvrez Firewall, puis NAT, puis Outbound, et lisez le mode avant d’ajouter quoi que ce soit. En mode Automatic, pfSense génère des règles pour les interfaces WAN et, parmi elles, pour les réseaux VPN d’accès à distance, si bien que le pool que vous allez ajouter est souvent déjà couvert. L’absence d’une ligne écrite à la main ne prouve pas que la traduction manque. L’ordre ci-dessous vous évite de basculer tout le pare-feu en Manual pour résoudre un seul pool.
Le mode décide qui assure la traduction pour chaque autre réseau de la machine, et c’est une décision plus lourde qu’une exception VPN.
Le mode Automatic couvre déjà le pool VPN
Chaque mode a un propriétaire distinct. Automatic génère des règles pour les interfaces WAN et inclut les réseaux VPN d’accès à distance parmi ses sources. Hybrid conserve ces règles générées et vous laisse ajouter des règles manuelles à côté. Manual cesse de générer quoi que ce soit, si bien que chaque traduction du pare-feu devient votre responsabilité, y compris celles que vous n’avez pas écrites. Un quatrième réglage désactive entièrement le NAT sortant. Une ligne qui semble écrite à la main ne prouve rien tant que vous ne savez pas quel mode est actif.
En Automatic et Hybrid, la page affiche aussi les règles générées. Lisez-les avant de conclure qu’un pool VPN n’a pas de traduction : cherchez le réseau du pool dans la colonne source et l’interface WAN dans la colonne interface.
Ne choisissez Hybrid que pour une exception examinée
Une exception documentée reste possible lorsque la politique de sortie diffère réellement. Imaginez un serveur qui distribue 10.90.0.0/24, où le pare-feu doit fournir une sortie Internet IPv4 et où le routage choisit déjà le WAN. La transformation attendue est que la source 10.90.0.23 soit réécrite vers l’adresse WAN. Vérifiez si une règle générée le fait déjà sur cette sortie ; sinon, Hybrid préserve la couverture automatique tout en ajoutant votre règle examinée.
Utilisez le pool VPN réel comme source, ou un alias pris en charge pour celui-ci, et ne choisissez jamais une adresse sans rapport simplement parce que le nom de l’instance OpenVPN manque dans un sélecteur. Évitez une source any, qui traduit aussi le trafic que le pare-feu émet lui-même.
Ne basculez pas tout le pare-feu en Manual pour un seul pool. Cette décision réattribue la maintenance de chaque réseau interne et de chaque futur changement WAN.
Le NAT ne choisit pas la sortie
Le routage choisit l’interface de sortie ; une règle NAT sortante décrit seulement comment la source est réécrite une fois le paquet parti. Un mappage pour le WAN ne force pas un paquet que le routage a envoyé ailleurs à passer par le WAN, et c’est pourquoi ajouter du NAT ne peut pas réparer une mauvaise route. Inspectez aussi les entrées NAT 1:1 applicables et les exceptions, car l’ordre compte et une nouvelle ligne ne gagne pas forcément. Et la page sortante n’est pas la page de filtrage.
Une source traduite n’est pas une autorisation d’atteindre n’importe quelle destination. Les clients ont toujours besoin d’une route par le tunnel et d’une règle de pare-feu qui admet leur trafic, et la sortie choisie a besoin d’un chemin de retour fonctionnel. Gardez l’accès LAN uniquement séparé de l’autorisation de sortie Internet.
Prouvez la transformation sur une nouvelle connexion
Après un changement approuvé, testez avec une nouvelle connexion autorisée plutôt qu’en réutilisant une connexion existante, car les états établis conservent leur traduction antérieure. Confirmez l’adresse source qui quitte réellement le WAN et que la réponse revient par le même état. Ne videz pas toute la table d’états comme premier geste ; cela masque quelle règle a changé le résultat. Notez le mode, la règle, le pool et la sortie dans le ticket de changement.
Cet exemple ne couvre que la sortie IPv4. Il ne dit rien d’une traduction ou d’une politique de filtrage IPv6, et une conception qui en a besoin doit l’énoncer séparément. L’enregistrement final liste le trafic client autorisé, l’interface qui le porte et la raison pour laquelle la source doit être réécrite.