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