FreeRADIUS allows connections locally, but not remotely

[Ernie Dunbar]

On 2015-12-29 14:29, Ernie Dunbar wrote:
> On 2015-12-28 18:07, Alan DeKok wrote:
>> On Dec 28, 2015, at 7:59 PM, Ernie Dunbar <maillist at 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).
> -

Further addendum: downgrading the kernel to the slightly older version 
of 3.2.73-2+deb7u1 has not fixed the problem.