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 est que Proxy ARP résout uniquement la découverte du voisin 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. Ce n’est qu’ensuite qu’une seule entrée Proxy ARP est ajoutée et testée avec le service réel.
⚠️ 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
- 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.
- Exclure que l’adresse soit déjà utilisée comme alias, sur un autre équipement ou par une architecture existante.
- Réaliser une capture ARP sur l’interface d’entrée attendue pendant le lancement d’une nouvelle connexion.
- Continuer uniquement si la requête ARP pour l’adresse de destination arrive et si l’absence de la réponse requise du firewall est démontrée.
- Dans la Device Console, ajouter une entrée avec
set proxy-arp addpour une seule adresse IPv4. - Configurer ou vérifier séparément la règle de firewall, le DNAT ou la route, ainsi que le chemin retour.
- Tester la réponse ARP, la Firewall Rule ID, la NAT Rule ID et le service réel avec une nouvelle connexion.
- Répéter le même test après un failover HA ou lors du rollback, puis supprimer précisément l’entrée avec
set proxy-arp del.
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. L’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.
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 :
- 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.
- 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.
- La requête arrive, mais personne ne répond : seule cette observation correspond à l’absence d’une réponse Proxy ARP sur le firewall.
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.
Le filtre BPF suivant est en lecture seule et affiche uniquement le trafic ARP pour l’adresse d’exemple :
tcpdump '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.
Ajouter une seule entrée Proxy ARP
Si le contrôle préalable est concluant, ajouter exactement l’adresse confirmée dans la Device Console :
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 et testé. 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:443vers10.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 :
- Générer une nouvelle requête ARP pour
203.0.113.10. - Confirmer dans la capture la requête sur
Port2et une seule réponse avec l’adresse MAC attendue du firewall. - Ouvrir une nouvelle connexion HTTPS depuis l’hôte de test
198.51.100.25. - Dans Log viewer, vérifier la Firewall Rule ID et la NAT Rule ID attendues.
- Dans le Packet Capture intégré, comparer l’entrée sur
Port2et la sortie vers le serveur. - Confirmer sur le serveur que la connexion arrive et que la réponse revient par le firewall.
- Tester négativement un port non autorisé et une source non autorisée.
- 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
Avant la suppression, documenter l’adresse publiée et le service qui dépendent de l’entrée. Pendant une fenêtre de maintenance, supprimer exactement la même valeur avec del :
set proxy-arp del interface Port2 dest_ip 203.0.113.10
Générer ensuite 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. Rétablir l’état antérieur documenté pour les règles de test dépendantes et la configuration NAT temporaire.
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.
- L’absence de réponse a été démontrée par capture avant la modification.
- 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.
- Commande
delexacte et état initial documentés.