Message RADIUS reçu d’une IP client non valide : résoudre l’erreur sur Duo Authentication Proxy

Vous venez de déployer un Duo Authentication Proxy, mais vos équipements réseau (pare‑feu, VPN, NAS, applications) se voient rejetés avec le message : « A RADIUS message was received from an invalid RADIUS client IP ». Ce guide complet détaille les causes possibles et fournit une méthodologie éprouvée pour éliminer l’alerte et rétablir l’authentification multi‑facteur.

Sommaire

Problématique

Le proxy Duo se comporte comme un relais RADIUS : il n’accepte des paquets Access‑Request que d’adresses clairement listées dans authproxy.cfg. Dès qu’un en‑tête IP ne correspond pas à l’une des valeurs radius_ip_x, il génère une entrée de journal semblable à :

2025‑08‑19T14:02:41.851‑0400  [WARN]  RADIUS: A RADIUS message was received from an invalid RADIUS client IP (198.51.100.42).

L’erreur peut résulter d’un oubli dans la configuration, d’un NAT trompeur ou d’une faute de frappe. Dans une architecture haute disponibilité, elle bloque souvent toute authentification MFA sur les services critiques (SSL VPN, Wi‑Fi, SSH, OWA, etc.).

Flux RADIUS et point de rejet

Pour comprendre la racine du problème, décortiquons le cheminement typique d’un paquet :

  1. L’utilisateur saisit ses identifiants sur le périphérique (ASA, Fortinet, Palo Alto, Citrix ADC…).
  2. Le périphérique forge un paquet UDP 1812 Access‑Request et le transmet au Duo Proxy.
  3. Le Duo Proxy inspecte l’IP source ; si absente de la liste blanche, il retourne immédiatement un Access‑Reject ou n’émet aucune réponse, suivant la version.
  4. Le périphérique considère l’authentification impossible et bloque la session.

Méthodologie de résolution

ÉtapeActionRésultat attendu
1Inventorier les IP sources
Obtenir la véritable IP d’origine en consultant les journaux du périphérique ou en capturant le trafic (Wireshark/tcpdump).
Liste exhaustive des adresses à autoriser.
2Mettre à jour authproxy.cfg
Ajouter chaque adresse dans la section adéquate ([radius_server_auto], [radius_server_iframe], etc.).
Le proxy reconnaît le client.
3Relancer le service Duo
duoauthproxy_restart (Linux) ou redémarrage du service Windows.
La nouvelle configuration est chargée.
4Contrôler la connectivité UDP
Tester les ports 1812/1813 avec nmap -sU ou l’outil radtest.
Pas de filtrage bloquant.
5Vérifier la traduction d’adresse
Si le client traverse un NAT, déclarer l’IP publique (et non privée) dans authproxy.cfg.
Éviter les faux‑positifs « IP invalide ».
6Aligner le secret partagé
Comparer radius_secret_1 côté proxy et périphérique.
Rejet dû à secret incorrect exclu.
7Activer le mode debug
debug=true puis analyse de debug.log.
Logs détaillés pour affiner le diagnostic.
8Mettre à jour le proxy Duo
Télécharger la dernière release et relancer l’installateur.
Compatibilité et messages d’erreur enrichis.

Exemple pratique : Cisco ASA + Duo Proxy Windows

Voici un scénario fréquemment rencontré :

;-------------- authproxy.cfg -----------------

[radius_server_auto]

ikey=DUOXXXXXXXXXXXXXXXXXXXX skey=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX api_host=api‑contoso‑corp.duosecurity.com radius\_ip\_1=203.0.113.25 ; IP publique NAT de l’ASA radius\_secret\_1=VeryStrongSecret! port=1812 failmode=safe ;———————————————

Étapes clefs :

  • L’ASA est derrière un firewall externe qui effectue un NAT statique vers 203.0.113.25.
  • Si vous déclarez l’IP privée 192.168.10.1 dans authproxy.cfg, le proxy rejettera la requête car le paquet arrive avec la source 203.0.113.25.
  • Solution : conserver l’IP publique dans la config Duo et ajouter une règle ACL qui n’autorise le trafic RADIUS qu’entre l’ASA et le proxy.

Analyse réseau : filtrage pare‑feu et inspection

Une erreur « client IP non valide » survient parfois parce qu’un équipement intermédiaire modifie la trame RADIUS :

  • Load‑balancer en mode SNAT qui substitue sa propre adresse.
  • IPS ou SSL Inspection qui décrochent la session et relancent un nouveau flux.
  • Proxy réversible ou VPN qui encapsulent/décapsulent et altèrent l’en‑tête.

Dans ces cas, deux approches existent :

  1. Autoriser l’adresse de l’équipement intermédiaire dans authproxy.cfg.
  2. Passer en mode Direct Server Return ou désactiver la translation afin de préserver l’IP source originale.

Dépannage avancé via radclient ou radtest

Pour éliminer toute ambiguïté côté client, exécutez un test local :

radtest "duo_test" "Password123" 198.51.100.10 1 VeryStrongSecret! -x

Dans la sortie, portez attention à :

  • Received Access‑Challenge : le message a bien été accepté ; l’IP est correcte.
  • No reply from server : soit la requête n’atteint pas le proxy, soit l’IP est rejetée.

Ajoutez l’option -t 60 pour augmenter le timeout et éviter les faux diagnostics sur des réseaux à forte latence.

Pièges courants et erreurs de débutant

  • Mauvaise casse dans authproxy.cfg : bien que les sections soient insensibles à la casse, certains éditeurs introduisent des caractères Unicode invisibles qui corrompent la ligne (zero‑width space).
  • Changement d’adresse dynamique : des VM cloud obtiennent une nouvelle IP après redémarrage ; préférez une IP privée statique ou un Elastic IP si nécessaire.
  • Double déclaration de clé : deux clients RADIUS distincts ne peuvent pas partager le même Client‑Identifier sur certains périphériques.
  • Port RADIUS non standard : si vous spécifiez port=1645 côté Duo mais conservez 1812 sur le client, l’IP sera marquée invalide car le paquet arrive sur le mauvais socket.

Checklist avant mise en production

Chaque équipement possède un NTP synchronisé (différence < 120 s).
authproxy.cfg versionné dans Git ou autre SCM avec historique clair.
Ports UDP 1812/1813 ouverts bidirectionnellement entre le proxy et le client.
Bascule planifiée vers failmode=safe puis failmode=secure quand l’environnement est stabilisé.
Test radtest scripté en tâche cron pour surveiller la régression.

FAQ rapide

Q : Puis‑je spécifier un FQDN au lieu d’une IP dans radius_ip_1 ?
R : Oui, mais le nom est résolu au moment du démarrage du service Duo. Si l’adresse varie dans le temps, le proxy continuera à envoyer l’erreur « IP invalide ». Favorisez donc une IP fixe ou relancez le service après chaque changement DNS.

Q : Pourquoi Duo génère‑t‑il l’erreur alors que le client est bien déclaré ?
R : Vérifiez l’ordre des sections. Si vous placez la ligne radius_ip_1 dans [cloud] ou [main] au lieu de [radius_server_*], elle sera ignorée.

Q : Pouvons‑nous enregistrer une plage CIDR complète ?
R : Non, Duo exige des adresses individuelles. Dans les environnements où les IP changent, automatisez la mise à jour du fichier via Ansible ou PowerShell et relancez le service.

Conclusion

La quasi‑totalité des messages « A RADIUS message was received from an invalid RADIUS client IP » se résolvent en vérifiant trois points : la véritable IP source, son inscription exacte dans authproxy.cfg, et l’absence de translation d’adresse imprévue. En suivant la démarche pas à pas détaillée dans cet article, vous transformez un échec d’authentification frustrant en un flux RADIUS robuste et sécurisé, parfaitement aligné sur les bonnes pratiques Duo Security.

Sommaire