Hi Alan, <br><br>Thanks for taking a look at this.<br><br>A quick clarification.<br><br>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.

<br><br>I almost wonder if power cycling the client device would resolve the problem... once freeradius had assumed the new ports.<br><div><span class="gmail_quote"></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

> What we saw were requests coming into freeradius, being processed as<br>> expected, and returning the appropriate response - many Accept responses<br>> clearly visible in the logs.  The radius clients however did not accept

<br>> these responses and treated them as authentication failure.<br><br>  See the FAQ.  Do you have multiple IP's on the machine?</blockquote><div><br>No multiple IPs<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

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

</blockquote><div><br>Just an expression meaning no other event to mark the change. Really more unexpectedly than suddenly.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

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.</blockquote><div> 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?

<br>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? <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

> Nov 29 10:58:48   rad_check_password:  Found Auth-Type Accept<br>> Nov 29 10:58:48   rad_check_password: Auth-Type = Accept, accepting the<br>> user<br>> Nov 29 10:58:48 Sending Access-Accept of id 105 to <a href="http://10.32.251.10">

10.32.251.10</a><br>> <<a href="http://10.32.251.10">http://10.32.251.10</a>> port 32768<br>> Nov 29 10:58:48 Finished request 0<br><br>  The Access-Accept contains no attributes.  Are you sure you want to do<br>

that?  The request contained VLAN attributes, so I presume you want to put the user in a VLAN.</blockquote><div> 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?

<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">  i.e. Are you sure that you have configured FreeRADIUS to return the<br>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.</blockquote><div> 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.

<br><br>Again, thanks for taking time to kick this around, I am truely at a loss.<br> <br></div>Regards,<br>Lin<br></div>