Résoudre les problèmes ARP après une migration Sophos Firewall

Après un changement de pare-feu, le nouveau Sophos Firewall peut être en ligne alors que certaines adresses IP publiques configurées comme alias restent inaccessibles. Souvent, le routeur en amont associe encore ces adresses à l’adresse MAC WAN de l’ancienne appliance. Les paquets n’atteignent alors même pas le nouveau pare-feu, bien que l’alias, la règle DNAT et la règle de pare-feu semblent correctement configurés.

Ce guide montre comment diagnostiquer ce problème IPv4 en contrôlant l’interface, Packet Capture et les entrées ARP en amont. Le cache ARP n’est mis à jour de manière ciblée ou un ping ARP n’est déclenché dans la Device Console qu’une fois la cause de couche 2 confirmée. Pour une migration matérielle générale, consultez également Comparer Sophos XG et XGS.

Quand faut-il réellement suspecter ARP ?

Le problème apparaît généralement juste après le remplacement d’une appliance, une restauration ou un changement de fabricant. L’adresse IP publique reste identique, mais l’adresse MAC de l’interface WAN change.

Les indices les plus probants sont les suivants :

• L’adresse IP principale de l’interface WAN fonctionne, mais pas une ou plusieurs adresses IP alias.
• Un test externe n’atteint pas un service publié sur certaines adresses IP publiques.
• Packet Capture ne montre aucun paquet entrant destiné à l’adresse IP concernée.
• Le service se met soudainement à fonctionner après l’expiration d’un cache en amont, sans autre modification du pare-feu.
• Le routeur en amont indique encore l’adresse MAC de l’ancienne appliance pour l’adresse IP publique.

ARP n’est pas automatiquement en cause. Si les paquets arrivent sur l’interface WAN, il faut ensuite contrôler la règle DNAT, la règle de pare-feu, la zone, le serveur interne ou la route de retour. Cette procédure ne s’applique pas non plus à IPv6, qui utilise Neighbor Discovery pour la résolution des voisins.

Pourquoi des IP alias peuvent-elles tomber en panne après un remplacement ?

ARP associe une adresse IPv4 à une adresse MAC dans un segment local de couche 2. Un routeur enregistre cette association dans son cache ARP. Après le remplacement, l’équipement en amont devrait apprendre l’adresse MAC WAN du nouveau pare-feu. Si cela ne se produit pas pour une IP alias, il continue d’envoyer les paquets à l’ancien matériel.

Cela explique pourquoi l’adresse IP principale peut fonctionner alors qu’une IP alias est inaccessible : l’équipement en amont conserve une entrée distincte pour chaque adresse IP. Une association peut déjà être à jour tandis qu’une autre pointe encore vers l’ancienne adresse MAC.

Il faut toutefois commencer par déterminer comment le fournisseur met les adresses publiques à disposition :

• Réseau directement connecté : l’équipement en amont résout les adresses IP principales et alias par ARP. Des entrées obsolètes sont plausibles après un changement de matériel.
• Bloc public routé : le fournisseur route le bloc vers l’adresse IP WAN principale. Une entrée ARP propre à chaque adresse IP publique n’est alors pas forcément attendue ; la route du fournisseur et la configuration locale des alias ou du NAT sont plus importantes.

Diagnostic avant toute intervention

Le diagnostic doit d’abord déterminer à quel endroit le flux de paquets s’interrompt. On évite ainsi de modifier simultanément ARP, le NAT et les règles de pare-feu.

1. Sous Network > Interfaces, contrôlez l’interface WAN physique et les adresses concernées. Une IP alias est liée à la bonne interface physique via Add interface > Add alias ; la version IP, l’adresse et le masque de sous-réseau doivent correspondre à la conception du réseau.
2. Si les adresses alias appartiennent à un autre sous-réseau, vérifiez que l’équipement en amont de ce sous-réseau est accessible comme passerelle depuis le pare-feu. Plusieurs interfaces WAN distinctes dans le même sous-réseau ne constituent pas une conception propre et peuvent elles-mêmes provoquer des problèmes ARP ; selon l’architecture, il convient d’utiliser des interfaces alias ou LAG.
3. Depuis un système de test réellement externe, testez la même adresse IP publique et le même service. Un ping seul ne suffit pas, car ICMP peut être bloqué ; ajoutez de préférence un test sur un port TCP connu.
4. Sous Diagnostics > Packet capture, effectuez une capture sur l’interface WAN. Pour le contrôle de couche 2, filtrez par interface et par Ethernet type: ARP ; pour le service, filtrez ensuite par adresse IP de destination concernée et par protocole.
5. Ce n’est que lorsque les paquets IP arrivent qu’il faut rechercher dans le Log viewer l’adresse IP de destination, le service, la Firewall Rule ID et la NAT Rule ID. ARP s’analyse avec Packet Capture, pas dans le journal habituel d’une règle de pare-feu.

Utiliser Packet Capture sur Sophos Firewall explique l’affichage plus en détail. Pour contrôler l’interface, la zone et l’affectation de l’alias, consultez Configurer les zones et interfaces de Sophos Firewall.

Les observations orientent clairement la suite du diagnostic :

• Aucun paquet sur le WAN : contrôlez les entrées ARP en amont, le routage du fournisseur, le CPE ou le commutateur en amont.
• Les paquets arrivent et sont rejetés : contrôlez la règle de pare-feu, la règle DNAT, la zone et le service.
• Les paquets sont transférés vers le réseau interne, mais aucune réponse ne revient : contrôlez la route de retour, le serveur interne, le SNAT et le pare-feu du serveur.
• Seule l’IP alias est concernée : comparez précisément la configuration de l’alias et l’entrée en amont correspondant à cette adresse IP.

Mettre à jour l’association ARP de manière ciblée

Vider le cache de l’équipement en amont

La correction la plus propre s’effectue sur l’appareil qui conserve l’entrée erronée. Si vous administrez le routeur en amont ou le CPE du fournisseur, supprimez de manière ciblée l’entrée ARP de l’adresse IP concernée. L’équipement en amont doit ensuite apprendre la nouvelle adresse MAC WAN.

Si une suppression ciblée n’est pas possible, le redémarrage du routeur concerné peut également renouveler le cache. Cette opération doit avoir lieu dans une fenêtre de maintenance, car elle interrompt d’autres connexions. Pour un équipement géré par le fournisseur, communiquez-lui l’adresse IP concernée, l’ancienne et la nouvelle adresse MAC ainsi que le CPE responsable, au lieu de redémarrer sans distinction toute la chaîne réseau.

Déclencher un ping ARP depuis la Device Console

Sophos Firewall propose un diagnostic ARP dans la Device Console. En utilisant l’adresse IP source concernée et l’interface WAN, le ping ARP peut déclencher une mise à jour sur l’équipement en amont directement connecté.

Après vous être connecté à la console ou en SSH, ouvrez Option 4: Device Console et exécutez la commande avec les valeurs réelles :

system diagnostics utilities arp ping source <alias-ip> interface <wan-interface> <upstream-gateway>

Exemple avec des adresses réservées à la documentation :

system diagnostics utilities arp ping source 198.51.100.21 interface Port2 198.51.100.1

Dans cet exemple, 198.51.100.21 est l’adresse IP alias concernée sur Port2 ; 198.51.100.1 est l’équipement en amont directement accessible dans le même segment de couche 2. L’adresse IP source, l’interface et la destination doivent être cohérentes. Si plusieurs IP alias sont concernées, testez chaque adresse séparément afin de pouvoir attribuer précisément l’effet observé.

Cette commande ne corrige ni une mauvaise configuration d’alias ni une entrée ARP statique erronée chez le fournisseur. Si le fournisseur route les adresses au lieu de les résoudre localement par ARP, le ping ARP n’est pas non plus la solution appropriée. Se connecter à Sophos Firewall en SSH décrit comment accéder en toute sécurité à la Device Console.

Valider l’accessibilité après la correction

Après chaque mesure individuelle, répétez exactement le même test. Il reste ainsi possible d’identifier ce qui a effectivement résolu le problème.

1. Sur l’équipement en amont, vérifiez que l’adresse IP concernée pointe désormais vers la nouvelle adresse MAC WAN.
2. Répétez le test externe de ping ou de port TCP avec la même source et la même destination.
3. Dans Packet Capture, vérifiez que les paquets arrivent maintenant sur l’interface WAN.
4. Si les paquets arrivent, contrôlez la Firewall Rule ID et la NAT Rule ID dans le Log Viewer.
5. Testez le service publié jusqu’au serveur interne, ainsi que le chemin de retour.

Une entrée ARP actualisée prouve uniquement que l’équipement en amont peut transmettre les paquets au nouveau pare-feu. Le fonctionnement du service dépend toujours de la règle DNAT, de la règle de pare-feu, de la cible interne et de la route de retour. Pour publier un serveur, Publier un serveur via DNAT présente l’ensemble du chemin de règles.

Si le problème persiste

Si l’adresse IP reste inaccessible malgré une entrée ARP actualisée, n’essayez pas d’autres commandes Shell au hasard : changez d’hypothèse.

Les autres causes fréquentes sont les suivantes :

• L’IP alias se trouve sur la mauvaise interface physique ou utilise un masque de sous-réseau incorrect.
• Le fournisseur route le bloc public autrement que prévu.
• Une entrée ARP ou MAC statique en amont prend le pas sur l’apprentissage dynamique.
• Un commutateur en amont conserve une ancienne association MAC ou utilise Port Security.
• La règle DNAT pointe vers une autre adresse IP publique.
• La règle de pare-feu n’autorise pas la source, le service ou la zone.
• Le serveur interne répond via une autre passerelle.
• Dans une configuration HA, l’adresse MAC virtuelle ou physique attendue n’est pas la bonne.

Une perte ARP qui se reproduit durablement ne doit pas non plus être contournée par une commande personnalisée exécutée périodiquement. Le fournisseur, le CPE, la conception de couche 2 et, si nécessaire, Sophos Support doivent alors en déterminer la cause.

Impliquer précisément le fournisseur ou l’équipe en amont

Si la capture WAN ne montre aucun paquet destiné à l’adresse IP concernée, le fournisseur a besoin d’un constat précis, et non d’un simple signalement indiquant que le pare-feu est inaccessible.

Préparez les informations suivantes :

• l’adresse IP principale ou alias concernée ;
• l’interface WAN et la nouvelle adresse MAC ;
• la passerelle en amont ou le CPE ;
• l’heure du test externe et du ping ARP ;
• le résultat de Packet Capture ;
• le mode de mise à disposition attendu, sous forme de réseau directement connecté ou de réseau routé ;
• les résultats obtenus pour l’adresse IP principale et les autres IP alias.

Le fournisseur peut ainsi contrôler l’entrée ARP précise, une association statique ou la route vers le bloc public. Les données de configuration sensibles ou les captures de paquets complètes ne doivent être transmises que par un canal d’assistance convenu.

Contrôle final compact

• Adresses IP principales et alias ainsi que mode de mise à disposition documentés.
• Interface physique, version IP et masque de sous-réseau contrôlés.
• Test TCP externe et Packet Capture effectués avec les mêmes destinations.
• Trafic ARP et trafic IP analysés séparément lors du diagnostic.
• Entrée en amont supprimée de manière ciblée ou ping ARP exécuté avec les bons paramètres.
• Nouvelle association MAC confirmée sur l’équipement en amont.
• Règle DNAT, Firewall Rule ID, NAT Rule ID et chemin de retour contrôlés ensuite.
• Cause et mesure consignées dans le ticket de changement ou le journal de migration.

FAQ