I just upgraded one of our CentOS 5 systems from FreeRadius 1.x to FreeRadius 2.1.6. It was all working before the upgrade and I have it working on the new version. That is, by using the deprecated authhost and accthost variables in the realm definition I can successfully authenticate and process accounting with the new version. However, as soon as I attempt to define a set of main and backup servers, then use the auth_pool and acct_pool variables I get the following error: "Ignoring spoofed proxy reply. Signature is invalid" Here is a status query that results in the error, like any other query: Sending Access-Request of id 136 to x.x.x.x port 1812 User-Name := "" User-Password := "" Service-Type := Authenticate-Only Message-Authenticator := 0x00000000000000000000000000000000 NAS-Identifier := "Status Check. Are you alive?" Waking up in 3.9 seconds. rad_recv: Access-Reject packet from host x.x.x.x port 1812, id=136, length=64 Ignoring spoofed proxy reply. Signature is invalid Of course, the main reason I upgraded at all was to be able to define a pool of servers. I've searched Google and cannot find any references to this issue. Here is the proxy.conf lines that matter: home_server my_rlm_auth { ipaddr = x.x.x.x port = 1812 type = "auth" secret = "bignewsecret" response_window = 30 max_outstanding = 65536 zombie_period = 40 status_check = "none" ping_check = "none" # ping_interval = 30 # check_interval = 30 # num_answers_to_alive = 3 # num_pings_to_alive = 3 revive_interval = 300 status_check_timeout = 4 } home_server my_rlm_acct { ipaddr = x.x.x.x port = 1813 type = "acct" secret = "bignewsecret" response_window = 30 max_outstanding = 65536 zombie_period = 40 status_check = "none" ping_check = "none" # ping_interval = 30 # check_interval = 30 # num_answers_to_alive = 3 # num_pings_to_alive = 3 revive_interval = 300 status_check_timeout = 4 } server_pool my_rlm_auth_pool { type = fail-over home_server = my_rlm_auth # home_server = Primary_my_rlm_auth # home_server = Secondary_my_rlm_auth } server_pool my_rlm_acct_pool { type = fail-over home_server = my_rl_acct # home_server = Primary_my_rlm_acct # home_server = Secondary_my_rlm_acct } realm my_rlm { nostrip auth_pool = my_rlm_auth_pool acct_pool = my_rlm_acct_pool # authhost = x.x.x.x:1812 # accthost = x.x.x.x:1813 # secret = "bignewsecret" type = radius } Any ideas or pointers? Regards, Emmett
Emmett Culley wrote:
However, as soon as I attempt to define a set of main and backup servers, then use the auth_pool and acct_pool variables I get the following error:
"Ignoring spoofed proxy reply. Signature is invalid"
That's pretty definitive. It means that the shared secret is wrong.
Of course, the main reason I upgraded at all was to be able to define a pool of servers. I've searched Google and cannot find any references to this issue. Here is the proxy.conf lines that matter:
Which doesn't show the primary && secondary server configuration that causes the problem. My guess is that you've configured the *same* shared secret for both home servers. Then, the home servers have been configured with *different* shared secrets for the proxy. Use "radclient" from the proxy to send packets to the home servers. It will need to use the same shared secret that the proxy *should* have. If you can get radclient working, the same shared secret will work with the proxy. Alan DeKok.
Alan DeKok wrote:
Emmett Culley wrote:
However, as soon as I attempt to define a set of main and backup servers, then use the auth_pool and acct_pool variables I get the following error:
"Ignoring spoofed proxy reply. Signature is invalid"
That's pretty definitive. It means that the shared secret is wrong.
Of course, the main reason I upgraded at all was to be able to define a pool of servers. I've searched Google and cannot find any references to this issue. Here is the proxy.conf lines that matter:
Which doesn't show the primary && secondary server configuration that causes the problem.
My guess is that you've configured the *same* shared secret for both home servers. Then, the home servers have been configured with *different* shared secrets for the proxy.
Use "radclient" from the proxy to send packets to the home servers. It will need to use the same shared secret that the proxy *should* have. If you can get radclient working, the same shared secret will work with the proxy.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Thanks Alan... I finally found the time to work on this issue, and so finally figured it out. I was using ipaddr = domain_name in the home_server definitions. I remembered a problem I had with the freeradius client library wherein if I used a domain name, like localhost, instead of a "real" IP address to describe the server I needed to connect with, I'd get a failure. Using the same proxy.conf file I sent in my first note and changing the ipaddr variable to 127.0.0.1 instead of localhost for each home server allowed me to successfully connect to the primary radius server. I won't have a secondary server set up until next week, at which time I'll test if the fail over to the secondary server work. As I fully expect it to. I assume it is a bug to be required to use and IP address instead of a domain name, so can you please point me to where I can file a bug report on this? Emmett
I was using ipaddr = domain_name in the home_server definitions. I remembered a problem I had with the freeradius client library wherein if I used a domain name, like localhost, instead of a "real" IP address to describe the server I needed to connect with, I'd get a failure.
Using the same proxy.conf file I sent in my first note and changing the ipaddr variable to 127.0.0.1 instead of localhost for each home server allowed me to successfully connect to the primary radius server. I won't have a secondary server set up until next week, at which time I'll test if the fail over to the secondary server work. As I fully expect it to.
I assume it is a bug to be required to use and IP address instead of a domain name, so can you please point me to where I can file a bug report on this?
It's not a bug. Hostname lookups are disabled by default in radiusd.conf. Along with explanation why enabling it is a bad idea. Ivan Kalik Kalik Informatika ISP
Ivan Kalik wrote:
I was using ipaddr = domain_name in the home_server definitions. I remembered a problem I had with the freeradius client library wherein if I used a domain name, like localhost, instead of a "real" IP address to describe the server I needed to connect with, I'd get a failure.
Using the same proxy.conf file I sent in my first note and changing the ipaddr variable to 127.0.0.1 instead of localhost for each home server allowed me to successfully connect to the primary radius server. I won't have a secondary server set up until next week, at which time I'll test if the fail over to the secondary server work. As I fully expect it to.
I assume it is a bug to be required to use and IP address instead of a domain name, so can you please point me to where I can file a bug report on this?
It's not a bug. Hostname lookups are disabled by default in radiusd.conf. Along with explanation why enabling it is a bad idea.
Ivan Kalik Kalik Informatika ISP
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Ah, I didn't occur to me that host name look ups off would prevent the server from looking up hosts defined in the configuration files. Well, now I know. Thanks Ivan! Emmett
Emmett Culley wrote:
It's not a bug. Hostname lookups are disabled by default in radiusd.conf. Along with explanation why enabling it is a bad idea. ... Ah, I didn't occur to me that host name look ups off would prevent the server from looking up hosts defined in the configuration files. Well, now I know.
No... if you give it a hostname in the config files, it always looks it up to find the IP. That configuration controls whether or not it *prints* hostnames. i.e. If it sees an IP address in a RADIUS packet, the default is to print it as an IP address. If you turn hostname lookups on, it will try to look up that IP to find a host name. Alan DeKok.
Alan DeKok wrote:
Emmett Culley wrote:
It's not a bug. Hostname lookups are disabled by default in radiusd.conf. Along with explanation why enabling it is a bad idea. ... Ah, I didn't occur to me that host name look ups off would prevent the server from looking up hosts defined in the configuration files. Well, now I know.
No... if you give it a hostname in the config files, it always looks it up to find the IP. That configuration controls whether or not it *prints* hostnames.
i.e. If it sees an IP address in a RADIUS packet, the default is to print it as an IP address. If you turn hostname lookups on, it will try to look up that IP to find a host name.
Alan DeKok. -
As I at first assumed...So, this is a bug after all. If I put ipaddr = localhost in a home_server definition I get the failed authentication I described in my first note. You can see in proxy.conf configuration lines I included, where ipaddr is set to localhost for all four home_server definitions. As soon as I changed the ipaddr parameter in all four home_server definitions, and reset the server, I was able to properly authenticate. Nothing else was changed. I'll write a bug report on the freeradius.org site. BTW, I found a similar issue in the radius client library. Using a host name in the configuration file causes a crash. I need to report that as well. I've run it in a debugger and can tell you where it fails. Emmett
As I at first assumed...So, this is a bug after all. If I put ipaddr = localhost in a home_server definition I get the failed authentication I described in my first note. You can see in proxy.conf configuration lines I included, where ipaddr is set to localhost for all four home_server definitions.
As soon as I changed the ipaddr parameter in all four home_server definitions, and reset the server, I was able to properly authenticate. Nothing else was changed.
Are you sure your name resolution isn't broken so localhost doesn't resolve to 127.0.0.1 but to something else, which then causes authentication to fail? I can substitute localhost for 127.0.0.1 in proxy.conf in 2.1.6 with no effect to authentication. Ivan Kalik Kalik Informatika ISP
Ivan Kalik wrote:
As I at first assumed...So, this is a bug after all. If I put ipaddr = localhost in a home_server definition I get the failed authentication I described in my first note. You can see in proxy.conf configuration lines I included, where ipaddr is set to localhost for all four home_server definitions.
As soon as I changed the ipaddr parameter in all four home_server definitions, and reset the server, I was able to properly authenticate. Nothing else was changed.
Are you sure your name resolution isn't broken so localhost doesn't resolve to 127.0.0.1 but to something else, which then causes authentication to fail? I can substitute localhost for 127.0.0.1 in proxy.conf in 2.1.6 with no effect to authentication.
Ivan Kalik Kalik Informatika ISP
I just spent the last hour or so attempting to repeat and debug the problem I observed in the free radius client. Then when I couldn't make it fail I switched the 127.0.0.1 IP address for localhost in the proxy.conf file of the server, and it worked as well. So, as you suggested, I must have had a misconfigured system when I attempted to test this before. Thanks for the help and sorry for the false alarm... BTW, I am using version 2.1.6. Thanks for all your hard work. Emmett
Emmett Culley wrote:
As soon as I changed the ipaddr parameter in all four home_server definitions, and reset the server, I was able to properly authenticate. Nothing else was changed.
You may also try using the 2.1.7-pre code: http://git.freeradius.org/pre/ It contains a fix where the server would still send packets when "status_check = none". Alan DeKok.
participants (3)
-
Alan DeKok -
Emmett Culley -
Ivan Kalik