> > The information is in the PoD request. > Kind of. From the NAS's perspecitive, the PoD only needs to contains the Acct-Session-Id. However obviously in order to proxy a request we at least need the NAS-IP-Address. I use this to map back to a "Realm" or a NAS which will ultimately handle the PoD.
> To ensure that bad things don't happen, the PoD *should* be >treated sort of like an Access-Accept, and the server should >see where the packet is proxied to. IF the home server is >where the PoD request came from, then it's a "real" PoD >request, and is sent to the NAS. >Otherwise, it's dropped. I must admit, my solution is not that comprehensive, and I'm not sure if it would even be possible. A PoD doesn't REQUIRE a User-Name attribute, so it would be difficult in that instance to map a PoD back to an appropriate home server for the specified session (NAS-IP-Address & Acct-Session-Id). The only attributes that are guaranteed (in my case) are NAS-IP-Address and Acct-Session-Id. My "solution" met my needs at the time as I had very specific requirements, and using freeRADIUS was the quickest way to a solution, as freeRADIUS obviously already has all the proxy and RADIUS packet handling logic, and is nice and modular, so its easy to add this stuff quickly (even if its not the best solution). I also haven't tried proxying directly to a NAS. Should be easy enough to set this up in our test lab though. Alan would be disgusted at my current butcher job ;-). However, I'll review what I have done (it was several months ago now) and report back as soon as I can (may take a few days though) - hopefully with something a little more elegant than I have currently. Regards, Mike - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
