On 2 Oct 2013, at 19:06, steve@comitcon.be wrote:
Alan
first of all thank you for replying although I must sense quite some hostility in your replies. On the other hand, I have read previous emails coming from your end and this appears to be the way you respond.
Firstly, you ignored what Alan said, there are multiple ways of achieving what you want. * VPN - Establish an IPSEC/PPP tunnel. Use policy driven IP assignment to ensure that the same addresses get assigned to the same NAS. * TLS - RADSEC use the global client 0.0.0.0/0 and use RADSEC to authenticate NAS. Different certificates can be installed on different NAS, all signed by a common CA. * Global client - If you don't care about security use a single client definition and use the same shared secret. If this is behind a nat you know the public IP addresses the UDP frames will come from. Getting the attributes you want from the request means partially decoding the request. This is a bad thing to do in DDOS situations where you just want to discard packets from unknown clients as quickly as possible. It's also a security risk where traffic is ingressing from outside of your network.
Secondly I have read the documentation, but RTFM still appears to be the common way of responding (even after using Linux for over 15 years).
Thirdly , the case below is a true real life situation, which does not only occur only for me, but also for other. Even though the module is not officially supported (maybe for the reason there are) it is in today's world . You can decide, be a bernstein (like qmail) or adopt to a real life situation. (Btw, if this was such uncommon, how come I find as many question on it as there are. If YFI is actually supporting this, there must be a need. Even if it is not meant like that.
Because people are given problems to solve outside their technical capacity, they fail to understand the underlying issue, and come up the solution that fits with their limited understanding of the problem and RADIUS. Or they understand the problem but are using NAS which has not been properly specced for the deployment scenario.
it does not state a) lifetime b) anything else usefull.
What would you like included in that debug message, it's pretty trivial to change...
Now I am running radmin show client list and see the IP appear. I am now testing when it disappear.
Please refrain from responding if it will only be a load of 'you did not do this or that', while you have no clue on what I read or already have done. If the response is coming to the basic question "how can I check the lifetime of a dynamic client" feel free.
Elsewise, let's keep this clean for people willing to find the proper solution.
The proper solution is one of the two posted above. I hate to pull the experience card, but i've been working with RADIUS the entirety of my professional career. I train people who work at telcos on RADIUS security and RADIUS cluster management. The way you're trying to do this is wrong. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team