freeradius and Cisco VPN IPSEC profiles authentication
Hi , I tried to setup configuration from different sources from the web, but it's not easy I have cisco vpn access server where are more IPSEC proflles ( groups ). They should be authenticated against Freeradius. One profile called Group1 should be authenticated against ntlm_auth_vpn ( already working), others against vpn_auth_name So my Users file is: DEFAULT Auth-Type := ntlm_auth_vpn, NAS-IP-Address == 10.1.1.252 Tunnel-Type = "ESP", Tunnel-Private-Group-ID = "Group1", Tunnel-Password = "cisco", Cisco-Avpair="ipsec:dns-servers=10.1.1.6 10.1.1.7", Cisco-Avpair="ipsec:addr-pool=vpn_pool", Cisco-Avpair="ipsec:inacl=101", Cisco-Avpair="ipsec:key-exchange=ike", Cisco-Avpair="ipsec:key-exchange=preshared-key", Service-Type = Framed-User, Framed-Protocol = PPP, DEFAULT Auth-Type := vpn_auth_name, , NAS-IP-Address == 10.1.1.252 Service-Type = Framed-User, Framed-Protocol = PPP, Fall-Through = Yes Point is that the group Group1 should be authenticated against ntlm_auth_vpn, other groups against vpn_auth_name However this config doesn't work, debug lokks strange ( takes only first Cisco Avpair attribute ), probably something wrong In the config Thanks fro your help pet
On 04/11/10 10:41, Jevos, Peter wrote:
DEFAULT Auth-Type := ntlm_auth_vpn, NAS-IP-Address == 10.1.1.252 Tunnel-Type = "ESP", Tunnel-Private-Group-ID = "Group1", Tunnel-Password = "cisco", Cisco-Avpair="ipsec:dns-servers=10.1.1.6 10.1.1.7", Cisco-Avpair="ipsec:addr-pool=vpn_pool",
This wrong; you want: Cisco-AVpair += "2nd:attribute" This is documented in the manpage and docs.
On 04/11/10 10:41, Jevos, Peter wrote:
DEFAULT Auth-Type := ntlm_auth_vpn, NAS-IP-Address == 10.1.1.252 Tunnel-Type = "ESP", Tunnel-Private-Group-ID = "Group1", Tunnel-Password = "cisco", Cisco-Avpair="ipsec:dns-servers=10.1.1.6 10.1.1.7", Cisco-Avpair="ipsec:addr-pool=vpn_pool",
This wrong; you want: Cisco-AVpair += "2nd:attribute" This is documented in the manpage and docs. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Thank you, it helped but it still doesn't work as I wished: All I need is: When request comes from 10.1.1.252 and Tunnel-Private-Group-ID = "Group1", use authentication ntlm_auth_vpn, and send back Cisco-av pairs (ipsec values) When request comes from whencesoever and Tunnel-Private-Group-ID is whatever, use authentication vpn_auth_name ,and that's it My current settings is: DEFAULT Auth-Type := ntlm_auth_vpn, NAS-IP-Address == 10.1.1.252 , Tunnel-Private-Group-ID == "Group1" Tunnel-Type = "ESP", Tunnel-Private-Group-ID = "Group1", Tunnel-Password = "cisco", Cisco-Avpair="ipsec:dns-servers=10.1.1.6 10.1.1.7", Cisco-Avpair="ipsec:addr-pool=vpn_pool", Cisco-Avpair="ipsec:inacl=101", Cisco-Avpair="ipsec:key-exchange=ike", Cisco-Avpair="ipsec:key-exchange=preshared-key", Service-Type = Framed-User, Framed-Protocol = PPP, Fall-Through = Yes DEFAULT Auth-Type := vpn_auth_name, Service-Type = Framed-User, Framed-Protocol = PPP, Thanks pet
On 04/11/10 15:25, Jevos, Peter wrote:
On 04/11/10 10:41, Jevos, Peter wrote:
DEFAULT Auth-Type := ntlm_auth_vpn, NAS-IP-Address == 10.1.1.252 Tunnel-Type = "ESP", Tunnel-Private-Group-ID = "Group1", Tunnel-Password = "cisco", Cisco-Avpair="ipsec:dns-servers=10.1.1.6 10.1.1.7", Cisco-Avpair="ipsec:addr-pool=vpn_pool",
This wrong; you want:
Cisco-AVpair += "2nd:attribute"
This is documented in the manpage and docs. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Thank you, it helped but it still doesn't work as I wished:
All I need is: When request comes from 10.1.1.252 and Tunnel-Private-Group-ID = "Group1", use authentication ntlm_auth_vpn, and send back Cisco-av pairs (ipsec values) When request comes from whencesoever and Tunnel-Private-Group-ID is whatever, use authentication vpn_auth_name ,and that's it
My current settings is:
DEFAULT Auth-Type := ntlm_auth_vpn, NAS-IP-Address == 10.1.1.252 , Tunnel-Private-Group-ID == "Group1" Tunnel-Type = "ESP", Tunnel-Private-Group-ID = "Group1", Tunnel-Password = "cisco", Cisco-Avpair="ipsec:dns-servers=10.1.1.6 10.1.1.7", Cisco-Avpair="ipsec:addr-pool=vpn_pool", Cisco-Avpair="ipsec:inacl=101", Cisco-Avpair="ipsec:key-exchange=ike", Cisco-Avpair="ipsec:key-exchange=preshared-key", Service-Type = Framed-User, Framed-Protocol = PPP, Fall-Through = Yes
You've set Fall-Through here - so your Auth-Type will be overwritten by the 2nd entry:
DEFAULT Auth-Type := vpn_auth_name, Service-Type = Framed-User, Framed-Protocol = PPP,
Remove the Fall-Through
Cisco-AVpair += "2nd:attribute"
This is documented in the manpage and docs. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Thank you, it helped but it still doesn't work as I wished:
All I need is: When request comes from 10.1.1.252 and Tunnel-Private-Group-ID = "Group1", use authentication ntlm_auth_vpn, and send back Cisco-av
pairs
(ipsec values) When request comes from whencesoever and Tunnel-Private-Group-ID is whatever, use authentication vpn_auth_name ,and that's it
My current settings is:
DEFAULT Auth-Type := ntlm_auth_vpn, NAS-IP-Address == 10.1.1.252 , Tunnel-Private-Group-ID == "Group1" Tunnel-Type = "ESP", Tunnel-Private-Group-ID = "Group1", Tunnel-Password = "cisco", Cisco-Avpair+="ipsec:dns-servers=10.1.1.6 10.1.1.7", Cisco-Avpair+="ipsec:addr-pool=vpn_pool", Cisco-Avpair+="ipsec:inacl=101", Cisco-Avpair+="ipsec:key-exchange=ike", Cisco-Avpair+="ipsec:key-exchange=preshared-key", Service-Type = Framed-User, Framed-Protocol = PPP, Fall-Through = Yes
You've set Fall-Through here - so your Auth-Type will be overwritten by the 2nd entry:
DEFAULT Auth-Type := vpn_auth_name, Service-Type = Framed-User, Framed-Protocol = PPP,
Dear Phil , thank you , I removed Fall through parameter, it works partially, when user comes from the address 10.1.1.252 and Tunnel-Private-Group-ID is not Group1, it takes the Auth-Type := ntlm_auth_vpn ( which is wrong ), and not Auth-Type := vpn_auth_name. Therefore there must be two conditions, one is NAS-IP-Address, second is PVT-Group thanks
On 04/11/10 15:52, Jevos, Peter wrote:
Dear Phil , thank you , I removed Fall through parameter, it works partially, when user comes from the address 10.1.1.252 and Tunnel-Private-Group-ID is not Group1, it takes the Auth-Type := ntlm_auth_vpn ( which is wrong ), and not Auth-Type := vpn_auth_name. Therefore there must be two conditions, one is NAS-IP-Address, second is PVT-Group
So, match both fields. Have you read the docs - specifically "man users" You want something like: DEFAULT Auth-Type := x, Service-Type == a, Tunnel-Private-Group-Id == b Reply-Var-1 = ... Note: ALL the conditions must be on the 1st line
On 04/11/10 15:52, Jevos, Peter wrote:
Dear Phil , thank you , I removed Fall through parameter, it works partially, when user comes from the address 10.1.1.252 and Tunnel-Private-Group-ID is not Group1, it takes the Auth-Type := ntlm_auth_vpn ( which is wrong ), and not Auth-Type := vpn_auth_name. Therefore there must be two conditions, one is NAS-IP-Address, second is PVT-Group
So, match both fields. Have you read the docs - specifically "man users" You want something like: DEFAULT Auth-Type := x, Service-Type == a, Tunnel-Private-Group-Id == b Reply-Var-1 = ... Note: ALL the conditions must be on the 1st line - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Thank fo your reply, hoever as you can see from my previous posts, I did it: DEFAULT Auth-Type := ntlm_auth_vpn, NAS-IP-Address == 10.1.1.252,Tunnel-Private-Group-ID == "Group1" Tunnel-Type = "ESP", Tunnel-Private-Group-ID = "Group1", .... So in the first line is: DEFAULT Auth-Type := ntlm_auth_vpn, NAS-IP-Address == 10.1.1.252,Tunnel-Private-Group-ID == "Group1"
On 04/11/10 16:15, Jevos, Peter wrote:
Thank fo your reply, hoever as you can see from my previous posts, I did it:
Frankly I find your posts confusing; your email client doesn't quote properly and mangles the text wrapping, so I had no way to be sure. Post full debug output of a failing request.
On 04/11/10 16:15, Jevos, Peter wrote:
Thank fo your reply, hoever as you can see from my previous posts, I did it:
Frankly I find your posts confusing; your email client doesn't quote properly and mangles the text wrapping, so I had no way to be sure. Post full debug output of a failing request. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html I'm sorry , It's outlook : ) Point is if I use Tunnel-Private-Group-ID == "Group1" as the condition on the dirst line, it doesn't work, it skips and goes to another auth method. DEFAULT Auth-Type := ntlm_auth_vpn, NAS-IP-Address == 10.1.1.252,Tunnel-Private-Group-ID == "Group1" Other statemts ...
Hi How can I skip to the second DEFAULT if the first DEFAULT doesn't pass ? So if request comes from the 10.1.1.2 and user doesn't pass through authentication, it should be forwarded to another DEFAULT ( with the vpn_auth_name authentication). Now it stops at the first DEFAULT DEFAULT Auth-Type := ntlm_auth_vpn, NAS-IP-Address == 10.1.1.252 Tunnel-Type = "ESP", Tunnel-Private-Group-ID = "Group", Tunnel-Password = "cisco", Cisco-Avpair += "ipsec:dns-servers=10.1.1.6 10.1.1.7", Cisco-Avpair += "ipsec:addr-pool=vpn_pool", Cisco-Avpair += "ipsec:inacl=101", Cisco-Avpair += "ipsec:key-exchange=ike", Cisco-Avpair += "ipsec:key-exchange=preshared-key", Service-Type = Framed-User, Framed-Protocol = PPP, DEFAULT Auth-Type := vpn_auth_name, NAS-IP-Address == 10.1.1.252 Service-Type = Framed-User, Framed-Protocol = PPP, thanks
Jevos, Peter wrote:
How can I skip to the second DEFAULT if the first DEFAULT doesn’t pass ?
Use the "Fall-Through" attribute. See comments in the default "users" file.
So if request comes from the 10.1.1.2 and user doesn’t pass through authentication, it should be forwarded to another DEFAULT ( with the vpn_auth_name authentication).
That is *completely* different from the previous question, and much more difficult. The "users" file is only processed once, at the "authorize" stage. You're asking for something else to happen if authentication fails. i.e. when the "users" is no longer being processed. A much better choice is to set the authentication type only once. i.e. "if the user is in group X, do ntlm_auth. Otherwise, vpn_auth" Alan DeKok.
Jevos, Peter wrote:
How can I skip to the second DEFAULT if the first DEFAULT doesn’t pass ?
Use the "Fall-Through" attribute. See comments in the default "users" file.
So if request comes from the 10.1.1.2 and user doesn’t pass through
authentication, it should be forwarded to another DEFAULT ( with the
vpn_auth_name authentication).
That is *completely* different from the previous question, and much more difficult. The "users" file is only processed once, at the "authorize" stage. You're asking for something else to happen if authentication fails. i.e. when the "users" is no longer being processed. A much better choice is to set the authentication type only once. i.e. "if the user is in group X, do ntlm_auth. Otherwise, vpn_auth" Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Thanks for your answer Alan Fall-through attribute doesn’t work in this case, cause it is “falling” all the time ( even though it matches the condition ) However, let’s think about this classic case: You have one router, with more profiles to connect ( different pools, dns, and so on ) Every profile should have its authentication against different AD group So it is not possible to solve it through USERS file ? Thanks pet
Jevos, Peter wrote:
Fall-through attribute doesn’t work in this case, cause it is “falling” all the time ( even though it matches the condition )
You're not getting what I'm saying. The "users" file does *not* run during the "authenticate" phase. So it makes no sense to ask about modifying the "users" file contents to change the "authenticate" process flow.
However, let’s think about this classic case: You have one router, with more profiles to connect ( different pools, dns, and so on )
Every profile should have its authentication against different AD group
A group does not supply authentication information. Again, proper terminology is *critical* to designing a good solution. When you use the wrong terminology, it means you're not clear on how things work, and any solution you design will be based on incorrect assumptions. The solution here is to define which situations require which authentication methods. Usually, this is as easy as looking at the packet. Look for differences in the packet between what you want as authentication method "A" versus authentication method "B". Then, write logic to say "when the packet looks like X, choose A. When it looks like Y, choose B". This is *much* simpler and saner than "everyone try A, if it fails, try B, if that fails, try C, ..." Think of it this way: If you're driving to Disneyland, you look up the destination on a map, and drive there. You don't drive to Chicago, realize you're in the wrong place, and ask the locals for directions to Disneyland.
So it is not possible to solve it through USERS file ?
As I've said, no. Alan DeKok.
Jevos, Peter wrote:
Fall-through attribute doesn’t work in this case, cause it is “falling” all the time ( even though it matches the condition )
You're not getting what I'm saying. The "users" file does *not* run during the "authenticate" phase. So it makes no sense to ask about modifying the "users" file contents to change the "authenticate" process flow.
However, let’s think about this classic case: You have one router, with more profiles to connect ( different pools, dns, and so on )
Every profile should have its authentication against different AD group
A group does not supply authentication information. Again, proper terminology is *critical* to designing a good solution. When you use the wrong terminology, it means you're not clear on how things work, and any solution you design will be based on incorrect assumptions. The solution here is to define which situations require which authentication methods. Usually, this is as easy as looking at the packet. Look for differences in the packet between what you want as authentication method "A" versus authentication method "B". Then, write logic to say "when the packet looks like X, choose A. When it looks like Y, choose B". This is *much* simpler and saner than "everyone try A, if it fails, try B, if that fails, try C, ..." Think of it this way: If you're driving to Disneyland, you look up the destination on a map, and drive there. You don't drive to Chicago, realize you're in the wrong place, and ask the locals for directions to Disneyland.
So it is not possible to solve it through USERS file ?
As I've said, no. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Thank you Alan I agree with you , regarding the logic "when the packet looks like X, choose A. When it looks like Y, choose B" I sit possible to apply it ? Which files should be affected ? The point is that I'm missing packet workflow in the freeradius, during its processing ( something like has postfix : http://www.postfix.org/OVERVIEW.html ) It means so I have no idea what files should be changed, therefore I thought that users file solves everything Thanks pet
Jevos, Peter wrote: First, edit your posts to delete unneeded text. Repeating all of the message you're replying to is unfriendly.
I agree with you , regarding the logic "when the packet looks like X, choose A. When it looks like Y, choose B" I sit possible to apply it ? Which files should be affected ?
See "man unlang". Put the logic into raddb/sites-available/default, the "authorize" section.
The point is that I'm missing packet workflow in the freeradius, during its processing ( something like has postfix : http://www.postfix.org/OVERVIEW.html )
See doc/aaa.rst (or doc/aaa.txt, depending on the FR version)
It means so I have no idea what files should be changed, therefore I thought that users file solves everything
Uh... read the debug output, and look at the files in the "raddb" directory. The directory has more than *one* file. This should be a hint that the "users" file doesn't solve everything. Alan DeKok.
See "man unlang". Put the logic into raddb/sites-available/default, the "authorize" section. Uh... read the debug output, and look at the files in the "raddb" directory. The directory has more than *one* file. This should be a hint that the "users" file doesn't solve everything. Alan DeKok. Hi Alan, , thanks , I've read it but it's too complicated and I'm missing more examples of configurations If anybody help me with the syntax and code location with this issue: If requests come from NAS-IP-Address==1.1.1.1 and the %{mschap:NT-Domain}=vipdomainuser , check them against module ntlm_auth_vip ( module is already working ) and if pass give them Cisco-Avpair += "ipsec:addr-pool=vip_vpn_pool" and other optional AVpairs. If request comes from NAS-IP-Address==1.1.1.1 and the %{mschap:NT-Domain}=guestdomainuser , check them against module ntlm_auth_guests and if pass give them Cisco-Avpair += "ipsec:addr-pool=guest_vpn_pool" and other optional AVpairs. Other point is that none can get the AV pair "ipsec:addr-pool=vip_vpn_pool" if the %{mschap:NT-Domain} is not vipdomainuser Thank a lot for any hint pet
On 11/11/10 15:49, Jevos, Peter wrote:
See "man unlang". Put the logic into raddb/sites-available/default,
the "authorize" section.
Uh... read the debug output, and look at the files in the "raddb"
directory. The directory has more than *one* file. This should be a
hint that the "users" file doesn't solve everything.
Alan DeKok.
Hi Alan, , thanks , I’ve read it but it’s too complicated and I’m missing more examples of configurations
If anybody help me with the syntax and code location with this issue:
If requests come from NAS-IP-Address==1.1.1.1 and the %{mschap:NT-Domain}=vipdomainuser , check them against module ntlm_auth_vip ( module is already working ) and if pass give them Cisco-Avpair += "ipsec:addr-pool=vip_vpn_pool" and other optional AVpairs.
Just add the Cisco-AVPair when you do "if (NAS-IP-Address == ..)" i.e. authorize { if ((NAS-IP-Address == xxx) && (...condition...)) { update control { Auth-Type = ntlm_auth_vip } update reply { Cisco-AVPair += "..." } } } ...then: authenticate { Auth-Type ntlm_auth_vip { ntlm_auth_vip } } ...and, as per the DEFAULT CONFIG! post-auth { ... Post-Auth-Type REJECT { attr_filter.access_reject } } ...the attribute filter in the reject will remove the Cisco-AVPair if the request is rejected.
Thank you phill, that's great help, but it still doesn't work as it should. Now I don't know how should I adjust the users file : ) I used if ((NAS-IP-Address == 1.1.1.1) && "%{mschap:NT-Domain}" = "vipdomainuser")) { update control { Auth-Type := ntlm_auth_vip } update reply { Cisco-AVPair += "ipsec:addr-pool=vip_vpn_pool" } } And in the user file is: DEFAULT Auth-Type := ntlm_auth_vpn_osw Service-Type = Framed-User, Framed-Protocol = PPP, With this it's working as it should , however if request comes from the different NT-Domain then "vipdomainuser" it's blocked ( according the ntlm_auth_vip ), and it doesn't go to another DEFAULT rule where everybody can pass. I trid also Fall-through parameter, it didn't work as well, I'm sorry that I'm bothering again ( Alan tried to explain me many times ), but I was using MS IAS many years, and my concepts come from this system Thank you
Jevos, Peter wrote:
Thank you phill, that's great help, but it still doesn't work as it should. Now I don't know how should I adjust the users file : )
You don't. The messages on this list should make it *very* clear that updating the "authorize" section is all that is necessary.
With this it's working as it should , however if request comes from the different NT-Domain then "vipdomainuser" it's blocked ( according the ntlm_auth_vip ), and it doesn't go to another DEFAULT rule where everybody can pass.
So.... *think* a little bit. You wrote two rules in an earlier email. One was translated for you into "unlang". It should be relatively easy to translate the *second* one into "unlang". As a hint, if you don't implement a rule for a different NT-Domain, then the rules for that different NT-Domain won't be applied. Because they don't exist. Alan DeKok.
As a hint, if you don't implement a rule for a different NT-Domain, then the rules for that different NT-Domain won't be applied. Because they don't exist. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Thank you Alan , it makes sense. But it doesn't solve my problem In my cisco configuration there is a group: crypto isakmp client configuration group vipgroup key xxxx dns 1.1.11.10 1.1.11.11 wins 1.1.11.12 1.1.11.13 pool vpn-vipgroup How could i ensure that this group with this parameters will be accesible only for the users from the domain vipdomainusers ( e.g. ntlm_auth_vipusers authentication) ? The other groups configured on the same router will be accessible for any domain users ( but i cannot name hundreds domains in the freeradius config ) point is that cisco radius doesn't send a group name ( vipgroup ) in the request to the radius server Ok, i can return CiscoAv pairs (pool, dns... )to the router, but still if any domain user try to connect to the group vipgroup, it recieves the pool and other parameters thanks, you're great that you can help us pet thanks
Jevos, Peter wrote:
Thank you Alan , it makes sense. But it doesn't solve my problem
(1) Edit your responses. It shows consideration for other people (2) pick one problem at a time. Changing "the problem" midway in a conversation makes it look like you don't care about the solution to the first problem.
In my cisco configuration there is a group: crypto isakmp client configuration group vipgroup key xxxx dns 1.1.11.10 1.1.11.11 wins 1.1.11.12 1.1.11.13 pool vpn-vipgroup
How could i ensure that this group with this parameters will be accesible only for the users from the domain vipdomainusers ( e.g. ntlm_auth_vipusers authentication) ?
Go back and read my messages again. Is there anything in the RADIUS packet which will distinguish the different groups? If not, you're out of luck.
The other groups configured on the same router will be accessible for any domain users ( but i cannot name hundreds domains in the freeradius config )
point is that cisco radius doesn't send a group name ( vipgroup ) in the request to the radius server
Go ask Cisco to fix their equipment. Alan DeKok.
Jevos, Peter wrote:
Hi Alan, , thanks , I’ve read it but it’s too complicated and I’m missing more examples of configurations
The raddb directory *does* come with examples.
If anybody help me with the syntax and code location with this issue:
Sorry, but: 1) the "unlang" documentation contains a detailed description of the syntax 2) my previous message gave the *specific* location of where the logic should go. *PLEASE* read the existing documentation and messages on this list. Failure to do so is a major reason for not solving issues.
If requests come from NAS-IP-Address==1.1.1.1 and the %{mschap:NT-Domain}=vipdomainuser , check them against module ntlm_auth_vip ( module is already working ) and if pass give them Cisco-Avpair += "ipsec:addr-pool=vip_vpn_pool" and other optional AVpairs.
The "unlang" syntax is pretty much exactly that. It's not that hard. if ((NAS-IP-Address == 1.1.1.1) && "%{mschap:NT-Domain}" = "vipdomainuser")) { update control { Auth-Type := ntlm_auth_vip } update reply { Cisco-AVPair += "ipsec:addr-pool=vip_vpn_pool" } } Alan DeKok.
participants (4)
-
Alan DeKok -
Jevos, Peter -
Johan Meiring -
Phil Mayers