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.
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 :
- L’utilisateur saisit ses identifiants sur le périphérique (ASA, Fortinet, Palo Alto, Citrix ADC…).
- Le périphérique forge un paquet UDP 1812 Access‑Request et le transmet au Duo Proxy.
- 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.
- Le périphérique considère l’authentification impossible et bloque la session.
Méthodologie de résolution
Étape | Action | Résultat attendu |
---|---|---|
1 | Inventorier 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. |
2 | Mettre à jour authproxy.cfg Ajouter chaque adresse dans la section adéquate ( [radius_server_auto] , [radius_server_iframe] , etc.). | Le proxy reconnaît le client. |
3 | Relancer le service Duoduoauthproxy_restart (Linux) ou redémarrage du service Windows. | La nouvelle configuration est chargée. |
4 | Contrôler la connectivité UDP Tester les ports 1812/1813 avec nmap -sU ou l’outil radtest. | Pas de filtrage bloquant. |
5 | Vé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 ». |
6 | Aligner le secret partagé Comparer radius_secret_1 côté proxy et périphérique. | Rejet dû à secret incorrect exclu. |
7 | Activer le mode debugdebug=true puis analyse de debug.log . | Logs détaillés pour affiner le diagnostic. |
8 | Mettre à 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 :
- Autoriser l’adresse de l’équipement intermédiaire dans
authproxy.cfg
. - 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.