I’m configuring one of my central routers to provide RADIUS authentication for login to ROS routers out in the network, via the user manager as documented on the wiki.
I first made it work with a router on the same subnet as the user-manager router, and it worked OK; but when I’ve duplicated the configuration on a router on a remote network I’m just getting RADIUS timeouts. I’ve verified the shared secret configuration, deleted it and recreated it, and ensured that the IP addresses in /tool user router are correct. I have also verified via torch that the packets are arriving at the user-manager router to the right port/address combination.
Turn on RADIUS logging on the client and see what it says.
The default timeout is 100ms. Are you sure the round trip time plus lookup time is less than that?
Thanks, I did enable debug logging on the client though I didn’t mention it in the OP. It simply reports a timeout. There are other RADIUS servers configured in the remote system which target the same router, but on a different IP address (it NATs through to an inside RADIUS server) - those other servers have the same default 300ms timeout value. A ping also verifies an average latency of 56ms.
In the interest of experimentation, I increased the timeout value to 3000ms. It still timed out.
But that made me realize that I did not enable debug logging on the TARGET!
Very interesting. The router running user manager shows in the log when looking at “manager/debug” log policy that it is receiving the Access-Request packet, decoding it successfully, and sending back an Access-Accept packet just like it should be - but that Access-Accept isn’t ever making it to the other router.
I’m going to do some more investigation, but that seems to me like there is some filter somewhere blocking the packets and that the RADIUS replies are being sent exactly as they should be.
Edit - I suspect that somehow they are being NAT’d out the other RADIUS servers’ return NAT path and showing up at the other end from the wrong IP address, which would certainly be ignored by any sane RADIUS client so that would explain why the RADIUS client is ignoring the packet.