RE: freeradius not responding on machine specific IPs
Kevin, The relevant line is: "> rad_verify: Received Access-Reject packet from client 127.0.0.1 port 1812 with invalid signature (err=2)! (Shared secret is incorrect.)" The shared secret to authenticate a client to the RADIUS server (for RADIUS, not EAP traffic) is either not set, or you're using the wrong secret. By default there is no shared secret set for localhost. Edit clients.conf, search for 127.0.0.1. You'll find a line that looks like: ipaddr = 127.0.0.1 Now, add this line beneath: secret = secret Restart freeradius and try again. The message should go away. Remember, you're still going to get an access-reject response unless you setup the user account and password your authenticating with in the "users" file. Jason -- Jason Wittlin-Cohen Yale Law School, Class of 2010 jason.wittlin-cohen@yale.edu
Thanks Jason, but I might have been unclear. Sorry about that. I'm using fake data to send to the radius server. I do not care if it passes or fails. I simply want the server to respond when I send a message to x.x.3.199 (the network address of the machine) just as it does when I send a request to the localhost address on the machine. It does respond to localhost, it does not respond to the network address. That's where the problem lies, that I am trying to figure out. Thanks again, though. The network I am trying to authenticate is remote from the radius server, so I cannot use localhost. Otherwise, I wouldn't worry about it... Eventually, the remote location will be running covachilli or something similar. But for security (equipment) reasons, I cannot put a server at that end, so must do authentication remotely, at this end. Cheers, Kevin On Fri, 2008-12-12 at 16:11 -0500, Jason Wittlin-Cohen wrote:
Kevin,
The relevant line is:
"> rad_verify: Received Access-Reject packet from client 127.0.0.1 port 1812 with invalid signature (err=2)! (Shared secret is incorrect.)"
The shared secret to authenticate a client to the RADIUS server (for RADIUS, not EAP traffic) is either not set, or you're using the wrong secret. By default there is no shared secret set for localhost. Edit clients.conf, search for 127.0.0.1. You'll find a line that looks like:
ipaddr = 127.0.0.1
Now, add this line beneath:
secret = secret
Restart freeradius and try again. The message should go away. Remember, you're still going to get an access-reject response unless you setup the user account and password your authenticating with in the "users" file.
Jason
-- Jason Wittlin-Cohen Yale Law School, Class of 2010 jason.wittlin-cohen@yale.edu
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
kevin wrote:
I'm using fake data to send to the radius server. I do not care if it passes or fails. I simply want the server to respond when I send a message to x.x.3.199 (the network address of the machine) just as it does when I send a request to the localhost address on the machine.
It's not clear from your messages if you're running the server in debugging mode for these tests. If you are, the possible outcomes are: 1) it doesn't receive the packet. This usually means firewall issues. 2) it receives the packet, and doesn't respond. Debug output explains why. 3) it receives the packet and responds, but the client doesn't see the response. This usually means firewall issues.
It does respond to localhost, it does not respond to the network address. That's where the problem lies, that I am trying to figure out.
As always, READ the debug output. From your messages it looks like you are NOT looking at the debug output when you send requests from outside of localhost. Alan DeKok.
Hi Alan, OK, you pointed me in the right direction. I did run radius in debug and came up with no errors as shown in a previous message to the list that was cut from this continuation. What I didn't realize nor think of, is that I could run radtest against the debug run. Every reference to debug mode simply indicated to run in debug, check if there were errors, and the ctrl-X and run freeradius again in standard mode. So I ran freeradius in debug mode an then ssh'd into the server again in another instance. Ran radtest again and found these output results:
rad_recv: Access-Request packet from host 192.168.3.199:41953, id=15, length=56 Ignoring request from unknown client 192.168.3.199:41953 --- Walking the entire request list --- Nothing to do. Sleeping until we see a request.
unh-hunh... FR was getting the request, and IGNORING IT... so the client never knew that FR had received the request. Great for security (looks like the port was closed), so that pointed me in the wrong direction, thinking it wasn't open or getting requests. Anyhow, I changed the clients.conf to include the external IP of the server, ran the test again, and it worked as expected:
root@server3:/home/kevin# radtest fred wilma 192.168.3.199 1812 mysecret Sending Access-Request of id 60 to 192.168.3.199 port 1812 User-Name = "fred" User-Password = "wilma" NAS-IP-Address = 255.255.255.255 NAS-Port = 1812 rad_recv: Access-Reject packet from host 192.168.3.199:1812, id=60, length=20 rad_verify: Received Access-Reject packet from client 192.168.3.199 port 1812 with invalid signature (err=2)! (Shared secret is incorrect.)
Thanks to all helping me figure this out... Cheers, Kevin On Sat, 2008-12-13 at 08:45 +0100, Alan DeKok wrote:
kevin wrote:
I'm using fake data to send to the radius server. I do not care if it passes or fails. I simply want the server to respond when I send a message to x.x.3.199 (the network address of the machine) just as it does when I send a request to the localhost address on the machine.
It's not clear from your messages if you're running the server in debugging mode for these tests. If you are, the possible outcomes are:
1) it doesn't receive the packet. This usually means firewall issues.
2) it receives the packet, and doesn't respond. Debug output explains why.
3) it receives the packet and responds, but the client doesn't see the response. This usually means firewall issues.
It does respond to localhost, it does not respond to the network address. That's where the problem lies, that I am trying to figure out.
As always, READ the debug output. From your messages it looks like you are NOT looking at the debug output when you send requests from outside of localhost.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
kevin wrote:
What I didn't realize nor think of, is that I could run radtest against the debug run. Every reference to debug mode simply indicated to run in debug, check if there were errors, and the ctrl-X and run freeradius again in standard mode.
The intent of the debug output is to run *all* of your tests with debugging output on. Otherwise, you're running tests where you completely ignore the output of the server.
So I ran freeradius in debug mode an then ssh'd into the server again in another instance. Ran radtest again and found these output results:
rad_recv: Access-Request packet from host 192.168.3.199:41953, id=15, length=56 Ignoring request from unknown client 192.168.3.199:41953 --- Walking the entire request list --- Nothing to do. Sleeping until we see a request.
unh-hunh... FR was getting the request, and IGNORING IT...
That's how RADIUS works. It accepts requests only from known client.
so the client never knew that FR had received the request. Great for security (looks like the port was closed), so that pointed me in the wrong direction, thinking it wasn't open or getting requests.
Again, you spent a lot of time verifying that the client was sending packets You didn't validate that the server was *receiving* the packets.
Anyhow, I changed the clients.conf to include the external IP of the server, ran the test again, and it worked as expected:
Exactly. Alan DeKok.
participants (3)
-
Alan DeKok -
Jason Wittlin-Cohen -
kevin