Now you can navigate to Status -> OpenVPN and it should state that the service is “up” 13. You can also check the connection log file under Status -> System Logs -> OpenVPN: That’s it! You should now have the VPN connection set on your pfSense.
Hi, I did a big refactoring of the code as you asked. Captiveportal now use a server from the user manager as source. Here are the main changes i did: • I updated the 6 functions dealing with RADIUS authentication in the captiveportal to make them use servers from server manager: radius() - need RADIUS auth portal_allow() - need RADIUS accounting start captiveportal_prune_old() - need RADIUS accounting start & stop, need RADIUS auth captiveportal_send_server_accounting() - need RADIUS accounting on & off captiveportal_disconnect() - need RADIUS accounting stop captiveportal_radius_stop_all() - need RADIUS() accounting stop All theses functions now rely on user manager servers. This is the most significant part of this Pull Request. • I added way to log in through an LDAP server from the user manager. I had to copy LDAP authentication code from auth.inc to captiveportal.inc, instead of just using the code of auth.inc.
Yeah, that's bad i know. The reason why i did this is the following problem: ldap_backed() and radius_backed() only return TRUE or FALSE, without returning the reason why ('could not contact server'?
Or 'invalid username/pasword'?). Captiveportal and some others services of pfSense (VPN, IPsec) need to know the reason why the auth didn't work, because they need to display an error message.
Maybe the functions inside auth.inc should be modified so that they return an array and not just a boolean? Mac address for internet wifi. Anyway, tell me if i'm wrong.but i believe that this should be done in another Pull Request, shouldn't it?
This PR is already pretty big. • I also updated the format of the SQLite database which contain users, since they was references on RADIUS servers inside it. I mention it here because this may break all existing captiveportals during update process.
• As you saw on the above picture, I have rewritten many help text, I changed the order of inputs etc.on the captiveportal configuration page. I also fixed few bugs: • When re-configuring a captiveportal, users went disconnected (because captiveportal's rules were flushed) but they was still considered as connected (because they was not removed from the SQLite database).
I fixed this by flushing the SQLite db, and added a warning. • I fixed a (very strange) parse error bug induced very long time ago by Only Regression: You cannot have a secondary RADIUS server as fallback anymore. Do you want me to add this feature back? I added way to log in through an LDAP server from the user manager. I had to copy LDAP authentication code from auth.inc to captiveportal.inc, instead of just using the code of auth.inc That isn't going to be viable. Alter the original functions and add a parameter at the end of their arguments to make them return a reason, such as $returnreason = false.
Then callers can be adjusted to set that parameter to true when they want to get back a reason or something similar. I also updated the format of the SQLite database which contain users, since they was references on RADIUS servers inside it. I mention it here because this may break all existing captiveportals during update process. We have had changes like that recently already and it should be OK, the databases get recreated at boot time, but if you are concerned then you will need to add upgrade code to remove the old databases on upgrade which will cause them to be created again no matter what. Only Regression: You cannot have a secondary RADIUS server as fallback anymore. Do you want me to add this feature back?