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

Après une migration de pare-feu, il peut arriver que le nouveau Sophos Firewall soit généralement en ligne, mais que certaines adresses IP publiques ou alias ne soient pas accessibles. Cela est particulièrement typique après un passage d’un autre fabricant à Sophos Firewall ou après une migration de matériel XG à XGS. Les adresses IP restent les mêmes, mais l’adresse MAC de l’interface WAN change.

Si un routeur en amont, un CPE du fournisseur ou un commutateur a encore d’anciennes entrées ARP dans le cache, il continue d’envoyer des paquets à l’ancienne adresse MAC. Cela donne l’impression que seules certaines adresses IP alias, cibles DNAT ou tests de ping ne fonctionnent pas. Pour la planification générale de la migration, l’article Quelle est la différence entre un pare-feu XG et XGS ? est également utile.

Symptômes typiques

Les problèmes ARP après une migration apparaissent généralement directement après le changement ou après une restauration sur un nouveau matériel.

Indications typiques :

L’interface WAN du Sophos Firewall est en ligne.
L’adresse IP principale fonctionne, mais certaines adresses IP alias ne fonctionnent pas.
Le ping sur certaines IP publiques échoue, d’autres IP sur la même interface répondent.
Les règles DNAT ou WAF semblent correctement configurées, mais n’atteignent pas le serveur interne.
Un service est accessible en interne, mais perturbé de l’extérieur uniquement sur certaines IP publiques.
Après un certain temps, cela fonctionne soudainement, car un cache ARP expire automatiquement.

Il est important de faire la distinction : tous les problèmes d’accessibilité après une migration ne sont pas des problèmes ARP. Les règles de pare-feu, les règles NAT, les zones, la configuration des alias, le routage du fournisseur et les routes de retour doivent également être vérifiés.

Pourquoi l’ARP peut perturber après une migration

L’ARP résout les adresses IPv4 en adresses MAC. Dans un segment local de couche 2, un appareil demande : Quelle adresse MAC appartient à cette adresse IP ? La réponse est stockée dans le cache ARP, afin que chaque paquet n’entraîne pas une nouvelle requête ARP.

Lors d’une migration de pare-feu, l’adresse IP reste souvent la même, mais l’adresse MAC change. Cela peut être problématique :

Le routeur du fournisseur connaît encore l’IP publique avec l’ancienne adresse MAC.
Un commutateur ou routeur en amont conserve des entrées ARP obsolètes.
Une IP alias a été correctement configurée sur le nouveau pare-feu, mais le voisin continue d’envoyer à l’ancien matériel.
Seule une partie des IP a déjà été réapprise, c’est pourquoi certaines adresses fonctionnent et d’autres non.

Pour les adresses IP alias individuelles, cela est particulièrement déroutant, car la connexion de base semble fonctionner. On regarde alors rapidement dans NAT, les règles de pare-feu ou le routage, bien que l’erreur se produise déjà avant, sur la couche 2.

Vérifier avant la commande CLI

Avant de forcer activement l’ARP, la configuration de base doit être correcte. Sinon, un ping ARP ne fera que masquer un autre problème.

Vérifiez :

Sous Network > Interfaces, vérifiez si l’adresse IP ou l’adresse IP alias concernée se trouve sur la bonne interface.
Vérifiez la zone de l’interface, par exemple WAN.
Vérifiez la passerelle, le masque de sous-réseau et la logique du réseau alias.
Sous Rules and policies > NAT rules, vérifiez si la règle DNAT pointe vers la bonne IP publique.
Sous Rules and policies > Firewall rules, vérifiez si une règle appropriée pour le trafic existe.
Dans le Log Viewer, vérifiez si les paquets arrivent sur le pare-feu.
Si nécessaire, utilisez Sophos Firewall Packet Capture dans WebAdmin pour vérifier si les paquets entrants sont visibles sur l’interface WAN.

Si aucun paquet pour l’IP publique concernée n’arrive dans le Packet Capture, le problème se situe probablement avant le pare-feu : routeur du fournisseur, commutateur en amont, cache ARP ou routage chez le fournisseur. Si les paquets arrivent mais sont rejetés, vérifiez d’abord NAT, les règles de pare-feu et les zones. Pour la logique des interfaces et des zones, consultez Configurer les zones et interfaces de Sophos Firewall.

Exécuter un ping ARP via la console de l’appareil

Sophos Firewall peut déclencher un ping ARP avec une IP source et une interface définies via la console de l’appareil. Cela est utile si une IP alias doit être activement annoncée dans le réseau après la migration.

Important : La commande ne doit être exécutée que si l’on sait clairement quelle IP source, quelle interface et quelle cible dans le segment local sont utilisées. Des valeurs incorrectes ne sont pas utiles et peuvent fausser l’analyse. Avant de modifier une migration en production, une sauvegarde actuelle de Sophos Firewall doit être disponible.

La commande est exécutée dans la Device Console, pas dans le Shell avancé :

system diagnostics utilities arp ping source <alias-ip> interface <interface> <target-ip>

Exemple :

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’IP alias concernée sur Port2. 198.51.100.1 est une cible accessible dans le même segment de couche 2, généralement la passerelle en amont ou le CPE du fournisseur. Cela génère du trafic ARP avec la bonne IP source via la bonne interface.

Si SSH n’est pas encore configuré, Connecter Sophos Firewall via SSH décrit comment accéder à la console de l’appareil. Lors des migrations, SSH ne doit pas être autorisé en permanence depuis le WAN. Il est préférable d’avoir un accès administratif temporaire et restreint depuis un réseau de confiance.

Procédure recommandée

1. Recueillir les adresses IP concernées

Commencez par documenter quelles adresses IP fonctionnent et lesquelles ne fonctionnent pas. Pour les adresses IP alias, comparez directement la liste avec la configuration de l’interface.

Notez :

Interface, par exemple Port2
Adresse IP principale et adresses IP alias
Passerelle en amont ou CPE du fournisseur
Règles NAT ou WAF concernées
Résultat du ping, test de port et capture de paquets

2. Délimiter le problème ARP

Depuis un système de test externe, vérifiez l’IP publique concernée. En parallèle, démarrez la capture de paquets sur l’interface WAN du Sophos Firewall.

Interprétation :

Aucun paquet n’arrive à l’interface WAN: Vérifiez l’amont, l’ARP, le routage du fournisseur ou l’appareil en amont.
Les paquets arrivent mais sont rejetés: Vérifiez la règle de pare-feu, NAT, zone ou service.
Les paquets arrivent et passent en interne, mais la réponse manque: Vérifiez la route de retour, le serveur interne, SNAT ou le pare-feu du serveur.
Seule l’IP alias est concernée, l’IP principale fonctionne: Vérifiez spécifiquement le cache ARP ou la configuration de l’alias.

3. Exécuter un ping ARP pour chaque IP alias concernée

Pour chaque IP alias concernée, exécutez le ping ARP avec l’IP source appropriée et la bonne interface. Ensuite, ne changez pas immédiatement plusieurs autres choses, mais testez d’abord si le comportement change.

Exemple avec des espaces réservés :

system diagnostics utilities arp ping source <ip-alias-concernee> interface <interface-wan> <passerelle-amont>

Si plusieurs adresses IP alias sont concernées, exécutez la commande individuellement pour chaque adresse. Cela rend la vérification traçable et empêche de ne plus savoir quelle mesure a aidé à la fin.

4. Valider l’accessibilité

Après le ping ARP, répétez le même test :

Ping ou test de port TCP depuis l’extérieur.
Capture de paquets sur l’interface WAN.
Filtrez le Log Viewer sur l’IP cible concernée.
Vérifiez la règle NAT et de pare-feu si les paquets arrivent maintenant.

Si l’amont apprend correctement les informations ARP, les paquets pour l’IP alias devraient maintenant arriver sur le nouveau pare-feu. Le bon fonctionnement du service publié dépend également de NAT, des règles de pare-feu, du serveur interne et du chemin de retour.

Si le ping ARP n’aide pas

Si le ping ARP n’apporte aucune amélioration, n’essayez pas d’autres commandes au hasard. Une délimitation structurée est alors judicieuse.

Autres vérifications :

L’appareil en amont peut encore conserver des entrées ARP obsolètes.
Le fournisseur doit vider le cache ARP ou recharger le CPE.
L’IP alias se trouve sur la mauvaise interface ou dans un mauvais réseau.
L’IP publique est routée par le fournisseur au lieu d’être apprise directement dans le segment local via ARP.
La règle DNAT pointe vers la mauvaise adresse publique.
La règle de pare-feu n’autorise pas le trafic.
Le serveur interne répond via une autre passerelle.
En cas de HA ou de changement de matériel, la mauvaise adresse MAC a été attendue.

Un redémarrage du CPE du fournisseur ou d’un routeur en amont peut vider les caches ARP, mais ne devrait pas être la première mesure. Dans les environnements de production, il est plus propre de collecter d’abord des preuves avec Packet Capture et Log Viewer.

Impliquer spécifiquement le fournisseur ou l’amont

Si aucun paquet pour l’IP publique concernée n’arrive à l’interface WAN, la demande au fournisseur ou aux responsables en amont doit être aussi précise que possible. Un message général comme “le pare-feu n’est pas accessible” conduit souvent à des boucles inutiles. Il est préférable d’avoir une preuve technique courte montrant quelle IP est concernée et ce qui a été vérifié sur le Sophos Firewall.

Informations utiles :

IP publique ou IP alias concernée: Le fournisseur peut vérifier spécifiquement l’entrée ARP ou de routage.
Interface WAN et nouvelle adresse MAC: Montre quelle correspondance est attendue après la migration.
Passerelle amont ou adresse CPE: Délimite quel appareil voisin doit apprendre l’adresse.
Moment du test de ping ARP: Facilite la correspondance avec les journaux du fournisseur ou l’état du CPE.
Résultat de la capture de paquets: Prouve si les paquets atteignent le Sophos Firewall.
Règle DNAT et de pare-feu vérifiée: Empêche que le cas soit rapidement classé comme un problème de règle locale. L’adresse MAC de l’interface WAN peut être documentée dans l’interface WebAdmin sous Network > Interfaces. Si le fournisseur doit vider un cache ARP ou recharger un CPE, cela doit être lié à l’IP concrète ou à l’interface concernée. Un redémarrage général de tous les appareils impliqués n’est judicieux que si la responsabilité, la fenêtre de maintenance et l’impact sont clairs.

Liste de contrôle

Adresses IP principales et alias concernées documentées.
Interface, zone, passerelle et configuration des alias vérifiées.
Règles NAT et de pare-feu pour l’IP concernée vérifiées.
La capture de paquets montre si les paquets arrivent à l’interface WAN.
Ping ARP exécuté uniquement avec la bonne IP source, interface et IP cible.
Accessibilité externe testée à nouveau après chaque changement.
Si nécessaire, contacter le fournisseur ou les responsables en amont avec l’IP concrète, l’adresse MAC, le moment du test et l’observation de la capture de paquets.

FAQ

Faut-il mettre à jour manuellement l'ARP après chaque migration de pare-feu ?

Non. Dans de nombreux environnements, les appareils voisins apprennent automatiquement la nouvelle adresse MAC. Les mesures ARP manuelles sont surtout pertinentes lorsque certaines adresses IP ne sont pas accessibles après le changement, bien que la configuration du pare-feu semble correcte.

Est-ce un problème de NAT ou un problème d'ARP ?

Si les paquets n’arrivent pas du tout à l’interface WAN dans la capture de paquets, le NAT sur le Sophos Firewall n’est pas encore le premier suspect. Si les paquets arrivent mais ne sont pas transmis, il faut vérifier NAT, les règles de pare-feu, les zones et les chemins de retour internes.

Pourquoi l'IP principale fonctionne-t-elle, mais pas une IP alias ?

L’amont peut avoir appris des entrées ARP différentes pour chaque adresse IP. Ainsi, une IP peut déjà pointer correctement vers la nouvelle adresse MAC, tandis qu’une autre pointe encore vers l’ancien pare-feu.

Faut-il simplement redémarrer les routeurs ou commutateurs ?

Seulement si l’intervention est opérationnellement acceptable et que la responsabilité est claire. Il est préférable de procéder d’abord à une vérification ciblée : capture de paquets sur le Sophos Firewall, statut ARP sur l’appareil en amont et, si possible, vidage ciblé du cache ARP sur l’appareil concerné.

A-t-on besoin de la Advanced Shell pour cela ?

Non. Le ping ARP montré est exécuté dans la console de l’appareil Sophos Firewall. La Advanced Shell n’est pas nécessaire pour cela et devrait être évitée pour des vérifications de migration simples.