FreeRadius: PPTP - RADIUS and client IP address
-
Please send me diffs of the files to coreteam@pfsense.com and I will get the changes commited. Thanks for working on this.
-
I created the diff files and sent them to coreteam@pfsense.com. I built them using the following commands:
cd /usr/local/pkg
diff -rub freeradius.xml freeradius.xml.txt > freeradius.xml.diff
diff -rub freeradius.inc freeradius.inc.txt > freeradius.inc.diffcd /usr/local/www
diff -rub vpn_pptp.php vpn_pptp.php.txt > vpn_pptp.php.diffcd /etc/inc
diff -rub vpn.inc vpn.inc.txt > vpn.inc.diff -
As mentioned in a previous post I'm working on additional features to the PFSense Freeradius package. I wanted to add database support for multiple databases. The GUI is ready to go the config file is correctly edited for MySQL and then the snag… The FreeRadius package used does not have MySQL driver support compiled in.
Modifying a BSD Package is a bit beyond my current knowledge however I'm willing to learn if someone will point me in the right direction. Anyone want to add PostgreSQL, MySQL, and Oracle libraries to the BSD package that the PFSense FreeRadius add on uses?
One other option would be to use have the install pickup the FreeRadius Port and desired database client libraries and compile them during the install of the PFSense package. Is it okay to use Ports in the install of a Package? If so is there any PFSense Packages that install/compile a BSD port that can be used an example? I'm guessing it is just a matter of fetching the port remotely, extracting it and starting the compile?
Any recommendations, suggestions or help is appreciated.
-
Today I searched for how to create a package and found that it can be generated quite easily with a port.
http://www.onlamp.com/pub/a/bsd/2003/08/07/FreeBSD_Basics.htmlIn short you can navigate to /usr/ports directory and choose the specific port you want to use to create a package. Then run the following:
make packageThe easiest way to have access to /usr/ports seems to be the developers edition of PFSense.
Will be doing some testing soon to install the MySQL client libraries and then create the package. Hopefully the new FreeRadius package will then compile in the MySQL support. If successful I will experiment with other database vendors and finish up the new changes.
-
i applied the patches to HEAD and RELENG_1… should work, i hope...
cybrsrfr: please have a look at the timeline / cvs to crosscheck if it's correct...
-
I went through the CVS timeline as suggested and looked at each Check-in.
The changes look like they were updated successfully.Thanks for applying the patches!
-
As mentioned in a previous post I'm working on additional features to the PFSense Freeradius package. I wanted to add database support for multiple databases. The GUI is ready to go the config file is correctly edited for MySQL and then the snag… The FreeRadius package used does not have MySQL driver support compiled in.
Modifying a BSD Package is a bit beyond my current knowledge however I'm willing to learn if someone will point me in the right direction. Anyone want to add PostgreSQL, MySQL, and Oracle libraries to the BSD package that the PFSense FreeRadius add on uses?
One other option would be to use have the install pickup the FreeRadius Port and desired database client libraries and compile them during the install of the PFSense package. Is it okay to use Ports in the install of a Package? If so is there any PFSense Packages that install/compile a BSD port that can be used an example? I'm guessing it is just a matter of fetching the port remotely, extracting it and starting the compile?
I've covered quite a bit of this here, which I know you've already found.
Forget about Oracle; there's no support for Oracle in the FreeBSD net/freeradius port, and Oracle on FreeBSD is a little tricky because Oracle themselves don't officially support FreeBSD (so you have to use the Linux compatibility layer). I had someone on the freeradius-users list mention that he'd managed to kludge the port to work with Oracle on FreeBSD, and if he ever sends me a patch I'll see about adding it to the net/freeradius port, but I can't think the use of the Linux compatibility layer is going to make sense on a pfSense box. I haven't done this before because I don't have access to an Oracle server so I can't test it even if I can build it.
MySQL, PostgreSQL and OpenLDAP support are all there in the net/freeradius port - you just need to turn on the options and build the port. However, the resulting package will then depend on the ports (or packages - in FreeBSD, a package is just a pre-compiled port) containing the clients you enabled. As I've already mentioned, the latest version of the FreeRADIUS port won't build in the 6.2-RELEASE ports tree, and you're going to have to be careful about depending on the same versions of the packages you're adding dependencies on, to try to keep them the same versions as those needed by other pfSense packages. Of course, compiling in additional support also increases the disk footprint of the server.
The particular problem with dependencies is with shared version library bumps - there's no easy way to cope with the situation of having packages installed that need different versions of the same shared library. If you look at the FreshPorts FreeRADIUS page, you will see some shared library version bumps mentioned in the commit logs - there are some for Heimdal near the top. When the shared library version has changed (bumped in the jargon) there has been an incompatible change in the library and all code that uses that library should really be recompiled against the new version.
Unfortunately, there are hidden shared library version bumps too, as MySQL, PostgreSQL and Firebird are all handled by /usr/ports/Mk/bsd.database.mk and OpenLDAP is handled by /usr/ports/Mk/bsd.port.mk rather than in the various ports that use these clients. Fortunately there are few, if any, shared library version bumps along a particular minor version - though it does happen. From its introduction into the ports tree, the MySQL 5.1 library had a shared library version number of 15 (which is the same as current versions of MySQL 5.0), but this changed to 16 from 5.1.21 onwards. (See the FreeBSD CVSweb page for bsd.database.mk - it happened in the commit that brings the file to version 1.21). I have seen mention elsewhere in the forums of people creating a symlink from libmysqlclient.so.16 to libmysqlclient.so.15 in /usr/local/lib/mysql when they have code that needs the version 15 library and a recent MySQL 5.1 client installed. This may work, but really can't be recommended as it could lead to strange and unexpected brokenness. There's a reason that the version number of the library was changed, though I'd have to investigate to find out the specifics of this case.
You can create an environment in which you have multiple versions of a shared library available, but you can't just install the MySQL 5.0 and 5.1 clients at the same time as they conflict. Whilst there are some improvements in MySQL 5.1 (which is tantalisingly close to formal release, but has been stuck at Release Candidate stage since September 2007), they're not huge changes over 5.0 for most users, and I'm comfortable sticking with 5.0 for now. Some software (such as phpMyAdmin) doesn't officially support MySQL 5.1 yet. Whilst using mismatched clients and servers can cause problems, a 5.0 client may well work properly against a 5.1 server for fairly simple tasks.
As you can probably tell, I'm much more familiar with MySQL than other database systems such as PostgreSQL.
The easiest way to avoid problems is for everyone to agree on what versions of the various clients and other dependencies to use in all pfSense packages. The easiest thing is to stick with the defaults for the FreeBSD version that the pfSense version is based on. For 1.2 that means 6.2-RELEASE, which means MySQL 5.0, PostgreSQL 7.4 (rather conservative, I'm afraid), Firebird 2 and OpenLDAP 2.3. The easiest way to find the defaults if you're not familiar with the FreeBSD ports CVS layout is to look in the appropriate packages directory on the FreeBSD FTP servers.
Of course, it's not for me to rule on what should and shouldn't be done - I just wanted you to be aware of the potential pitfalls in making FreeRADIUS depend on the various clients.
Meanwhile, as I've mentioned in the other thread, I have concerns about having a FreeRADIUS that is using SQL databases or LDAP directories on a firewall. Some of this information is potentially quite sensitive. I certainly wouldn't want to be running a SQL or LDAP server on a firewall, and if you have those services running elsewhere on the network, why not put your FreeRADIUS server on that machine instead?
I see the main use of FreeRADIUS running on pfSense itself as providing relatively straightforward authentication (based on a file) for services such as VPN servers running on pfSense. I can also see a place for providing EAP-PEAPv0-MSCHAP service for WPA[2]-Enterprise, authenticating off a file. However, I appreciate that everyone's requirements are different.
All I'm suggesting is caution - because of the possibility of creating conflicts with other pfSense packages, also the possibility that people are encouraged to create sophisticated RADIUS servers on pfSense that might be better hosted inside the firewall rather than on the firewall machine from a security point of view.
It is possible (in the abstract) to have RADIUS authentication running on one RADIUS server and RADIUS accounting running on another. This can be useful if you want a simple RADIUS server running on pfSense to authenticate VPN users (so that they can get access to the local network to fix a problem with other servers), but you want accounting data stored in an SQL database (which can be done via a RADIUS server inside the firewall, where it's more secure).
Splitting authentication and accounting when accounting is to an SQL database can also be preferable from a robustness point of view - if FreeRADIUS 1.x hits problems with an SQL database, it can stop handling other traffic - hence the recommendation to proxy accounting data to a second FreeRADIUS instance that handles the SQL side of things. In FreeRADIUS 2.x, virtual servers can come to your aid here.
Finally, you asked somewhere about supporting SQLite in FreeRADIUS. Unless I'm very much mistaken, there's no support for SQLite in FreeRADIUS itself, so this is far from trivial! I'm certainly not going to do it.
I apologise that this is a bit of a 'brain dump', but I hope it's helpful in guiding your work. This really feels like it should be a new thread somewhere - maybe an admin can rearrange the various bits of the two threads this is split over.
David
-
Hi,
Please also refer to this post:
http://forum.pfsense.org/index.php/topic,8956.0.html
(Sorry for the cross-posting but the subjects are related)
I have upgraded to psfsense 1.2-RELEASE and was looking for the "RADIUS issued IP's" configuration for PPTP server. However, this seems to be missing.
Please advise on what is required to enable "RADIUS issued IP's" or just how to get RADUIS allocated IPs working. The RADUIS Users GUI includes a field to specify the IP address. However, without the "RADIUS issued IP's" option enabled it does not seem to work.
Regards,
Mon
-
BUMP!
-
BUMP
-
B.U.M.P.
Please can somebody advise on how to enable "RADUIS Issued IP's" for PPTP.
-
:'( Oh, come on! Somebody must be able to help?
-
B.U.M.P
Please can somebody in the know give a status update on this issue. When can we expect this issue to be resolved?
Regards,
Mon