Introduction

Le mécanisme du Proxy ARP c'est tout simplement lorsqu'un nœud répond à une requête ARP au lieu d'un autre nœud présent dans le réseau !
Est-ce logique ? est-ce un comportement malicieux ? Utile ?

Prenons les trois cas pratiques d'utilisation suivants : Utilisateurs configurés avec des masques erronés, la nécessité de Proxy ARP dans le routage statique et Utilisation du NAT par les Firewalls.

Masques Réseaux mal configurés pour les Utilisateurs

Petit Rappel : 

- PC-A veut communiquer avec PC-B sur le même Network : Le PC-A doit chercher l'adresse MAC du PC-B dans sa table ARP (Il envoie une Requête ARP s'il ne la trouve pas).
- PC-A veut communiquer avec PC-B dans un Network différent : Le PC-A doit chercher l'adresse MAC de son Default Gateway dans sa table ARP (Il envoie aussi une Requête ARP s'il ne la trouve pas).

Regardons cette figure :

Le PC-A est configuré avec l'adresse 10.10.10.1 et un masque /24. Le PC-B qui possède l'adresse 10.10.10.2 se trouve dans le même LAN que le PC-A, cependant, et accidentellement, on a configuré son masque /8. Il va considérer donc toutes les IP qui commencent par 10 (10.0.0.0/8) présentes dans son Network.

Le PC-C possède l'adresse 10.10.20.3 et un masque /24. Il est donc dans un autre LAN à droite du routeur.

Que se passe-t-il si les deux PCs A et B essaient de communiquer avec le PC-C ?

- Le PC-A trouve que le PC-C possède un Network différent (10.10.10.0/24 != 10.10.20.0/24) et il va remplir donc sa trame avec l'adresse MAC Dest de son Gateway (le Paquet va être envoyé vers la Gateway).
- Le PC-B trouve que le PC-C se trouve dans son même réseau (10.0.0.0/8) et va essayer donc de remplir sa trame avec l'adresse MAC Dest du PC-C ! Il ne va pas la trouver -sûrement- dans sa table ARP, une requête ARP est envoyée dans le LAN pour chercher l'adresse MAC du PC-C en admettant qu'il se trouve dans le même LAN.

Dans le cas classique d'une config de routage simple sur le routeur, le Broadcast généré (n'oubliant pas que la requête ARP est un type particulier de Broadcast) ne va pas traverser le routeur en question, c'est bloqué par défaut, et la requête n'arrive donc pas à la machine C. Le PC-A ainsi que le routeur vont rejeter la requête ARP vu qu'ils ne sont pas la destination cherchée (10.10.20.3) et la communication ne peut pas être établie entre PC-B et PC-C.

Pour plus de flexibilité (exp : ne pas compliquer les choses suite aux fautes de frappe lors de l'écriture des masques…), le routeur peut lui-même répondre positivement aux Requêtes ARPs destinées vers d'autres machines dans d'autres Networks qui y sont connectés : c'est en utilisant le Proxy ARP !

Voir figures suivantes :

La réponse ARP envoyée par le routeur contient l'adresse MAC de sa propre Interface LAN mappée avec l'adresse IP du PC-C cible. Comme si la réponse était « c’est à travers moi que tu peux aller vers le PC C ! ».
Toutes les trames sortantes du PC-B vont utiliser l'adresse MAC du routeur comme Destination pour aller vers le PC-C, et c'est malgré l'erreur du masque configuré ... Point positif.

On cite quelques inconvénients liés à cette utilisation de Proxy ARP :

• La hausse de CPU du routeur car il va traiter un nombre très important de Requêtes ARP. Dans l’exemple précédant c’est « 2^24 – 2 » requêtes. Tout le réseau 10.0.0.0/8 est considéré comme local pour le PC B !
• La non-capabilité de l'administrateur réseau de se rendre compte qu'un PC ou plusieurs dans son réseau possède un masque erroné ... Le Proxy ARP a résolu son problème d’une manière transparente. Dans des « Moves » ou de migrations futures, ça peut poser des problèmes.

Actuellement, plusieurs Routeurs/Switches Layer 3 Cisco possèdent cette fonctionnalité activée par défaut. La meilleure façon de remédier aux problèmes des erreurs de configuration des masques c'est de la désactiver et de corriger les masques erronés manuellement :)

Utilisation du Proxy ARP avec le routage statique

Il existe deux méthodes pour configurer une route statique simple. Soit en utilisant le Next-hop IP address, soit en utilisant l’interface de sortie physique.

Généralement, on ne met pas trop d’importance sur la différence entre les deux méthodes, mais ça peut causer des problèmes dans certains cas particuliers. Voyons les deux cas de figures suivantes.  

1. Utilisation de IP Next-hop Address :

C’est la méthode la plus sûre et la plus recommandée. Dans la figure ci-dessous, PC-A veut communiquer avec PC-B. Le routage statique est implémenté en utilisant l’IP de NextHop.

En entrée sur R1 depuis PC-A, le header Layer 2 de la trame est éliminé. Les IPs sources et destinations restent inchangées. En utilisant le routage, la destination est encore lointaine et configurée statiquement vers un Next-hop. En sortie vers ce Next-Hop IP address, on doit ajouter un nouveau Header Layer 2 pour que la trame soit complète : MAC source celle de l’interface de sortie de R1 et MAC Destination celle du Next-Hop (connected). Si cette dernière n’existe pas dans la table ARP du routeur R1, il envoie une recherche ARP Request « Qui a l’IP du Next-hop .1 ? qu’il me donne son MAC ! » et l’obtient par la suite… La trame est bien envoyée vers R2.

2. Utilisation de l’interface physique de sortie :

C’est la moins sûre et la moins recommandée. Toujours PC-A veut communiquer avec PC-B. Le routage statique est implémenté en utilisant l’interface de sortie Gi0/1 et non l’IP de Next-Hop.

Cette fois, en sortie depuis R1, et vu l’obligation d’ajouter au paquet un Header Layer 2 pour que ça soit une trame complète, on n’a pas une IP de NextHop configurée pour checker la table ARP locale ou envoyer un ARP Request. Le routeur ADMET (Cisco, par défaut) que l’IP de destination dans le paquet est celle du NextHop ! Il envoie un ARP Request pour chercher la MAC address de cette IP Destination !

Dans l’exemple ci-dessous, pour pinger la Destination 8.8.8.8, la requête ARP envoyée de R1 vers R2 est « Qui est 8.8.8.8 ? qu’il me donne son MAC ! ».

Deux cas peuvent se présenter :

• L’équipement qui reçoit la requête n’a pas de « ip proxy-arp » activé, il ne répond pas, c’est évident car l’IP 8.8.8.8 n’est pas une IP locale et le ping ne marche pas !

• L’équipement qui reçoit la requête ARP possède l’« ip proxy-arp » activé : il check s’il possède cette adresse IP Dest dans sa table de routage (joignable ou pas), si oui, il répond positivement à la requête ARP avec sa propre adresse MAC de l’interface qui a reçu la requête : « Oui c’est à travers moi que tu peux joindre ta destination 8.8.8.8, voici ma propre MAC ! »

Conclusion et Remarques :

• Eviter au Max les routes statiques configurées avec des interfaces de sortie physiques (et non des IP Next-Hop), c’est pour éviter le grand flux des recherches ARP Broadcast ainsi que les erreurs dans le cas où le proxy arp est désactivé sur le nexthop.
• La commande pour voir si le proxy-arp est activé ou pas est la suivante (souvent, c’est caché il faut utiliser le « all » ) :

• Les routes statiques configurées avec des IP Nexthop permettent tout simplement d’éviter tout ce débat 😉.

• Il existe sur le Web plein de discutions techniques si on active ou on désactive le proxy-arp sous les interfaces des routeurs, chacun l’utilise pour son besoin et même Cisco l’active par défaut sur certaines gammes et le désactive sur d’autres (il faut se référer au datasheet). Personnellement, je préfère souvent le désactiver car il permet de résoudre des Pb de routage mais il nous cache plusieurs failles (Broadcasts ARP répétitifs, masques erronés mais fonctionnels car traités par le routeur, routes statiques générales non précises, ect …).

• Astuce pratique : des incidents liés à des masques non corrects et/ou des routes statiques non précises -> penser souvent au proxy arp.

Utilité de proxy ARP dans le NAT

La notion de Proxy ARP est parfois attachée à la notion du NAT. Comment et pourquoi ? Pour répondre à cette question, prenons l'exemple basique suivant de l'utilisation d'un NAT :

Le Firewall dans la figure ci-dessous contient un NAT statique vers un serveur Interne :

80.80.80.80 <-> 10.10.10.1

Le Serveur Publique 70.70.70.70 va effectuer un transfert de donnée vers le serveur Interne 10.10.10.1. Il va contacter donc l'adresse Publique NATée : 80.80.80.80.

La patte interne du firewall qui représente le Gateway du serveur 10.10.10.1 possède l'IP : 10.10.10.254. La patte externe a comme adresse publique : 80.80.80.2.

Comment se déroule la communication depuis le serveur Publique vers le serveur Privé ?

Le trafic sortant du serveur 70.70.70.70 et allant vers le serveur Interne 10.10.10.1 possède comme source IP 70.70.70.70 et Destination IP 80.80.80.80 (il ne communique qu’avec l'adresse publique externe du NAT).
 
Ce flux arrive sur le Routeur FSI de l'Opérateur. Pour véhiculer les paquets ayant comme destination 80.80.80.80 vers son interface de sortie, le routeur déduit que le réseau de destination est Direcly Connected. Il effectue donc une Requête ARP pour apprendre la MAC de 80.80.80.80. 

La requête ARP est envoyée à travers le lien qui le relie au Firewall.
Sans le Proxy ARP activé au niveau du Firewall, ce dernier reçoit la Requête ARP et la rejette car son IP est 80.80.80.2 et non 80.80.80.80 ! En effet, 80.80.80.80 est l'adresse publique NATée du serveur et elle ne se trouve pas sur une interface du Firewall.

Si le Proxy ARP est configuré au niveau du Firewall, il va répondre positivement à la Requête ARP (au lieu du serveur Réel 80.80.80.80 <-> 10.10.10.1) et il va confirmer qu'il connaît bien la MAC de 80.80.80.80 puisqu'il est son Gateway Interne. La Réponse ARP contient donc l'IP cible 80.80.80.80 mappée à la MAC de l’interface externe du Firewall.

Sans le Proxy ARP, le NAT n'aurait pas été fonctionnel !!
(Sauf si, on utilise des routes statiques vers l'IP publique mappée au niveau du routeur FSI)

Configuration de Proxy ARP

Plusieurs IOS Cisco contiennent le mécanisme de Proxy ARP activé.

Si on veut augmenter la performance et améliorer la sécurité d'un tel Équipement Niveau 3, on désactive le Proxy-Arp, si on veut plutôt simplifier les modes de fonctionnement et avoir plus de flexibilité lors des déploiements, on l’active.
On rappelle, que si on désactive le Proxy ARP sous une interface, le routeur concerné ne peut pas répondre aux Requêtes ARPs destinées vers des machines distantes.

Les commandes !

Pour voir si le proxy-Arp est activé ou pas :

Pour désactiver le Proxy-Arp sous une interface :

Pour l'activer de nouveau: