|
|
On Sat, Dec 31, 2005 at 03:46:59PM +0100, Ralf Lübben wrote: > Am Freitag, 30. Dezember 2005 17:10 schrieben Sie: > > > For a new plugin version, it would be an better idea, that the plugin > > > gets the information about the topology by reading from the openvpn > > > config file or by the enviroment variable from openvpn which are passed > > > to the plugin. > > > > Yes, I think this would work... I may try to hack something similar in to > > the plugin and will send you patches if I figure it out (I'm sure you're > > busy). > If you can wait about one week, I can make the changes. > Else: > The changes are: > 1. > Class: > RadiusConfig > Changes: > - two new variables (subnet, p2p) with getters and setters > - two new configurations points in method parse config > - add the new variables in constructors/destructor > 2. > Class: > UserAuth > Changes: > add the right value based on the topology option in function createCcdFile Fantastic. I'll probably try and work on the Framed-IP issue below first. If you get to this that would be great. > > > to 3.) > > > Well, the reason I brought this up is that our Radius server (in its > > current configuration) does not hand out a Framed-IP-Address variable to > > every connecting client. Only to those clients (customers) who have > > requested a specific IP address (static IP). So, for the vast majority of > > clients, no Framed-IP-Address is assigned by the Radius server. In this > > case, OpenVPN properly assigns an IP from its pool, but when the Radius > > plugin sends its Accounting-Start packet to the Radius server for this > > connection, the Framed-IP-Address entry is blank or invalid. > > > > So when I look at my online client list on my Radius server, I can see the > > client connected, but its Framed-IP-Address is empty. > > > > So, I would like to implement the following behavior: > > > > 1. Client connects. > > 2. Radius authentication occurs. > > 3. Radius server has no Framed-IP-Address variable to return to server. > > 4. OpenVPN server assigns IP from its pool. > > 5. Radius plugin sees that no Framed-IP-Address is available from Radius > > server and uses instead the IP assigned by OpenVPN > > 6. Radius plugin crafts Accounting-Start packet using the OpenVPN-assigned > > IP address in the Framed-IP-Address field. > > > > Let me know if that makes sense. I will also try and get this into the > > code. I don't know how the "flow" of things works however. Maybe the > > Radius plugin has no idea what IP OpenVPN has assigned when it sends the > > Accounting-Start packet? > > I think now I understand your problem. The plugin send the Framed-IP-Address > attribute in accounting packets, also the radius server doesn't send it to > the plugin on authentication. > I think there are two posibilities: > 1. > If the radius server doesn't send the attribute, the attribute is not add in > the accounting packets. > 2. > The plugin gets the ip from the OpenVPN-Server and sends this IP in the > accounting packets. (I think it is possible to get the assigned ip from > OpenVPN.) > > I would prefer the first version, because the meaning of the attribute is, > that the radius server assigned the ip to the client. > > I don't know how other systems like BRAS or PPTP/PPP behave, if they assign > ips to the client. Do they send the ip as Framed Ip Address attribute back to > the radius server? I guess I'd have to look at the RADIUS RFC to confirm the meaning of the Attribute. I suspect you are correct, but PPTP/PPP on Linux both send the Framed-IP-Address attribute back to the Radius accounting server regardless of whether or not it was received in an Access-Accept packet from the Radius authentication server. This is the behavior I'd *like* to see. If it's not RFC-compliant, I'm willing to go with option 1 though and re-design our system (currently tailored for PPTP/PPPD) accordingly. Thanks, Ray ____________________________________________ Openvpn-users mailing list Openvpn-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/openvpn-users |