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.
Used a global client before. The main reason is also that I hacked into daloradius so we can ping trace the local NAS boxes and log into them using ssh. So a global client would not allow me (in the interface for my end operator) to go to the separate boxes. No we don't care on security for the NAS themselves (it is a fully respinned WRT version)
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.
True, I have explained this to the person requesting this and they agree with this. I am not in favor too, don't get me wrong.
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.
I wont go into this argument... There might be other factors limiting them so they need to downsize the solution. It's always balancing the pros and cons.
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...
The lifetime / expiration would help me debugging the lifetime option as this is where I don't see it discarded after 1 minute.
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.
The main issues is that the solution we provide will not work properly using the first 2. It is very limited on speed and we are dropping below an acceptable rate in traffic... Yes we have tried it but it really becomes flacky... Global client is a solution, but I explained above why I wanted to use this to atleast define multiple nas boxes. Any box is allowed on the radius to put it bluntly I understand the risks and discussed this with the requestor. But it was talking the ups with the downs. Best regards Steve
-Arran
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html