lifetime of dynamic clients
Dear all, I have rebuild freeradius on debian 7.0. I have added rlm_raw and have a working dynamic client configuration where I use Called_Station_ID to authenticate / validate that a NAS is allowed to use this radius server. I test using the following command on client A echo "NAS-IP-Address=10.1.2.236, Called-Station-Id=00:40:96:aa:bb:ee,User-Name='testradius',User-Password='test'," | radclient -c '1' -n '3' -r '3' -t '3' -x '46.18.36.232:1812' 'auth' 'mysecret' I can see in the logs that is is checking the first time I log on and it is properly giving the message adding client xxx.xxx.xxx.xxx with shared secret. Now, when I executed the same command on a different machine Client B, it runs through it again. (Same command, I only had 1 nas added to it ) It adds the new 'client' to the dynamic clients. I wait for a couple of minutes and I executed the following command of client A: echo "NAS-IP-Address=10.1.2.236, Called-Station-Id=00:40:96:aa:bb:cc,User-Name='testradius',User-Password='test'," | radclient -c '1' -n '3' -r '3' -t '3' -x '46.18.36.232:1812' 'auth' 'mysecret' This has a faulty Called-Station-Id in it. I would assume that it would not allow me to connect. But this appears to still work. I am wondering - The first time the IP address of client A is added to the list of known client - So the second time , it will check first in the list if the IP is known, if so it won't go checking using the process defined in dynamic clients? But no matter how long I wait, it appears that the cache if not cleared. I have added a lifetime of 60 in the dynamic client conf, so I would assume that if I wait for a minute, the IP of client A would not be known, and it would go through checking again. Am I wrong in this? If not can I read the cache to find out why it is keeping that record? Kind regards Steve
steve@comitcon.be wrote:
I have rebuild freeradius on debian 7.0. I have added rlm_raw and have a working dynamic client configuration where I use Called_Station_ID to authenticate / validate that a NAS is allowed to use this radius server.
That's not a recommended configuration.
I wait for a couple of minutes and I executed the following command of client A: echo "NAS-IP-Address=10.1.2.236, Called-Station-Id=00:40:96:aa:bb:cc,User-Name='testradius',User-Password='test'," | radclient -c '1' -n '3' -r '3' -t '3' -x '46.18.36.232:1812' 'auth' 'mysecret'
This has a faulty Called-Station-Id in it. I would assume that it would not allow me to connect. But this appears to still work.
Of course. RADIUS depends on IP addresses, not on Called-Station-Id. This is documented in the "dynamic_clients" configuration. Right at the top of the virtual server.
I am wondering - The first time the IP address of client A is added to the list of known client - So the second time , it will check first in the list if the IP is known, if so it won't go checking using the process defined in dynamic clients?
That's what the documentation says.
But no matter how long I wait, it appears that the cache if not cleared.
I have added a lifetime of 60 in the dynamic client conf, so I would assume that if I wait for a minute, the IP of client A would not be known, and it would go through checking again.
That's how it works.
Am I wrong in this? If not can I read the cache to find out why it is keeping that record?
You can use "radmin" to query the server about a client. It won't show you the lifetime of that client. But it will show you if the client still exists. And as always, run the server in debugging more. READ the output. It tells you exactly what's going on, and why. Alan DeKok.
Dear Alan see my comments below
steve@comitcon.be wrote:
I have rebuild freeradius on debian 7.0. I have added rlm_raw and have a working dynamic client configuration where I use Called_Station_ID to authenticate / validate that a NAS is allowed to use this radius server.
That's not a recommended configuration.
1. FreeRadius lacks the ability to actually run Nas's behind a link with a dynamic IP. Although not recommended, this software does not support a proper way of dealing with this.
I wait for a couple of minutes and I executed the following command of client A: echo "NAS-IP-Address=10.1.2.236, Called-Station-Id=00:40:96:aa:bb:cc,User-Name='testradius',User-Password='test'," | radclient -c '1' -n '3' -r '3' -t '3' -x '46.18.36.232:1812' 'auth' 'mysecret'
This has a faulty Called-Station-Id in it. I would assume that it would not allow me to connect. But this appears to still work.
This is indeed a fake. I have added this in mysql in the nas table under the field community (described in ify /yfi setup). The connection actually works. I can (ab)use this field as much as desired
Of course. RADIUS depends on IP addresses, not on Called-Station-Id. This is documented in the "dynamic_clients" configuration. Right at the top of the virtual server.
Yes, I have read the documentation (multiple sources, google etc...) I was just wondering what happens when you use the raw module.
I am wondering - The first time the IP address of client A is added to the list of known client - So the second time , it will check first in the list if the IP is known, if so it won't go checking using the process defined in dynamic clients?
That's what the documentation says.
Again, yep, read the docs... It is also stated in the yfi docs in the remarks below their dynamic client section.
But no matter how long I wait, it appears that the cache if not cleared.
I have added a lifetime of 60 in the dynamic client conf, so I would assume that if I wait for a minute, the IP of client A would not be known, and it would go through checking again.
That's how it works.
Am I wrong in this? If not can I read the cache to find out why it is keeping that record?
You can use "radmin" to query the server about a client. It won't show you the lifetime of that client. But it will show you if the client still exists.
Is a client defined by a NAS or a user? Because I need to figure out how or when the dynamic client is remove from the cache?
And as always, run the server in debugging more. READ the output. It tells you exactly what's going on, and why.
The output shows indeed when it goes through the the dynamic server section and once it is authenticated it only runs through the default (which is understandable) Steve
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
1. FreeRadius lacks the ability to actually run Nas's behind a link with a dynamic IP. Although not recommended, this software does not support a proper way of dealing with this.
Nonsense. This is a fundamental limitation of the RADIUS protocol. If you want to use dynamic IPs, use a VPN, or TLS (RFC 6614)
This is indeed a fake. I have added this in mysql in the nas table under the field community (described in ify /yfi setup). The connection actually works. I can (ab)use this field as much as desired
Because RADIUS depends on source IP.
Of course. RADIUS depends on IP addresses, not on Called-Station-Id. This is documented in the "dynamic_clients" configuration. Right at the top of the virtual server.
Yes, I have read the documentation (multiple sources, google etc...) I was just wondering what happens when you use the raw module.
It's not distributed with the server. So it's not a supported module. And no, I don't use it. And no, you haven't read the documentation. The files I mentioned *clearly* states that the dynamic clients use and cache the source IP. They say NOTHING about checking the Called-Station-Id for each packet.
Is a client defined by a NAS or a user?
RADIUS clients are defined by source IP. The documentation you allegedly read makes this clear. So there's no need to ask the above question... because the documentation already answers it.
The output shows indeed when it goes through the the dynamic server section and once it is authenticated it only runs through the default (which is understandable)
So... *nothing* else in the debug output is useful to you. I guess you've read it as carefully as you've read the documentation. Alan DeKok.
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. 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. Fourhtly, the issue I have has nothing to do with the whole running of rlm_raw or any alike. Authentication works fine and as expected. And yes I have read the statements on caching , what is used and even the disclaimer that only the src ip is supported. So don't become patronising that I didn't. I also scrobbled google for quite some time and I have read the debug more than you can think. But guess what? If the only output after authentication is adding client xxx.xxx.xxx.xxx with shared secret it does not state a) lifetime b) anything else usefull. 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. Best regards Steve
1. FreeRadius lacks the ability to actually run Nas's behind a link with a dynamic IP. Although not recommended, this software does not support a proper way of dealing with this.
Nonsense. This is a fundamental limitation of the RADIUS protocol.
If you want to use dynamic IPs, use a VPN, or TLS (RFC 6614)
This is indeed a fake. I have added this in mysql in the nas table under the field community (described in ify /yfi setup). The connection actually works. I can (ab)use this field as much as desired
Because RADIUS depends on source IP.
Of course. RADIUS depends on IP addresses, not on Called-Station-Id. This is documented in the "dynamic_clients" configuration. Right at the top of the virtual server.
Yes, I have read the documentation (multiple sources, google etc...) I was just wondering what happens when you use the raw module.
It's not distributed with the server. So it's not a supported module. And no, I don't use it.
And no, you haven't read the documentation. The files I mentioned *clearly* states that the dynamic clients use and cache the source IP. They say NOTHING about checking the Called-Station-Id for each packet.
Is a client defined by a NAS or a user?
RADIUS clients are defined by source IP. The documentation you allegedly read makes this clear. So there's no need to ask the above question... because the documentation already answers it.
The output shows indeed when it goes through the the dynamic server section and once it is authenticated it only runs through the default (which is understandable)
So... *nothing* else in the debug output is useful to you.
I guess you've read it as carefully as you've read the documentation.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
steve@comitcon.be wrote:
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.
Perhaps you could read the *content* of my messages, instead of inventing some emotional projection.
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).
So you read the documentation saying that clients are defined by IP addresses, and then asked whether or not clients are defined by NAS or by user. Did you (a) NOT read the documentation, or (b) read it and not understand it, or (c) read it, understand it, and ask a misleading question?
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.
People do all kinds of crazy things. That doesn't mean those things are a good idea. It's fairly conceited for you, a non-expert, to lecture me about RADIUS.
Fourhtly, the issue I have has nothing to do with the whole running of rlm_raw or any alike. Authentication works fine and as expected.
I'm not really clear on the issue you're having, because your statements are contradictory. Am I allowed to get frustrated at that?
And yes I have read the statements on caching , what is used and even the disclaimer that only the src ip is supported. So don't become patronising that I didn't.
Learn how to deal with people telling you you're wrong. It's a skill many adults have.
I also scrobbled google for quite some time and I have read the debug more than you can think. But guess what? If the only output after authentication is adding client xxx.xxx.xxx.xxx with shared secret
it does not state a) lifetime b) anything else usefull.
It shows the IP of the client. It does NOT say "adding client keyed by Called-Station-Id" See? The debug output says what it means, and means what it says. Because you're unwilling to take it at face value, you think it's useless. That says more about you than anything else.
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.
You have no business making that demand. See the last paragraph of this message for my response. You asked a question and you got told an answer. When you made mistakes, they were pointed out. We CANNOT help you if your questions are unclear, or if your statements are contradictory. You have NO BUSINESS getting offended when people try to help you.
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.
Read the documentation. Follow instructions. Don't argue with the experts. It's not hard. If you fail to follow instructions, or if you keep arguing about the instructions, or if you keep complaining when I answer your questions, you will be unsubscribed and permanently banned from this list. Such behavior is anti-social, rude, and will NOT be tolerated. Alan DeKok.
Replied in between
steve@comitcon.be wrote:
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.
Perhaps you could read the *content* of my messages, instead of inventing some emotional projection.
Half of what you actually stated is reading the manual.
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).
So you read the documentation saying that clients are defined by IP addresses, and then asked whether or not clients are defined by NAS or by user.
That is a) not the question b) I was trying to clear confusion on clients.
Did you (a) NOT read the documentation, or (b) read it and not understand it, or (c) read it, understand it, and ask a misleading question?
Correct I might have a asked a misleading question, considering I added commands I send, how it is configured and your first response is 'not recommended'
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.
People do all kinds of crazy things. That doesn't mean those things are a good idea. It's fairly conceited for you, a non-expert, to lecture me about RADIUS.
It is fairly clear that the experts claim they have the knowledge , but are guarding it. But considering I am using linux since '95 I am quite used to by now. Unfortunately, it is remarks and conceiled 'RTFM's that keep people from using OSS. Whether or not YFI is doing stuff with is crazy, it is what is needed in the current day and age. You can decide it is crazy, but I prefer a working crazy solution, next to a non-solution. I am secondly not lecturing you on how to use Radius, but you are "expert" are neither teaching me, by referring me to files I have read multiple times. Trust me, I do not jump into something without considering, testing and playing. Actually before working and trying this on a test system, I spend multiple days just installing, reading etc...
Fourhtly, the issue I have has nothing to do with the whole running of rlm_raw or any alike. Authentication works fine and as expected.
I'm not really clear on the issue you're having, because your statements are contradictory.
For the record The IP address of a client is added using dynamic. I have set the lifetime to 60 (and the file states seconds), but it is not removed after 1 minute or even more. show client list in radmin also keeps showing it. Therefor I was actually looking at finding the contents of the cache.
Am I allowed to get frustrated at that?
So you admit you are frustrated? With all best respect, I love people being helpfull, willing to test and try out. But if the immediate respons is "not recommended", well don't bother responding because people might have proper reasons for using it this way. The question was also asked to this mailinglist and not only you. There might be others who are using this in a similar fashion.
And yes I have read the statements on caching , what is used and even the disclaimer that only the src ip is supported. So don't become patronising that I didn't.
Learn how to deal with people telling you you're wrong. It's a skill many adults have.
Learn to adjust to the needs of the real world. This is not a student pet thing here. I am merely walking the boundaries of what the system is doing. You know, I could make the system check in using perl/php and update the IP address as I am using SQL as a backend. Same deal. But no, I don't see a purpose on a security level on doing it with rlm_raw / dynamic clients etc...
I also scrobbled google for quite some time and I have read the debug more than you can think. But guess what? If the only output after authentication is adding client xxx.xxx.xxx.xxx with shared secret
it does not state a) lifetime b) anything else usefull.
It shows the IP of the client. It does NOT say "adding client keyed by Called-Station-Id"
See? The debug output says what it means, and means what it says. Because you're unwilling to take it at face value, you think it's useless.
You know, I just needed to find out if the lifetime 60 will work because I don't see it. The changelog of FR actually state at a certain revision it was defaulted to 1 hour in case of lacking. Maybe there is a minimum?
That says more about you than anything else.
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.
You have no business making that demand. See the last paragraph of this message for my response.
What is the point is responding when you refer to something I have said. And see the last paragraph in my message...
You asked a question and you got told an answer. When you made mistakes, they were pointed out. We CANNOT help you if your questions are unclear, or if your statements are contradictory. You have NO BUSINESS getting offended when people try to help you.
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.
Read the documentation. Follow instructions. Don't argue with the experts. It's not hard.
*hail to god?* an expert who refuses to set up a system (might not even be in real life, but a matter as experimenting?) Sorry from an expert I expect atleast the full reasons (or links) to the security issues which are claimed. Secondly an expert would give me the response to the simple question. Of course, within this world you are the expert. Honestly, respect for that.
If you fail to follow instructions, or if you keep arguing about the instructions, or if you keep complaining when I answer your questions, you will be unsubscribed and permanently banned from this list. Such behavior is anti-social, rude, and will NOT be tolerated.
You know, you are trully the entitlement of the linux guru. The one who knows. But pay attention if you go one step beyond. But no problem, I'll try YFI as they are willing to try that. For the anti-social? An email starts with a header, most people end with kind regards too. And I have scrobbled a lot of your email. They refer to a documention which is unclear, in text files and not in a book form. No offence, when I started using linux (15+ years), there was flame wars, RTFM's etc... I though the community became much more. Sad to see this is the evolution. So play god. And for the record , you did not answer the question. You told me "it should not be done" and I should read the documents. Next to giving me an amusing evening, it did not help me, nor even pointed me to the proper direction. And with all do respect. Radmin showed me the clients are removed, just the time is unclear and it sure is not 60 seconds. So we might focus on the lifetime which is not removing the client in the 60 seconds (or would the documentation be wrong and is it minutes?) You really believe I care for this? If you can't make an argument because you need to point out that you believe it's rude and you have rights??? Be a god, if you are bigger than this, you might actually respond with something usefull. If Linus followed the directions, we would not have Linux. You move boundaries. Are you doing that by stating the obvious? Well guess I won't know the respons as I will probably be not on this list any longer. But do yourself a favor... Read this again in 6 months and ask yourself how many people moved to another solution because this is not support. This is telling people they are too stupid to read and basically "I won't support this". I even did an strace. Did you know if the sql queries don't work properly in dynamic_clients, FR crashes? I used this because FR is the only free , OSS solution which seemed good for my purpose. And yes, it is clear that you won't help me, nor are able to as you never used rlm_raw (or are not willing to try it) Now this you can call rude. I was being polite in the previous mails.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
steve@comitcon.be wrote:
It is fairly clear that the experts claim they have the knowledge , but are guarding it.
Ah, yes. That's why I've wrote tons of documentation for the server, and have answered questions daily for 15 years. I'm trying to hide RADIUS knowledge.
I am secondly not lecturing you on how to use Radius,
Nonsense. You lectured me on the use-case for rlm_raw.
but you are "expert" are neither teaching me, by referring me to files I have read multiple times.
Well, you didn't say that. If you don't say what you're doing, it's a form of lying.
For the record The IP address of a client is added using dynamic. I have set the lifetime to 60 (and the file states seconds), but it is not removed after 1 minute or even more. show client list in radmin also keeps showing it.
Well, it works for me. Did you try sending another packet after 60 seconds? What happened?
So you admit you are frustrated? With all best respect, I love people being helpfull, willing to test and try out. But if the immediate respons is "not recommended", well don't bother responding because people might have proper reasons for using it this way.
I see. You're not a RADIUS expert, so you ask a question. When a RADIUS expert answers you, you disagree, and think they're wrong. And you say *I* am unhelpful?
Learn to adjust to the needs of the real world. This is not a student pet thing here. I am merely walking the boundaries of what the system is doing. You know, I could make the system check in using perl/php and update the IP address as I am using SQL as a backend. Same deal. But no, I don't see a purpose on a security level on doing it with rlm_raw / dynamic clients etc...
That's why you're not a RADIUS expert, and I am.
You know, I just needed to find out if the lifetime 60 will work because I don't see it. The changelog of FR actually state at a certain revision it was defaulted to 1 hour in case of lacking. Maybe there is a minimum?
I just checked. There isn't.
an expert who refuses to set up a system
Where the HELL did you get that idea from? And what kind of entitlement do you have? I'm supposed to do things for free to check that you've likely misconfigured things? Are you paying me? Do you even know how open source works?
(might not even be in real life, but a matter as experimenting?) Sorry from an expert I expect atleast the full reasons (or links) to the security issues which are claimed. Secondly an expert would give me the response to the simple question.
I expect that I can have technical discussions without people getting upset when I tell then they're wrong. That's what makes me an expert, and makes you banned from the list. I'm willing to learn from others. You're not.
Now this you can call rude. I was being polite in the previous mails.
Refusing to follow instructions is rude. Complaining when I tell you you're wrong is rude. Refusing to learn is rude. Goodbye. Alan DeKok.
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
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
For those interested: Information gotten from http://sourceforge.net/apps/trac/hotcakes/wiki/YfiTechDynamicClients In regards to the usage of Called_Station_Id, rlm_raw and SQL checks. Kind regards Steve
1. FreeRadius lacks the ability to actually run Nas's behind a link with a dynamic IP. Although not recommended, this software does not support a proper way of dealing with this.
Nonsense. This is a fundamental limitation of the RADIUS protocol.
If you want to use dynamic IPs, use a VPN, or TLS (RFC 6614)
This is indeed a fake. I have added this in mysql in the nas table under the field community (described in ify /yfi setup). The connection actually works. I can (ab)use this field as much as desired
Because RADIUS depends on source IP.
Of course. RADIUS depends on IP addresses, not on Called-Station-Id. This is documented in the "dynamic_clients" configuration. Right at the top of the virtual server.
Yes, I have read the documentation (multiple sources, google etc...) I was just wondering what happens when you use the raw module.
It's not distributed with the server. So it's not a supported module. And no, I don't use it.
And no, you haven't read the documentation. The files I mentioned *clearly* states that the dynamic clients use and cache the source IP. They say NOTHING about checking the Called-Station-Id for each packet.
Is a client defined by a NAS or a user?
RADIUS clients are defined by source IP. The documentation you allegedly read makes this clear. So there's no need to ask the above question... because the documentation already answers it.
The output shows indeed when it goes through the the dynamic server section and once it is authenticated it only runs through the default (which is understandable)
So... *nothing* else in the debug output is useful to you.
I guess you've read it as carefully as you've read the documentation.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
steve@comitcon.be wrote:
For those interested:
Information gotten from
http://sourceforge.net/apps/trac/hotcakes/wiki/YfiTechDynamicClients
In regards to the usage of Called_Station_Id, rlm_raw and SQL checks.
Which notes that rlm_raw doesn't come with the server. The reason is simple. It's not necessary, and a security risk. There have been a number of requests to include rlm_raw, and the answer has been (and will always be) "no". There are alternatives which are more secure, and generally better. Alan DeKok.
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
steve＠comitcon.be