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 sur l’équipement qui conserve l’ancienne entrée 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 Appliance.

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.

Pour contrôler plutôt le cache ARP ou NDP local de Sophos Firewall, consulter Contrôler le cache des voisins ARP et NDP. L’article explique aussi quand vider le cache et quand le problème reste situé chez le fournisseur ou sur l’équipement en amont.

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. Au-delà de trois alias, SFOS n’affiche d’abord que trois adresses. Survolez une adresse visible et faites défiler la liste avant de recréer un alias qui semble absent.
2. Si les adresses alias appartiennent à un autre sous-réseau, les hôtes internes doivent utiliser Sophos Firewall comme passerelle par défaut et l’équipement en amont doit disposer, dans chaque sous-réseau d’alias, d’une adresse servant de passerelle accessible au pare-feu. Selon Sophos, plusieurs interfaces WAN distinctes dans le même sous-réseau provoquent des problèmes ARP et rendent les passerelles inaccessibles ; utilisez des interfaces alias ou LAG selon l’architecture.
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, activez la capture et ouvrez Display filter. Pour le contrôle de couche 2, sélectionnez Interface name et Ethernet type: ARP. Pour le service, utilisez Ethernet type: IPv4, la Destination IP concernée et, si nécessaire, Destination port. Sans Wrap capture buffer once full, la capture s’arrête lorsque le tampon de 2048 Ko est plein ; cliquez sur Clear, puis répétez le test reproductible. Si l’option est activée, la capture reprend au début du tampon et écrase les paquets plus anciens.
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 IPv4 sur le WAN : contrôlez les entrées ARP en amont, le routage du fournisseur, le CPE ou le commutateur en amont.
• État Incoming ou Violation : le paquet atteint le pare-feu. Pour Violation, Reason, la règle de pare-feu, la règle DNAT, la zone et le service fournissent les indices suivants.
• État Forwarded, mais aucune réponse : 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 sur 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, Sophos indique le redémarrage du routeur concerné comme solution de remplacement. Cette opération doit avoir lieu dans une fenêtre de maintenance, car elle interrompt d’autres connexions et ne peut pas être annulée. La suppression d’une entrée dynamique ne nécessite pas de restauration de configuration : le routeur la réapprend. En cas de retour à l’ancienne appliance, supprimez de nouveau l’entrée après l’avoir reconnectée afin que son ancienne adresse MAC soit réapprise. 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.

Ce correctif ne nécessite aucune commande supplémentaire dans la Device Console. L’aide actuelle de SFOS 22 prescrit explicitement de vider le cache du routeur ou de redémarrer celui-ci pour les entrées ARP d’alias obsolètes. Si le fournisseur route les adresses au lieu de les résoudre localement par ARP, ces deux actions sur une entrée d’alias restent sans effet ; contrôlez plutôt la route du fournisseur et la configuration locale de l’alias ou du NAT.

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’appareil principal répond aux requêtes ARP avec l’adresse MAC virtuelle de l’interface. Seules les appliances virtuelles pour lesquelles Use host or hypervisor-assigned MAC address est sélectionné utilisent à la place l’adresse MAC attribuée par l’hôte ou l’hyperviseur.

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 de la suppression du cache ou du redémarrage ;
• 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 routeur redémarré dans une fenêtre de maintenance convenue.
• 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