NAT sur pfSense : NAT sortant, redirection de port et NAT 1:1

Le NAT (Network Address Translation, traduction d'adresses) remplace une adresse IP, et souvent un port, dans les paquets qui traversent le pare-feu. Sur pfSense, il prend trois formes : le NAT sortant, qui fait sortir les réseaux privés sur Internet avec l'adresse publique ; la redirection de port (port forward), qui publie un service interne sur un port de l'adresse publique ; le NAT 1:1, qui associe une adresse publique entière à un serveur. Ce chapitre configure les trois chez Sorbier, explique dans quel ordre pfSense traduit et filtre, et règle le cas des utilisateurs internes qui visitent le site public de l'entreprise.

Pourquoi traduire

Les réseaux de Sorbier utilisent des adresses privées (192.168.10.0/24), qui ne circulent pas sur Internet. L'opérateur lui a attribué six adresses publiques, de 203.0.113.17 à 203.0.113.22. Le NAT fait le lien : les postes sortent avec l'adresse publique du pare-feu, et les clients d'Internet joignent le serveur web en visant cette même adresse. Le principe de la traduction et de la table PAT est expliqué dans le cours Réseaux ; celle d'un routeur Cisco dans le cours Routage et commutation.

Dans quel ordre pfSense traduit et filtre

Pour le trafic qui entre par une interface, pfSense applique la redirection avant les règles de filtrage. Pour le trafic qui sort par le WAN, le NAT sortant s'applique après le filtrage.

Conséquence directe, la plus importante du chapitre : la règle de filtrage qui autorise un flux redirigé vise l'adresse interne du serveur, pas l'adresse publique. Quand la règle est examinée, l'adresse de destination du paquet a déjà été remplacée.

Le NAT sortant

Firewall > NAT > Outbound propose quatre modes :

En mode automatique, la section Automatic Rules liste les règles générées : une ligne par réseau interne (les sept VLAN de Sorbier, les réseaux VPN), traduite vers WAN address. pfSense les crée pour les réseaux des interfaces sans passerelle, ce qui explique le piège de la passerelle de trop vu au chapitre 3. Une règle particulière garde le port source d'origine (Static Port) pour l'UDP 500, le port d'IKE, utile aux VPN IPsec établis depuis l'intérieur.

Le trafic entre deux réseaux internes, et entre le siège et Mâcon dans le tunnel IPsec, n'est jamais traduit : seul ce qui sort par le WAN l'est.

Publier srv-web : la redirection de port

Les clients de Sorbier suivent leurs livraisons sur https://suivi.sorbier.example, dont l'enregistrement DNS public pointe vers 203.0.113.17. Le site est sur srv-web, 192.168.10.225, en DMZ. Firewall > NAT > Port Forward > Add :

Une seconde redirection publie le port 80, pour que srv-web redirige les visiteurs vers HTTPS (et pour le renouvellement de son certificat Let's Encrypt par le défi HTTP).

Le choix Filter rule association :

• Add associated filter rule (le défaut, à garder) : la règle de filtrage est liée à la redirection ; modifier l'une met l'autre à jour, et la règle ne se modifie pas seule ;
• Add unassociated filter rule : une règle indépendante, qu'il faudra tenir à jour soi-même ;
• Pass : aucune règle visible, le trafic redirigé est autorisé directement ; à éviter, la politique devient illisible dans l'onglet WAN ;
• None : aucune règle ; tu l'écris toi-même, et sans elle le trafic redirigé est bloqué.

La règle créée dans l'onglet WAN se lit : Pass, TCP, source any, destination 192.168.10.225 (l'adresse interne), port 443, avec la description « NAT HTTPS vers srv-web ».

Changer de port au passage. La redirection peut traduire le port : un port public 8443 vers le port interne 443, par exemple. Cela ne cache rien à un balayage de ports et n'apporte aucune sécurité ; on s'en sert seulement quand deux serveurs internes doivent être publiés sur le même port avec une seule adresse publique (sinon, voir le proxy inverse du chapitre 7).

Les utilisateurs internes et le site public

Un salarié de Sorbier tape https://suivi.sorbier.example depuis son poste. Son DNS lui répond 203.0.113.17, l'adresse publique. Le paquet part vers le pare-feu… par l'interface POSTES, pas par le WAN : la redirection, définie sur le WAN, ne s'applique pas, et le poste tombe sur l'interface web du pare-feu (ou sur la règle qui l'interdit). Deux solutions :

Chez Sorbier, les postes utilisent le DNS de l'Active Directory : c'est là qu'on crée le DNS partagé. Une zone qui porte exactement le nom du site évite de masquer le reste de sorbier.example :

# Sur srv-ad : une zone dédiée au seul nom suivi.sorbier.example, répliquée dans l'annuaire
Add-DnsServerPrimaryZone -Name "suivi.sorbier.example" -ReplicationScope "Forest"
# L'enregistrement de la racine de la zone pointe vers l'adresse privée de srv-web
Add-DnsServerResourceRecordA -ZoneName "suivi.sorbier.example" -Name "@" -IPv4Address 192.168.10.225

Les machines qui utilisent le résolveur du pare-feu (la DMZ, les visiteurs) reçoivent la même réponse grâce à une substitution d'hôte : Services > DNS Resolver > Host Overrides > Add, Host suivi, Domain sorbier.example, IP Address 192.168.10.225. Le flux interne vers srv-web est alors un flux ordinaire entre deux zones, autorisé par une règle (la règle 5 de l'onglet POSTES au chapitre 5).

La réflexion NAT se règle globalement dans System > Advanced > Firewall & NAT, section Network Address Translation (Disabled par défaut, Pure NAT ou NAT + Proxy), ou redirection par redirection avec le champ NAT reflection.

Le NAT 1:1

Un NAT 1:1 associe une adresse publique entière à une adresse privée : tout ce qui arrive sur l'adresse publique est traduit vers le serveur, et tout ce que le serveur envoie vers Internet sort avec cette adresse publique. Il sert quand un serveur a besoin de sa propre adresse publique, en entrée comme en sortie : un relais de messagerie (le DNS inverse de l'adresse d'envoi doit correspondre au nom du serveur), un serveur de téléphonie, un service qui utilise de nombreux ports.

Si Sorbier installait un relais de messagerie srv-mail en DMZ (192.168.10.231), avec l'adresse publique 203.0.113.20 :

1. Firewall > Virtual IPs > Add : Type IP Alias, Interface WAN, Address 203.0.113.20/29, description « IP publique srv-mail ». Le pare-feu répond désormais aux requêtes ARP de la box pour cette adresse. (Le type Proxy ARP fait la même chose sans que le pare-feu puisse utiliser l'adresse pour ses propres services ; le type CARP sert à la haute disponibilité.)
2. Firewall > NAT > 1:1 > Add : Interface WAN, External subnet IP 203.0.113.20, Internal IP 192.168.10.231 (Single host), Destination any, description « 1:1 srv-mail ».
3. Firewall > Rules > WAN : une règle Pass, TCP, source any, destination 192.168.10.231, port 25. Le NAT 1:1 ne crée aucune règle : sans elle, tout est bloqué, et c'est très bien ainsi.

Vérifier le NAT

• Diagnostics > States : la colonne Source (Original Source) -> Destination (Original Destination) montre les adresses après traduction, et entre parenthèses celles d'origine. Pour la navigation d'un poste, la ligne de l'interface WAN se lit 203.0.113.17:7135 (192.168.10.88:51544) -> 198.51.100.80:443 : l'adresse publique et le port choisi par le pare-feu, puis l'adresse réelle du poste.
• Depuis l'extérieur (un téléphone en 4G), ouvrir https://suivi.sorbier.example, et vérifier le journal de srv-web : l'adresse source vue par le serveur est celle du client d'Internet, car la redirection ne traduit que la destination.
• Si le serveur publié ne répond pas, vérifie dans l'ordre : la redirection, la règle associée dans l'onglet WAN, la passerelle par défaut du serveur (elle doit être le pare-feu, 192.168.10.238 : sinon la réponse part ailleurs et le client attend toujours), le pare-feu local du serveur.

Exercices