Posts Tagged ClearOS

Enable OpenVPN Management Interface on ClearOS

The OpenVPN config file structure on ClearOS is non-standard (For example there is no server.conf), so I was unsure where to put the directive. However, as it turns out enabling the Management console is as simple as adding the following to /etc/openvpn/clients.conf:

management localhost 7505

The port is arbitrary: any unused port will do. Localhost restricts connections to the local machine, which is smart if you do not have a password to secure the connection.

To access the management interface using telenet, issue the following from the clearOS box:

telnet localhost 7505
#When the prompt comes up, issue a command such as "status"

, ,

No Comments

Wifi RADIUS authentication with LDAP on ClearOS 5.2

This guide will help you setup WPA Enterprise authentication using the RADIUS functionality built into ClearOS 5.2.

The tutorial on the ClearOS wiki page is a good starting point to get radius authenticating off of the LDAP user directory, however it stops short of setting up RADIUS encryption which is required when using WIFI.


Please ensure that you have ClearOS 5.2 installed and have completed the guide at

Throughout this guide, it is assumed that ClearOS can be accessed at http://localhost:81. If you are connecting from a remote machine, please updated your url accordingly.

Generating Certificates

Navigate to https://localhost:81/admin/certificates.php.
When initially setting up ClearOS a Certificate Authority should have been created by default. If this isn’t the case, checkout the ClearOS docs for more information.

We are going to be generating a Secure Server Certificate for use with the RADIUS server.
The default Certificate parameters should work, just be sure to include a proper email address in the email field.
After clicking generate, a new certificate should be visible, click view to review the contents of the certificate. Be sure to note the filename as we will be needing that in a moment. Mine is “/etc/ssl/usr-1-cert.pem”

Now that we have the certificates generated, we are going to softlink them into the radius certs folder and update the permissions so the daemon can read them.

cd /etc/raddb/certs
#softlink the generated certificate
ln -s /etc/ssl/usr-1-cert.pem usr-1-cert.pem
#softlink the generated private key
ln -s /etc/ssl/private/usr-1-key.pem usr-1-key.pem
#update the file ownership
chown nobody:radiusd usr-1-cert.pem usr-1-key.pem

RADIUS Configuration

Now that we have the certificates generated, its time to modify the RADIUS configuration files. Remember, the files should have already been modifed as per the wiki article.


In the eap.conf file we will be wanting to enable TLS (using our generated certs) and PEAP.
So un-comment out tls and fill in the corresponding information.

The private key file should be set to the key-file softlinked to the /etc/ssl/private directory. (No password is required)

private_key_file = ${raddbdir}/certs/usr-1-key.pem

The certificate file is the cert file softlinked to the /set/ssl/ directory

certificate_file = ${raddbdir}/certs/usr-1-cert.pem

The Trusted root CA list should be the CA certificate for our server

CA_file = /etc/ssl/ca-cert.pem

Additinally, be sure to un-comment the dh_file and the random_file.

tls {
 #       private_key_password = whatever
 #       private_key_file = ${raddbdir}/certs/cert-srv.pem
 private_key_file = ${raddbdir}/certs/usr-1-key.pem
 #  If Private key & Certificate are located in
 #  the same file, then private_key_file &
 #  certificate_file must contain the same file
 #  name.
 #       certificate_file = ${raddbdir}/certs/cert-srv.pem
 certificate_file = ${raddbdir}/certs/usr-1-cert.pem
 #  Trusted Root CA list
 #       CA_file = ${raddbdir}/certs/demoCA/cacert.pem
 CA_file = /etc/ssl/ca-cert.pem
 dh_file = ${raddbdir}/certs/dh
 random_file = ${raddbdir}/certs/random
 #  This can never exceed the size of a RADIUS
 #  packet (4096 bytes), and is preferably half
 #  that, to accomodate other attributes in
 #  RADIUS packet.  On most APs the MAX packet
 #  length is configured between 1500 - 1600
 #  In these cases, fragment size should be
 #  1024 or less.
 #       fragment_size = 1024
 #  include_length is a flag which is
 #  by default set to yes If set to
 #  yes, Total Length of the message is
 #  included in EVERY packet we send.
 #  If set to no, Total Length of the
 #  message is included ONLY in the
 #  First packet of a fragment series.
 #       include_length = yes
 #  Check the Certificate Revocation List
 #  1) Copy CA certificates and CRLs to same directory.
 #  2) Execute 'c_rehash <CA certs&CRLs Directory>'.
 #    'c_rehash' is OpenSSL's command.
 #  3) Add 'CA_path=<CA certs&CRLs directory>'
 #      to radiusd.conf's tls section.
 #  4) uncomment the line below.
 #  5) Restart radiusd
 #       check_crl = yes
 #  If check_cert_issuer is set, the value will
 #  be checked against the DN of the issuer in
 #  the client certificate.  If the values do not
 #  match, the cerficate verification will fail,
 #  rejecting the user.
 #       check_cert_issuer = "/C=GB/ST=Berkshire/L=Newbury/O=My Company Ltd"
 #  If check_cert_cn is set, the value will
 #  be xlat'ed and checked against the CN
 #  in the client certificate.  If the values
 #  do not match, the certificate verification
 #  will fail rejecting the user.
 #  This check is done only if the previous
 #  "check_cert_issuer" is not set, or if
 #  the check succeeds.
 #       check_cert_cn = %{User-Name}
 # Set this option to specify the allowed
 # TLS cipher suites.  The format is listed
 # in "man 1 ciphers".
 #       cipher_list = "DEFAULT"

Setting up peap is easy: just uncomment the directives

peap {
 #  The tunneled EAP session needs a default
 #  EAP type which is separate from the one for
 #  the non-tunneled EAP module.  Inside of the
 #  PEAP tunnel, we recommend using MS-CHAPv2,
 #  as that is the default type supported by
 #  Windows clients.
 default_eap_type = mschapv2
 #  the PEAP module also has these configuration
 #  items, which are the same as for TTLS.
 copy_request_to_tunnel = no
 use_tunneled_reply = no
 #  When the tunneled session is proxied, the
 #  home server may not understand EAP-MSCHAP-V2.
 #  Set this entry to "no" to proxy the tunneled
 #  EAP-MSCHAP-V2 as normal MSCHAPv2.
 proxy_tunneled_request_as_eap = yes


This file needs an additional line added. Directly before the checkItem $GENERIC$ … line, add
checkItem    User-Password            userPassword

so the file now looks like:

checkItem    User-Password            userPassword
checkItem    $GENERIC$            radiusCheckItem
replyItem    $GENERIC$            radiusReplyItem
checkItem    Auth-Type            radiusAuthType
checkItem    Simultaneous-Use        radiusSimultaneousUse
checkItem    Called-Station-Id        radiusCalledStationId
checkItem    Calling-Station-Id        radiusCallingStationId
checkItem    LM-Password            sambaLMPassword
checkItem    NT-Password            sambaNTPassword
checkItem    SMB-Account-CTRL-TEXT        sambaAcctFlags
checkItem    Expiration            radiusExpiration
checkItem    NAS-IP-Address            radiusNASIpAddress
replyItem    Service-Type            radiusServiceType
replyItem    Framed-Protocol            radiusFramedProtocol
replyItem    Framed-IP-Address        radiusFramedIPAddress
replyItem    Framed-IP-Netmask        radiusFramedIPNetmask
replyItem    Framed-Route            radiusFramedRoute
replyItem    Framed-Routing            radiusFramedRouting
replyItem    Filter-Id            radiusFilterId
replyItem    Framed-MTU            radiusFramedMTU
replyItem    Framed-Compression        radiusFramedCompression
replyItem    Login-IP-Host            radiusLoginIPHost
replyItem    Login-Service            radiusLoginService
replyItem    Login-TCP-Port            radiusLoginTCPPort
replyItem    Callback-Number            radiusCallbackNumber
replyItem    Callback-Id            radiusCallbackId
replyItem    Framed-IPX-Network        radiusFramedIPXNetwork
replyItem    Class                radiusClass
replyItem    Session-Timeout            radiusSessionTimeout
replyItem    Idle-Timeout            radiusIdleTimeout
replyItem    Termination-Action        radiusTerminationAction
replyItem    Login-LAT-Service        radiusLoginLATService
replyItem    Login-LAT-Node            radiusLoginLATNode
replyItem    Login-LAT-Group            radiusLoginLATGroup
replyItem    Framed-AppleTalk-Link        radiusFramedAppleTalkLink
replyItem    Framed-AppleTalk-Network    radiusFramedAppleTalkNetwork
replyItem    Framed-AppleTalk-Zone        radiusFramedAppleTalkZone
replyItem    Port-Limit            radiusPortLimit
replyItem    Login-LAT-Port            radiusLoginLATPort
replyItem    Reply-Message            radiusReplyMessage


I found that in the default configuration, the Auth-Type LDAP appeared before the eap in the authenticate section. As a result, the server would cast the request as an LDAP auth type, and fail to parse it as an eap, which would cause the encrypted request from the WIFI access point to fail.
To fix this, I simply swapped the order of the two values, so if the server can’t match against any auth type, it will default to ldap, but most importantly, it will try EAP first.

So the authentication part of the file should look like the following:

authenticate {
 #  PAP authentication, when a back-end database listed
 #  in the 'authorize' section supplies a password.  The
 #  password can be clear-text, or encrypted.
 Auth-Type PAP {
 #  Most people want CHAP authentication
 #  A back-end database listed in the 'authorize' section
 #  MUST supply a CLEAR TEXT password.  Encrypted passwords
 #  won't work.
 Auth-Type CHAP {
 #  MSCHAP authentication.
 Auth-Type MS-CHAP {
 #  If you have a Cisco SIP server authenticating against
 #  FreeRADIUS, uncomment the following line, and the 'digest'
 #  line in the 'authorize' section.
#    digest
 #  Pluggable Authentication Modules.
#    pam
 #  See 'man getpwent' for information on how the 'unix'
 #  module checks the users password.  Note that packets
 #  containing CHAP-Password attributes CANNOT be authenticated
 #  against /etc/passwd!  See the FAQ for details.
 # Uncomment it if you want to use ldap for authentication
 # Note that this means "check plain-text password against
 # the ldap database", which means that EAP won't work,
 # as it does not supply a plain-text password.
 #Auth-Type LDAP {
 #    ldap
 #  Allow EAP authentication.
 Auth-Type LDAP {


Comment out the DEFAULT Auth-Type and fallthrough directive, so we aren’t always trying to default to ldap:

DEFAULT LDAP-Group != "radius_users", Auth-Type := Reject
#DEFAULT Auth-Type := LDAP
#      Fall-Through = 1

In Conclusion

You should run service radiusd stop && radiusd -X -A to do your testing with the debug log, as suggested on the ClearOS Wiki.
I found that the radtest still worked as well as authentication from wireless clients using PEAP with MSCHAPv2.
You may want to distribute the usr-1-cert.pem that was generated in the certificates step to wireless clients, however, since we are using password authentication this isnt strictly necessary.

Please let me know in the comments if I have included any redundant or unnecessary steps.

, , , , , ,

1 Comment