Configurer et vérifier Proxy ARP sur Sophos Firewall

Proxy ARP n’est nécessaire sur Sophos Firewall que lorsqu’un équipement du segment IPv4 directement connecté recherche une adresse de destination supplémentaire et que le firewall doit répondre à sa place avec son adresse MAC. Cela peut par exemple se produire avec une IP publique supplémentaire, ensuite redirigée par DNAT vers un serveur interne.

Le point essentiel : Proxy ARP assure uniquement la résolution des voisins avant le véritable chemin de données IP. Il ne crée ni règle de firewall, ni règle NAT, ni route de retour. Il faut donc d’abord confirmer par une capture ARP que cette réponse précise manque. En outre, avant toute modification, l’état initial de la configuration doit être établi pour la combinaison exacte de l’interface et de l’adresse de destination : l’absence de réponse ARP ne prouve pas qu’aucune entrée manuelle n’existe. L’entrée n’est ajoutée et testée avec le service réel que s’il est démontré qu’elle n’est pas encore configurée.

⚠️ Ne pas activer Proxy ARP par précaution pour toute une plage d’adresses publiques. Avant la modification, documenter l’attribution du fournisseur, l’interface, l’état ARP initial, la sauvegarde, un accès d’administration indépendant et le rollback. Une adresse de destination erronée ou dupliquée peut attirer le trafic vers le mauvais firewall.

Proxy ARP en huit étapes

1. Clarifier avec le fournisseur ou l’équipe upstream si l’adresse IPv4 supplémentaire est recherchée par ARP sur le segment WAN ou routée vers le firewall sous forme de préfixe.
2. Exclure que l’adresse soit déjà utilisée comme alias, sur un autre équipement ou par une architecture existante. Établir et documenter l’état initial de la configuration de l’entrée Proxy ARP manuelle pour cette interface précise et cette adresse de destination, à l’aide d’une méthode de lecture confirmée pour le build installé, d’un justificatif actuel et fiable de la configuration ou de Sophos Support. Si cet état est inconnu, arrêter la procédure ; si l’entrée existe déjà, diagnostiquer son fonctionnement au lieu de la recréer ou de l’écraser.
3. Réaliser une capture ARP sur l’interface d’entrée attendue pendant le lancement d’une nouvelle connexion.
4. Continuer uniquement si la requête ARP pour l’adresse de destination arrive, si l’absence de la réponse requise du firewall est démontrée et s’il est confirmé, indépendamment de la capture, que l’entrée manuelle exacte n’est pas encore configurée.
5. Dans la Device Console, ajouter une entrée avec set proxy-arp add pour une seule adresse IPv4 et consigner qu’il a été démontré qu’elle était absente auparavant et qu’elle a été ajoutée par cette procédure.
6. Configurer ou vérifier séparément la règle de firewall, le DNAT ou la route, ainsi que le chemin retour.
7. Tester la réponse ARP, la Firewall Rule ID, la NAT Rule ID et le service réel avec une nouvelle connexion.
8. Répéter le même test après un failover HA. Lors du rollback, supprimer de manière ciblée avec set proxy-arp del uniquement l’entrée dont il a été démontré qu’elle n’était pas configurée auparavant et qui a été ajoutée par cette procédure ; laisser les entrées préexistantes intactes.

Distinguer Proxy ARP, alias et routage

Ce que fait réellement Proxy ARP

Avant qu’un équipement IPv4 puisse envoyer un paquet à un voisin du même segment de couche 2, il doit connaître son adresse MAC. Il envoie pour cela une requête ARP. Avec Proxy ARP, Sophos Firewall répond à une telle requête pour une autre IP de destination avec l’adresse MAC de l’interface sélectionnée.

L’équipement upstream envoie alors les trames Ethernet suivantes au firewall. Ce n’est qu’ensuite que le routage, le NAT et les règles de firewall déterminent le sort du paquet IP. Une réponse ARP correcte ne prouve donc pas encore que le service publié fonctionne.

La commande Device Console documentée par Sophos concerne ARP et donc IPv4. IPv6 utilise Neighbor Discovery pour la découverte des voisins. Cette commande ne permet pas de déduire une procédure Proxy NDP.

Quelle variante correspond à l’attribution du fournisseur

• IP alias : l’adresse supplémentaire est liée localement à une interface physique du firewall. Cette variante convient lorsque le firewall doit posséder l’adresse ou l’utiliser précisément pour le NAT ou le trafic système. Configurer une IP alias sur Sophos Firewall présente la procédure complète.
• Proxy ARP : le firewall répond au nom d’une adresse IPv4 redirigée ou traduite. Cette commande n’ajoute pas l’adresse comme adresse d’interface normale.
• Préfixe routé : l’équipement upstream route un réseau entier vers l’adresse WAN ou vers un next hop convenu. Il ne recherche alors normalement pas chaque adresse de destination de ce préfixe par ARP sur le segment WAN. Une entrée Proxy ARP manuelle serait une correction inadaptée.
• Voisin statique : il associe une adresse MAC fixe à un voisin directement accessible. Il s’agit du sens de consultation inverse et non d’un substitut à Proxy ARP. La distinction est expliquée dans Vérifier le cache de voisins ARP et NDP.

Une règle DNAT ne signifie pas non plus automatiquement qu’un Proxy ARP manuel est nécessaire. Il faut d’abord tester le chemin de données existant. Une nouvelle entrée CLI n’est justifiée que si l’architecture du fournisseur et la capture démontrent réellement l’absence de réponse ARP et s’il est démontré que l’entrée exacte est absente de l’état initial documenté de la configuration.

Exemple et valeurs à remplacer

L’exemple utilise une attribution IPv4 publique directement connectée. Un service HTTPS doit être accessible via l’adresse supplémentaire 203.0.113.10 :

• Interface WAN : Port2
• Adresse WAN du firewall : 203.0.113.9/29
• Gateway du fournisseur : 203.0.113.14
• IP publique de destination supplémentaire : 203.0.113.10
• Hôte de test externe : 198.51.100.25
• Serveur interne : 10.20.40.20
• Service : HTTPS

203.0.113.0/24 et 198.51.100.0/24 sont des réseaux réservés à la documentation. Ils ne fonctionnent pas comme adresses de production et doivent être entièrement remplacés par l’attribution réelle du fournisseur et un hôte de test externe autorisé. Port2 n’est également qu’un exemple ; il faut utiliser exactement l’interface sur laquelle la requête ARP arrive de manière démontrée.

Le masque /29 n’est pas repris dans la commande Proxy ARP. Il sert uniquement à expliquer le réseau d’exemple. L’entrée elle-même s’applique volontairement uniquement à 203.0.113.10. Une plage entière ne doit recevoir de réponse que lorsque la propriété, l’utilisation et la syntaxe sont clairement documentées pour chaque adresse et testées sur le build utilisé.

Vérifier le chemin du fournisseur et ARP avant la modification

Avant d’utiliser la CLI, il faut distinguer trois observations possibles :

1. Aucune requête ARP n’atteint le firewall : le chemin du fournisseur, le VLAN, le port du switch ou l’hypothèse sur l’attribution doivent être clarifiés avant l’étape Proxy ARP.
2. La requête arrive et un équipement répond déjà : ne pas générer une seconde réponse. Identifier d’abord le propriétaire de l’adresse MAC visible.
3. La requête arrive, mais personne ne répond : cette observation montre l’absence de réponse ARP, et non l’absence d’une entrée Proxy ARP manuelle configurée. La configuration doit être vérifiée indépendamment.

Pour la capture, se connecter par SSH ou par la console locale et ouvrir Option 4: Device Console. Se connecter à Sophos Firewall par SSH explique l’accès et la distinction entre Device Console et Advanced Shell.

Exécuter ici tcpdump et set proxy-arp dans Option 4: Device Console, et non dans Advanced Shell. Sophos avertit dans la documentation de Device Console qu’une commande incomplète peut empêcher le daemon access_server de répondre. Préparer donc la ligne complète, comparer une nouvelle fois l’interface et l’IP de destination avec le plan de capture et ne pas tester des paramètres au hasard. Si l’aide intégrée accessible par la touche Tab sur le build installé diffère de la syntaxe documentée, arrêter la modification et clarifier d’abord le point avec Sophos Support.

Le filtre BPF suivant est en lecture seule et limite la capture à l’interface et à l’adresse d’exemple :

tcpdump interface Port2 'arp and host 203.0.113.10'

Lancer ensuite une nouvelle connexion vers 203.0.113.10 depuis le chemin de test externe autorisé. Si l’équipement upstream conserve encore une entrée en cache, actualiser uniquement cette entrée selon la méthode documentée du routeur ou du fournisseur, ou attendre son expiration. Vider tous les caches ARP ou redémarrer un routeur est disproportionné pour le diagnostic initial.

L’interface, l’IP de destination et l’heure de la capture doivent correspondre au test. Une requête ARP sur un autre VLAN ou une autre interface n’est pas résolue par une entrée sur Port2.

Établir l’état initial de la configuration indépendamment de la capture

Avant add, déterminer et documenter si une entrée Proxy ARP manuelle est déjà configurée pour la combinaison exacte de l’interface et de l’adresse de destination — dans l’exemple, Port2 et 203.0.113.10. Utiliser pour cela uniquement une méthode de lecture confirmée pour le build installé, un justificatif actuel et fiable de la configuration réelle ou une clarification auprès de Sophos Support. Consigner le build du firmware, l’interface, l’adresse de destination, le résultat, la date et l’heure ainsi que le justificatif utilisé. Une ancienne note de modification sans comparaison avec la configuration actuelle ne suffit pas. La syntaxe Proxy ARP documentée décrit add et del, mais aucune commande de lecture ; aucune commande de lecture n’est donc inventée ici ni déduite par essais.

S’il est impossible d’établir de manière fiable l’état initial de la configuration, arrêter la procédure avant toute modification. Si l’entrée existe déjà, ne pas la recréer, l’écraser ni la supprimer dans le cadre de cette procédure. Diagnostiquer plutôt l’association à l’interface, l’adresse de destination, la capture et le chemin de données existant ; faire appel à Sophos Support si nécessaire. Une entrée configurée peut elle aussi ne produire aucune réponse ARP visible. Ni l’absence de réponse, ni un cache de voisins vide, ni l’absence de trafic ARP ne prouvent donc son absence.

Seule une entrée dont il est démontré qu’elle n’est pas encore configurée pour cette interface et cette adresse de destination peut être ajoutée à l’étape suivante. Son état initial documenté et son ajout consigné dans le cadre de cette procédure constituent également les conditions préalables à sa suppression ciblée ultérieure.

Ajouter une seule entrée Proxy ARP

Ajouter exactement l’adresse confirmée dans la Device Console uniquement si le contrôle préalable est concluant et s’il est démontré que l’entrée manuelle exacte pour l’interface et l’adresse de destination n’était pas configurée dans l’état initial documenté. Si l’entrée existe déjà ou si l’état initial est inconnu, ne pas exécuter cette commande :

set proxy-arp add interface Port2 dest_ip 203.0.113.10

Les parties fixes sont set proxy-arp add interface et dest_ip. Remplacer Port2 et 203.0.113.10 par l’interface réelle et l’adresse IPv4 confirmée individuellement.

Sophos documente également dst_iprange, mais la page d’aide actuelle ne publie pas d’exemple de plage complet. Aucun format n’est donc supposé ici. Pour les plages publiques, une seule adresse constitue aussi le pilote le plus sûr : elle limite l’impact et permet des tests positifs et négatifs sans ambiguïté.

Immédiatement après la commande, générer une nouvelle requête ARP et répéter la capture. La réponse attendue contient l’adresse MAC de l’interface prévue du firewall. Si une autre MAC répond ou si plusieurs réponses apparaissent, arrêter le rollout et résoudre d’abord le conflit d’adresses.

Mettre en place séparément la règle, le NAT et le chemin retour

Proxy ARP attire la trame Ethernet vers le firewall. Le chemin de données IP suivant nécessite toujours sa propre configuration techniquement adaptée.

Pour le serveur HTTPS interne de l’exemple, cela comprend :

• une règle DNAT étroite de 203.0.113.10:443 vers 10.20.40.20:443 ;
• une règle de firewall correspondante de la source WAN autorisée vers la zone du serveur ;
• le logging pendant la validation ;
• un chemin retour du serveur via Sophos Firewall ;
• le loopback, si nécessaire, uniquement comme cas interne planifié séparément.

Publier un serveur par DNAT décrit la position des règles, Original Destination, la zone de destination, le loopback et les fonctions de protection. NAT sur Sophos Firewall explique SNAT, DNAT, MASQ et PAT.

Si l’adresse publique supplémentaire doit être routée vers un système en aval sans DNAT, le firewall a besoin à la place d’une route sans ambiguïté et de règles adaptées. Un réseau qui se chevauche ne doit pas être masqué par une route statique supposée ou une plage Proxy ARP. Le préfixe du fournisseur, l’adressage interne et le chemin retour doivent d’abord former une architecture de routage cohérente.

Valider ARP et le service réel

La validation comprend un contrôle de couche 2 et un contrôle IP/applicatif :

1. Générer une nouvelle requête ARP pour 203.0.113.10.
2. Confirmer dans la capture la requête sur Port2 et une seule réponse avec l’adresse MAC attendue du firewall.
3. Ouvrir une nouvelle connexion HTTPS depuis l’hôte de test 198.51.100.25.
4. Dans Log viewer, vérifier la Firewall Rule ID et la NAT Rule ID attendues.
5. Dans le Packet Capture intégré, comparer l’entrée sur Port2 et la sortie vers le serveur.
6. Confirmer sur le serveur que la connexion arrive et que la réponse revient par le firewall.
7. Tester négativement un port non autorisé et une source non autorisée.
8. En présence de HA, tester une nouvelle connexion et un nouvel échange ARP après un failover contrôlé.

Le succès n’est démontré que lorsque la réponse ARP et le service réel sont tous deux corrects. Un ping ne suffit pas : ICMP peut volontairement être traité différemment de HTTPS dans Device Access ou dans la règle de firewall. Packet Capture sur Sophos Firewall explique les filtres, Status, Reason, Rule ID et la comparaison des interfaces ; tester systématiquement les règles de firewall présente la validation complète.

Dépannage systématique

Aucune requête ARP n’arrive

Vérifier l’attribution du fournisseur, le routage upstream, le VLAN, le port du switch et l’interface d’entrée réelle. Une entrée Proxy ARP locale ne peut pas répondre à une requête qui n’atteint jamais l’interface. Avec un préfixe routé, l’absence de requête ARP pour chaque IP de destination est même normale ; il faut alors contrôler la route et le next hop plutôt que Proxy ARP.

La requête ARP arrive, mais aucune réponse ne sort

Comparer l’IP de destination et l’interface de la commande avec la capture. Exclure ensuite un changement d’interface, une faute dans l’adresse ou un test lancé depuis un autre segment de couche 2. Ne pas ajouter une plage IP plus large pour donner l’impression qu’un test individuel incertain fonctionne.

Si l’entrée documentée sur l’interface confirmée ne répond toujours pas, rassembler la version du firmware, une courte capture et la topologie exacte pour Sophos Support. Des modifications non documentées d’ARP ou de paramètres du kernel dans Advanced Shell ne constituent pas une étape standard sûre.

Plusieurs adresses MAC répondent

Arrêter le test. Les causes fréquentes sont une adresse IP dupliquée, un ancien équipement encore actif, un alias sur un second firewall ou une autre entrée Proxy ARP. Identifier d’abord le propriétaire de chaque adresse MAC et résoudre le conflit d’adresses. Une règle de firewall ne peut pas corriger des réponses ARP concurrentes.

ARP est correct, mais le service reste inaccessible

Proxy ARP a déjà rempli sa fonction. Vérifier ensuite la Firewall Rule ID, la NAT Rule ID, l’ordre des règles, la zone de destination, le service, la gateway du serveur et le chemin retour. Utiliser une nouvelle connexion afin de ne pas réutiliser une ancienne session.

L’adresse est brièvement inaccessible après un remplacement ou un failover HA

Vérifier à nouveau ARP et le service réel sur le nœud actif au moment de l’événement. L’équipement upstream peut encore conserver une ancienne association MAC. Actualiser d’abord uniquement l’entrée concernée de façon contrôlée ; résoudre les problèmes ARP après une migration du firewall décrit le processus complet pour les anciens caches du fournisseur ou du routeur.

La poursuite sans interruption des connexions existantes n’est pas garantie. Les critères sont une nouvelle requête ARP, une nouvelle session applicative et les logs du nœud qui a réellement traité le trafic.

Rollback et exploitation

La suppression suivante s’applique exclusivement à l’entrée exacte qui, d’après l’état initial documenté de la configuration, était absente auparavant et dont l’ajout par cette procédure est démontré. Elle ne doit pas servir à supprimer une entrée préexistante ; si l’état initial est inconnu ou si l’identification de l’entrée est incertaine, arrêter la procédure et clarifier le point avec Sophos Support. Avant la suppression, documenter l’adresse publiée et le service qui dépendent de l’entrée nouvellement ajoutée. Uniquement si ces conditions sont remplies, supprimer exactement la même valeur avec del pendant une fenêtre de maintenance :

set proxy-arp del interface Port2 dest_ip 203.0.113.10

Vérifier et documenter ensuite, à l’aide de la méthode précédemment confirmée, du justificatif de configuration ou de Sophos Support, que l’entrée exacte introduite par cette procédure n’est de nouveau plus configurée. Générer également une nouvelle requête ARP. Le firewall ne doit plus répondre pour cette entrée manuelle, à condition qu’aucun alias, peer HA ou autre mécanisme légitime ne desserve la même adresse. L’absence de réponse constitue uniquement le contrôle fonctionnel et ne prouve pas la suppression de la configuration. Rétablir l’état antérieur documenté pour les règles de test dépendantes et la configuration NAT temporaire ; laisser intacte toute configuration non modifiée par cette procédure.

L’entrée doit figurer dans la documentation d’exploitation, car elle n’apparaît pas comme une adresse d’interface normale expliquant pourquoi le firewall répond pour cette IP supplémentaire. Après une modification d’interface, une appliance de remplacement, une restauration, un changement de firmware ou un test HA, vérifier à nouveau l’adresse de destination, l’interface, la réponse ARP et le service réel.

Checklist

• Attribution du fournisseur et modèle ARP plutôt que routage confirmés.
• L’IP de destination appartient de manière démontrable à l’organisation et n’est pas dupliquée.
• La requête ARP arrive sur l’interface documentée.
• Absence de réponse démontrée par capture avant la modification et, indépendamment de celle-ci, absence de l’entrée configurée exacte pour l’interface et l’adresse de destination établie de manière fiable ; aucun add si l’entrée existe déjà ou si son état est inconnu.
• Une seule adresse pilote a été saisie avec dest_ip.
• Règle de firewall, NAT ou route et chemin retour testés séparément.
• Adresse MAC, Firewall Rule ID et NAT Rule ID attendues confirmées.
• Source non autorisée et port non autorisé testés négativement.
• Failover HA ou chemin de remplacement testé avec une nouvelle connexion.
• État initial de la configuration consigné avec son justificatif et l’ajout de l’entrée ; commande del exacte prévue uniquement pour supprimer l’entrée dont l’absence préalable a été démontrée et qui a été ajoutée par cette procédure. Configuration et fonctionnement vérifiés séparément après la suppression.

FAQ