Le ping passe, mais aucune connexion TCP ne sort : une passerelle dupliquée entre switch cœur et pfSense

Le symptôme

Le serveur du portail B2B venait d'être installé dans sa DMZ : un VLAN dédié sur le switch cœur, un réseau /30, et pfSense comme unique passerelle. Avant d'ouvrir le portail, il devait joindre le dépôt de Wazuh pour installer son agent, puis le SIEM interne.

Rien ne sortait. Un test de connexion TCP vers un DNS public échouait (TcpTestSucceeded : False), alors que le ping passait. Le blocage a duré plusieurs semaines avant l'ouverture : le temps de trouver la bonne question.

Ce que le symptôme écarte déjà

Avant de toucher à quoi que ce soit, le symptôme permettait déjà de raisonner :

• Le ping passe : le serveur a une adresse, un lien et un chemin vers sa passerelle. Le câblage, le VLAN du port et l'adressage ne sont pas en cause.
• Le test vise une adresse IP, pas un nom : le DNS n'intervient pas.
• Ce qui échoue, ce sont des connexions TCP, qui demandent un aller et un retour cohérents. La question devient : par où passent les paquets, et que fait le pare-feu de leur réponse ?

Ce que montre la table d'états

pfSense garde une trace de chaque connexion qu'il autorise : un « état ». La commande pfctl -ss les affiche. Pour une même connexion sortante du serveur, les paquets SYN apparaissaient tantôt sur l'interface DMZ du pare-feu, tantôt sur l'interface de liaison avec le switch cœur.

Or la politique d'états était liée à l'interface (if-bound) : un état créé sur une interface ne vaut que pour elle. Quand la réponse revenait par l'autre chemin, elle ne retrouvait pas son état et le pare-feu la rejetait. Un paquet qui entre dans un pare-feu par deux portes différentes, c'est le signe que quelque chose, en amont, l'y envoie par deux chemins.

Qui répond à la passerelle ?

Pour joindre sa passerelle, le serveur demande en ARP : « qui a cette adresse ? », puis envoie ses trames à l'équipement qui répond. Si deux équipements portent la même adresse, le serveur retient l'un ou l'autre selon le moment.

Sur le switch cœur, show ip interface brief a donné la réponse : l'interface virtuelle (SVI) du VLAN de la DMZ portait la même adresse IP que l'interface DMZ du pare-feu. Selon la réponse ARP retenue, le serveur envoyait son trafic directement au pare-feu, ou au switch, qui le routait vers le pare-feu par sa liaison.

La correction, sans casser le reste

Le switch cœur porte tout le réseau de l'entreprise : avant de modifier l'interface, j'ai vérifié qu'elle ne servait à rien d'autre. Sa configuration et la table de routage ne montraient que la route locale du VLAN.

Cisco IOS-XE et pfSense · correction (noms et adresses génériques)

! 1. L'interface du VLAN DMZ porte-t-elle une adresse ?
SW-CORE# show ip interface brief | include Vlan<DMZ>

! 2. Avant de la retirer : rien d'autre ne dépend de cette interface
SW-CORE# show running-config interface Vlan<DMZ>
SW-CORE# show ip route | include <réseau DMZ>

! 3. Plus d'adresse : le VLAN reste actif en couche 2
SW-CORE(config)# interface Vlan<DMZ>
SW-CORE(config-if)# no ip address

# 4. pfSense : purger les seuls états du serveur, les autres sessions restent
pfctl -k <adresse du serveur>

! 5. Enregistrer seulement après validation
SW-CORE# write memory

Après la correction, le pare-feu était le seul à porter l'adresse de la passerelle. Le test TCP a réussi (TcpTestSucceeded : True), le dépôt et le manager Wazuh étaient joignables, et l'agent du serveur est apparu « Active » dans le SIEM avant l'ouverture du portail.

Ce que j'en retiens

• Avant de configurer une passerelle, vérifier qu'aucun équipement du segment ne porte déjà son adresse : table ARP, configuration du switch cœur. Ce contrôle de deux minutes aurait évité plusieurs semaines de blocage.
• Lire la table d'états d'un pare-feu quand « le ping passe mais pas le TCP » : un état créé sur une interface et une réponse arrivée par une autre trahissent un chemin asymétrique.
• Modifier le cœur de réseau comme une opération à risque, même pour une seule ligne : vérifier les dépendances, ne purger que ce qui est en cause, enregistrer seulement après validation.