FreeRADIUS allows connections locally, but not remotely

[Ernie Dunbar]

On 2015-12-28 15:32, Alan DeKok wrote:


>   Run the server in debug mode.  If it doesn't show any packets
> received... it's not receiving any packets.
> 
>   Blame the OS and the network.  Not FreeRADIUS.
> 

Okay, fair enough. I've made some changes to the FreeRADIUS 
configuration with respect to the listening port and IP address, and 
I've added a new "client" for remote testing. Here's the redacted client 
configuration, according to FreeRADIUS' debug output.

radiusd: #### Loading Clients ####
  client 127.0.0.1 {
	require_message_authenticator = no
	secret = "SECRET"
	shortname = "localhost"
  }
  client 204.XXX.XX.254 {
	require_message_authenticator = no
	secret = "SECRET"
	shortname = "dialup"
  }
  client 65.XXX.XX.178 {
	require_message_authenticator = no
	secret = "SECRET"
	shortname = "dialup7"
  }

and the IP addresses and ports section:

radiusd: #### Opening IP addresses and Ports ####
listen {
	type = "auth"
	ipaddr = 206.XXX.XX.4
	port = 1812
}
listen {
	type = "acct"
	ipaddr = 206.XXX.XX.4
	port = 1813
}
listen {
	type = "auth"
	ipaddr = 127.0.0.1
	port = 18120
}

My understanding is that port 18120 is only used internally, especially 
after this debug output:

Listening on authentication address 127.0.0.1 port 18120 as server 
inner-tunnel.

Then I try to get FreeRADIUS to authenticate locally, as I've been 
successful in doing today:

$ /usr/bin/radtest customer password 206.XXX.XX.4:1812 5 SECRET


And for each unsuccessful attempt, I get this output from FreeRADIUS:

Ignoring request to authentication address 206.XXX.XX.4 port 1812 from 
unknown client 206.XXX.XX.205 port 47980
Ready to process requests.
Ignoring request to authentication address 206.XXX.XX.4 port 1812 from 
unknown client 206.XXX.XX.205 port 47980
Ready to process requests.


Ok, Fair enough. Those attempts are coming through this server's other 
IP address (206.XXX.XX.205) to its other IP address (206.XXX.XX.4). It's 
pretty clear that packets are reaching the FreeRADIUS daemon, it's just 
rejecting them because this other IP address isn't in the clients 
configuration. No problem, I switch to another Linux box that *does* 
have its IP address configured in the clients:


# radtest customer password 206.12.82.4:1812 5 l1ghtsp33d -4 
65.XX.XXX.178
Sending Access-Request of id 43 to 206.XXX.XX.4 port 1812
	User-Name = "customer"
	User-Password = "password"
	NAS-IP-Address = 65.XX.XXX.178
	NAS-Port = 5
	Message-Authenticator = 0x00000000000000000000000000000000
	Framed-Protocol = PPP
Sending Access-Request of id 43 to 206.XXX.XX.4 port 1812
	User-Name = "customer"
	User-Password = "password"
	NAS-IP-Address = 65.XX.XXX.178
	NAS-Port = 5
	Message-Authenticator = 0x00000000000000000000000000000000
	Framed-Protocol = PPP
Sending Access-Request of id 43 to 206.XXX.XX.4 port 1812
	User-Name = "customer"
	User-Password = "password"
	NAS-IP-Address = 65.XX.XXX.178
	NAS-Port = 5
	Message-Authenticator = 0x00000000000000000000000000000000
	Framed-Protocol = PPP
^C

And I get this output from the RADIUS server:

Ready to process requests.
Ready to process requests.
Ready to process requests.


Each time "Ready to process requests" comes up in the console, is 
exactly timed to a new Access-Request from the radtest client at 
65.XX.XXX.178.

It's not much output, but it appears to demonstrate that FreeRADIUS is 
accepting the connection over the network and then... doing nothing. If 
it does do something, it doesn't produce any output. It certainly 
doesn't complain about a connection coming from an incorrect host, or 
return a message about how it's correctly authenticated the user or 
denied the authentication request.

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). 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.

I'm not trying to blame you for this issue, I just need to get it fixed.