On 2015-12-28 18:07, Alan DeKok wrote:
On Dec 28, 2015, at 7:59 PM, Ernie Dunbar <maillist@lightspeed.ca> wrote:
I don't know what to make of this, but I don't think it's a network problem. There are also other servers on this physical machine that are working just fine (like ssh and apache, for example).
They're TCP. Not UDP.
Also, I've correctly configured the 206.XXX.XX.205 IP address as a client, and then gotten the radtest program to successfully connect and authenticate. Installing the client on another, separate physical machine which exists on the same network switch and class C at 206.XXX.XX.0/24 also results in the same result as connections from our office at 65.XX.XXX.178.
It's a networking problem. You've demonstrated that FreeRADIUS can send and receive UDP packets. But something is preventing the packets from reaching the server.
You could try running a more recent version of the server. But I doubt it would help.
Okay, just to follow up on this with my own findings for the benefit of future readers, I've discovered that whatever differences there are between Ubuntu 14.04 LTS and Debian Wheezy, are the cause of this issue. I copied the configuration from the original Debian server to another server we have that's running Ubuntu, installed the packages for FreeRADIUS (v 2.1.12 on both servers, by the way, so it's not application-specific), and found that the Ubuntu server was responding to remote hosts, while the Debian server was not. We're also running DNS and NTP on the old Debian server, so Debian's issues with FreeRADIUS appear to be very weirdly specific to that server, and not to the UDP protocol or networking in general. I don't really know why this is, but I can tell you that moving FreeRADIUS away from Debian Wheezy is definitely a solution (or possibly going back to a previous kernel version, since it worked for about 9 years before Monday morning).