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.