RE : RE : RE : IP Pool management and Re-authentication
Thibault Le Meur wrote: I've patched the radiusplugin to add Framed-IP-Address to the re-auth request but rlm_ippool still allocates a new IP Address (I'm using FR 1.1.4). Ok. It seems like rlm_ippool should be updated to look for Framed-IP-Address in the request. That would be very useful, and would solve the problem you're seeing. Alan DeKok. Do you mean updated (to 1.1.5) or patched ? Never mind I found the answer by looking at the code from rlm_ippool.c. Currently, when an Access-Request arrives, rlm_ippool: * looks in the pool for an 'active' entry (flagged as active) with the key=NAS-IP/NAS-port * If no entry is found == rlm_ippool allocates an @IP from the pool * If an active entry is found == it is considered as a stale entry and is marked as not active (active=0) == then a new IP is allocated If rlm_ippool is 'updated' to take Framed-IP-Address into account what shoudl be the behaviour ? A simple patch would consist of doing nothing at Post-Auth time if the request contains a Framed-IP-Address. A more complex patch should handle several different cases and decide what to do. For instance: * when Access-Request is received, look for an active entry in the pool with the search key NAS-IP/NAS-port * If no entry is found * If there is No Framed-IP-Address attribute in the Request == allocate a new @IP from the pool * If there is a Framed-IP-Address attribute in the Request * If the Framed-IP-Address belongs to the IP-range of the pool (but it is not assigned to this NAS-IP/NAS-port) == then issue a warning log (especially if this IP is allocated to an active entry for another NAS-IP/NAS-port) == do not allocate a new @IP ??? (Or should we enforce a new IP, without beeing sure the NAS will be able to use it ?) * If the Framed-IP-Address doesn't belong to the IP-range of the pool == do not allocate a new @IP * If an entry is found (there is already an allocated @IP for this NAS-IP/NAS-port) * If there is a Framed-IP-Address attribute in the Request * If this Framed-IP-Address is the same as the allocated IP from the entry found == then do nothing (no stale marking, no new @IP allocation) * If this Framed-IP-Address is NOT the same as the allocated IP from the entry found == then mark the current entry as staled (active=0) == report an error in the log because something went wrong (especially if the Framed-IP-Address received is allocated to another NAS-IP/NAS-port entry in the pool) == do not allocate a new @IP * If there is No Framed-IP-Address attribute in the Request == then mark the current entry as staled (active=0) == allocate a new @IP What do you think ? Is it already done in current developpement tree ? Regards, Thibault Le Meur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE : IP Pool management and Re-authentication
Hi Alan, I'd like to patch the openvpn-radiusplugin so that an extra attribute is sent in the Access-Accept packets so that FR will be able to differentiate Initial and Renegociation Access-Accept requests and only assign new IP address from the pool on Initial Access-Accept requests. I think you mean Access-Request packet. Sorry for the mistake, I meant Access-Request of course If it doesn't have a Framed-IP-Address attribute, FreeRADIUS can allocate send one in an Access-Accept. If openvpn re-authenticates a session with an existing IP address, it should send Framed-IP-Address in the Access-Request. I get you right, my patch may be as easy as to make radiusplugin add the Framed-IP-Address attribute in the Access-Request packet with the already assigned IP Address when it is a renegotiation. I've patched the radiusplugin to add Framed-IP-Address to the re-auth request but rlm_ippool still allocates a new IP Address (I'm using FR 1.1.4). I can see this in radiusd -X: modcall: entering group postauth.ovpn for request 3 rlm_ippool: Searching for an entry for nas/port: 192.168.1.1/1 rlm_ippool: Found a stale entry for ip/port: 10.1.1.1/1 rlm_ippool: num: 0 rlm_ippool: Searching for an entry for nas/port: 192.168.1.1/1 rlm_ippool: Allocating ip to nas/port: 192.168.1.1/1 rlm_ippool: num: 1 rlm_ippool: Allocated ip 10.1.1.2 to client on nas 192.168.1.1,port 1 modcall[post-auth]: module Ovpn_Main_Pool returns ok for request 3 Where: * 192.168.1.1 is the NAS IP Address * 10.1.1.1 is the IP address allocated at connection time * 10.1.1.2 is the IP address allocated at re-authentication time Maybe I didn't understand you well: * Is rlm_ippool supposed to return NOOP if a Framed-IP-Address attribute is present in the Request ? OR * is it up to me to bypass the rlm_ippool (by setting another Post-Auth-Type) when a Re-Auth Request is performed (that is to say when a Framed-IP-Address attribute is present in the Request) ? Thanks in advance, Thibault - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: RE : IP Pool management and Re-authentication
Thibault Le Meur wrote: I've patched the radiusplugin to add Framed-IP-Address to the re-auth request but rlm_ippool still allocates a new IP Address (I'm using FR 1.1.4). Ok. It seems like rlm_ippool should be updated to look for Framed-IP-Address in the request. That would be very useful, and would solve the problem you're seeing. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE : RE : IP Pool management and Re-authentication
Thibault Le Meur wrote: I've patched the radiusplugin to add Framed-IP-Address to the re-auth request but rlm_ippool still allocates a new IP Address (I'm using FR 1.1.4). Ok. It seems like rlm_ippool should be updated to look for Framed-IP-Address in the request. That would be very useful, and would solve the problem you're seeing. Alan DeKok. Do you mean updated (to 1.1.5) or patched ? I made a quick diff between rlm_ippool.c from 1.1.4 and 1.1.5 and I can't see any difference so I think the problem I'm seeing is still present in 1.1.5. Regards, Thibault - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: RE : RE : IP Pool management and Re-authentication
I've been using OpenVPN + Ralf's Radiusplugin for several months and recently moved away from server-side IP assignment. However, while I did use it, I found that in my configuration FreeRADIUS only assigned new IPs when the accounting for that user had stopped (ie, if it recieved a STOP packet). This meant, that once I'd crashed the openvpn server 3 times with users on it :-) there were many IP's who were 'lost' - their sessions had never ended, hence the IP was never returned to the pool. I was doing renegotiation every 20 minutes if I remember correctly, and the freeradius replied with the same IP for the user time and time again. Hence, I'm beginning to wonder if it's configuration-specific, because I didn't have any problems. Hope this helps, Jan On 21/03/07, Thibault Le Meur [EMAIL PROTECTED] wrote: Thibault Le Meur wrote: I've patched the radiusplugin to add Framed-IP-Address to the re-auth request but rlm_ippool still allocates a new IP Address (I'm using FR 1.1.4). Ok. It seems like rlm_ippool should be updated to look for Framed-IP-Address in the request. That would be very useful, and would solve the problem you're seeing. Alan DeKok. Do you mean updated (to 1.1.5) or patched ? I made a quick diff between rlm_ippool.c from 1.1.4 and 1.1.5 and I can't see any difference so I think the problem I'm seeing is still present in 1.1.5. Regards, Thibault - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE : IP Pool management and Re-authentication
quote I've been using OpenVPN + Ralf's Radiusplugin for several months and recently moved away from server-side IP assignment. However, while I did use it, I found that in my configuration FreeRADIUS only assigned new IPs when the accounting for that user had stopped (ie, if it recieved a STOP packet). /quote Curious this is not what I see here ?? What is/was your FR server version ? Anyway, Alan said that a 'good nas' should send the Framed-IP-Address in the Access-Request if it has been already assigned one: this wasn't done by radiusplugin, thus I think I'll keep the pacth. quote This meant, that once I'd crashed the openvpn server 3 times with users on it :-) there were many IP's who were 'lost' - their sessions had never ended, hence the IP was never returned to the pool. /quote Sure, this is also true for my others NAS (pppd based), but they are quite robust (I hope openvpn is/will be as robust ;-)). quote I was doing renegotiation every 20 minutes if I remember correctly, and the freeradius replied with the same IP for the user time and time again. /quote Interesting, what could explain that mine allocate new IP addresses each time ? Should rlm_ippool allocate the same IP for a NAS-IP/NAS-port couple if the entry isn't cleaned from the pool ? (Anyway, I think it's better to have FR not re-send Framed-IP-Address since it would cause an unsuseful write to the client-config file from the radiusplugin.) quote Hence, I'm beginning to wonder if it's configuration-specific, because I didn't have any problems. /quote I can trust you, but I don't know where to search for a setup mistake. Does someone has an idea ? Thanks in advance, Thibault - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: IP Pool management and Re-authentication
Thibault Le Meur wrote: Openvpn sometimes needs to renegotiate the connections and thus sends authentication requests while the connection is still active (with an already assigned IP address): this causes FR to assign a new IP address from the pool (which seems normal since FR has no way to know this is a renegotiation). So why isn't the radiusplugin telling FreeRADIUS what the old IP address was? I'd like to patch the openvpn-radiusplugin so that an extra attribute is sent in the Access-Accept packets so that FR will be able to differentiate Initial and Renegociation Access-Accept requests and only assign new IP address from the pool on Initial Access-Accept requests. I think you mean Access-Request packet. If it doesn't have a Framed-IP-Address attribute, FreeRADIUS can allocate send one in an Access-Accept. If openvpn re-authenticates a session with an existing IP address, it should send Framed-IP-Address in the Access-Request. Do you know a standard Radius attribute that could be used for this ? As far as you know, are there other NASes using such a quirk ? Does this make sense ? It makes sense. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE : IP Pool management and Re-authentication
Thanks for your reply, Thibault Le Meur wrote: Openvpn sometimes needs to renegotiate the connections and thus sends authentication requests while the connection is still active (with an already assigned IP address): this causes FR to assign a new IP address from the pool (which seems normal since FR has no way to know this is a renegotiation). So why isn't the radiusplugin telling FreeRADIUS what the old IP address was? Because It's still beta ;-), I can fix this I'd like to patch the openvpn-radiusplugin so that an extra attribute is sent in the Access-Accept packets so that FR will be able to differentiate Initial and Renegociation Access-Accept requests and only assign new IP address from the pool on Initial Access-Accept requests. I think you mean Access-Request packet. Sorry for the mistake, I meant Access-Request of course If it doesn't have a Framed-IP-Address attribute, FreeRADIUS can allocate send one in an Access-Accept. If openvpn re-authenticates a session with an existing IP address, it should send Framed-IP-Address in the Access-Request. I get you right, my patch may be as easy as to make radiusplugin add the Framed-IP-Address attribute in the Access-Request packet with the already assigned IP Address when it is a renegotiation. Thanks a lot Alan. Regards, Thibault - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
