Swapping RADIUS servers.

[Lin Richardson]

Hi Alan,

Thanks for taking a look at this.

A quick clarification.

The configuration of freeradius in this situation has already been tested
and is not really the basis for my question.  It is not a standard
configuration, but it does work.

Freeradius is installed on the same physical machine and listens on the same
IP address as another vended radius solution.  Freeradius is configured to
use nonstandard ports (11812/11813), while the vended solution is using both
sets of common ports - (same IP address, same physical machine).  We have
moved entire pilot facilities to authenticate on the nonstandard ports using
freeradius and everything works swimmingly.  Huge kudos to freeradius on
that count.  We have chosen to use freeradius not for economy, but rather
for flexibility - hence the nonstandard configuration.

We want to move all facilities to freeradius now for production use.  We
would like to use the standard ports of 1812/1813 in an effort to keep
things somewhat industry standard, and also because all the clients are
already configured for those ports.  We would have to manually change the
configuration of hundreds of WAPs to the nonstandard ports if we intended to
continue to use them.

The concept was simple - shut down the vended radius solution, thus freeing
up the desired ports.  Change the "listen" directive in radiusd.conf to use
1812/1813, and restart freeradius.  All the clients that WERE using the
vended solution on the given ports should continue on as if nothing had
happened, only now they would be talking to freeradius.

Bear in mind that literally the same configuration and installation of
freeradius with only a different listening port have already been in limited
production use with the very devices in question.  I did read the FAQ which
talked about needing to pass the same/correct attributes back to the client
as a previous/other working radius solution in order for freeradius to
work.  I strongly believe that this is not the problem here as it has
already been working without any problems on a different port.

I almost wonder if power cycling the client device would resolve the
problem... once freeradius had assumed the new ports.

> What we saw were requests coming into freeradius, being processed as
> > expected, and returning the appropriate response - many Accept responses
> > clearly visible in the logs.  The radius clients however did not accept
> > these responses and treated them as authentication failure.
>
>   See the FAQ.  Do you have multiple IP's on the machine?


No multiple IPs

> Does anyone have an idea what could have happened here?  If a radius
> > client was talking to server X, and then suddenly recieves a response
> > from server Y on the same IP / port combination...
>
>   Huh?  What does that mean?  "Suddenly", as in... what, exactly?


Just an expression meaning no other event to mark the change. Really more
unexpectedly than suddenly.

  If you shut down the old machine, and start a new machine with the
> same IP, then RADIUS should work as before, assuming the server
> configuration is the same.


So... even if they are on the same machine... killing the vended radius
solution and starting freeradius on the same ports the vended solution was
using should work seamlessly?  Clients won't know or care, provided their
shared secret and attributes are the same?
Could a radius response with spoofed source IP and port be accepted as valid
by a radius client simply based on the IP and port... and of course the
coherence of the reply to a corresponding request?

> Nov 29 10:58:48   rad_check_password:  Found Auth-Type Accept
> > Nov 29 10:58:48   rad_check_password: Auth-Type = Accept, accepting the
> > user
> > Nov 29 10:58:48 Sending Access-Accept of id 105 to 10.32.251.10
> > <http://10.32.251.10> port 32768
> > Nov 29 10:58:48 Finished request 0
>
>   The Access-Accept contains no attributes.  Are you sure you want to do
> that?  The request contained VLAN attributes, so I presume you want to
> put the user in a VLAN.


The WAP controls this, and I have been forbidden to specify anything to do
with VLANs.
Which of the request attributes do/don't flow through to the reply?

  i.e. Are you sure that you have configured FreeRADIUS to return the
> SAME response as your old server?  If the old server returns a bunch of
> attributes, and FreeRADIUS doesn't... then the configurations aren't
> identical, and the clients will behave differently.


Because this is such a logical explanation I will also revisit this
possibility.  For a different type of radius client we do pass some things
back, but the WAPs have always worked without anything else.

Again, thanks for taking time to kick this around, I am truely at a loss.

Regards,
Lin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20061129/7cace470/attachment.html>