Swapping RADIUS servers.
aland at deployingradius.com
Thu Nov 30 07:11:09 CET 2006
Lin Richardson wrote:
> 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.
Or... IP re-write rules on the RADIUS server. There's more than one
way to solve a problem.
> 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 almost wonder if power cycling the client device would resolve the
> problem... once freeradius had assumed the new ports.
I don't see why. RADIUS doesn't maintain sessions across states, and
NASes are pretty dumb. This kind of behavior is a little surprising.
> 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?
Yes. The clients know nothing more than RADIUS requests and RADIUS
responses. Same request/response == same behavior.
> 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?
No, you need the shared secret, too.
> 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?
None flow through to the reply. RADIUS clients can request anything
they want, and you can't control that. So sane RADIUS servers don't let
the clients control the reply. They let the *administrator* control the
> 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.
Even for the old server? An empty Access-Accept? That sounds a
http://deployingradius.com - The web site of the book
http://deployingradius.com/blog/ - The blog
More information about the Freeradius-Users