Hello Dave -
On this same topic, I recently did a job for a client who was sending proxy
requests to a "cluster" running radius for accounting, and from which the
replies came back from different IP addresses(!).
To deal with this one I implemented the ServerHasBrokenAddresses parameter
that is included in the new Radiator 2.18 release.
There is also a companion IgnoreReplySignature for broken authenticators in
proxy accounting replies (similar to IgnoreAcctSignature for Client clauses).
On Saturday 10 March 2001 01:33, Kitabjian, Dave wrote:
> I was reading the writeup on this interesting feature:
>
> "ServerHasBrokenPortNumbers
>
> "Some Radius servers (GRIC on NT in particular) exhibit broken
> behaviour in that the reply does not come from the same UDP port that the
> request was sent to! "
>
> We have a similar sounding problem, but from some of our Radius CLIENTS:
>
> Fri Mar 9 09:26:08 2001: DEBUG: Packet dump:
> *** Received from 207.201.82.17 port 1646 ....
> Code: Accounting-Request
>
> All (but one) of our NASes are reaching us on ports 1812/1813, and those
> ports were always reflected in the "*** Received from..." lines in our
> Debug 4 logfile. That was all with USR gear. Now that we've added Cisco
> gear, they are often showing 1645/1646, like in the above logfile clipping
> EVEN THOUGH they are actually communicating to Radiator on ports 1812/1813!
>
> Any idea what the reason for that is, and if it has anything to do with the
> ServerHasBrokenPortNumbers issue?
>
This shouldn't be a problem. Note that there are two ends to any
client/server communication, with each end using both an IP address and (in
the case of Radius) a UDP port number. In theory a client can use any UDP
port number it likes for its own end of the communication, and in fact it is
rarely the same port number as the server end. I do grant you however, that
seeing all Radius requests coming from a Cisco from port 1645 is a bit
curious, but again its not a problem.
Why do you say that the above is causing difficulty?
You can do some experiments with radpwtst to see what port numbers it uses
for its own end of its communications with Radiator (on my box its 1028).
hth
Hugh
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
