Re: No available IP Addresses in the pool ...
Hi Thibault, Hi Alan, Thank you very much for coming back to me on this.
If not, confirm that the pool module name is defined in the acctounting{} section of radiusd.conf and that your NAS sends accounting Stop messages.
The accounting is performed on a different machine (physically) so no poolname is be defined under the acctounting{} section. Which also means that the machine I have problems with will never see accounting packets. For some security reasons outside of my control, this setup cannot be changed. I'll have a look at the rlm_ippool_tool tool. Thanks.
I wonder what it would take to convince RedHat to use a version that wasn't almost THREE YEARS out of date.
Will the latest version of freeradius **really** help in this scenario ? How ? Could it automatically free up IP addresses from the pool based on a timer ? I cannot go "astray" from RHEL binaries and compile a new freeradius version on a production server (24x7x365) without a hell of a good reason. I hope you can understand me. Thanks again guys and I am looking forward for your opinions :-) Regards, Florin
Florin wrote:
If not, confirm that the pool module name is defined in the acctounting{} section of radiusd.conf and that your NAS sends accounting Stop messages.
The accounting is performed on a different machine (physically) so no poolname is be defined under the acctounting{} section. Which also means that the machine I have problems with will never see accounting packets.
Which means IP pools will not work.
For some security reasons outside of my control, this setup cannot be changed.
Those security reasons are nonsense. They're "securing" your network by ensuring that no one can log in.
Will the latest version of freeradius **really** help in this scenario ? How ? Could it automatically free up IP addresses from the pool based on a timer ?
More recent versions allow pools in SQL, which are easier to manage. I think also that the SQL pools will free IP's based on Session-Timeout. i.e. after Session-Timeout, the IP can be marked "free", even if there was no accounting packets.
I cannot go "astray" from RHEL binaries and compile a new freeradius version on a production server (24x7x365) without a hell of a good reason. I hope you can understand me.
Making your network work? Try 1.1.6 and the SQL pools on a test machine. Try logging on/off without it receiving accounting packets. If it works, you have a few choices: 1) Make your RADIUS server receive accounting packets in it's existing config 2) Upgrade the RADIUS server to the new code, which does expire pools. 3) Live with a broken network. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Wed 02 May 2007, Alan DeKok wrote:
Florin wrote:
If not, confirm that the pool module name is defined in the acctounting{} section of radiusd.conf and that your NAS sends accounting Stop messages.
The accounting is performed on a different machine (physically) so no poolname is be defined under the acctounting{} section. Which also means that the machine I have problems with will never see accounting packets.
Which means IP pools will not work.
For some security reasons outside of my control, this setup cannot be changed.
Those security reasons are nonsense. They're "securing" your network by ensuring that no one can log in.
Will the latest version of freeradius **really** help in this scenario ? How ? Could it automatically free up IP addresses from the pool based on a timer ?
More recent versions allow pools in SQL, which are easier to manage. I think also that the SQL pools will free IP's based on Session-Timeout. i.e. after Session-Timeout, the IP can be marked "free", even if there was no accounting packets.
Yes. This is correct -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
participants (3)
-
Alan DeKok -
Florin -
Peter Nixon