Anyone got a working sites-available/tls file for FR 4.0- ?
Once I wrapped the supplied example in "server tls {....} " Get a "Failed to find clients radsec {..} message" even though the config is there. A
On Dec 2, 2016, at 8:04 AM, Alex Sharaz <alex.sharaz@york.ac.uk> wrote:
Once I wrapped the supplied example in "server tls {....} "
Why would you do that?
Get a "Failed to find clients radsec {..} message" even though the config is there.
The example works as-is. You don't need to wrap it in a "server tls" section. Alan DeKok.
So it does thx A On 2 December 2016 at 13:47, Alan DeKok <aland@deployingradius.com> wrote:
On Dec 2, 2016, at 8:04 AM, Alex Sharaz <alex.sharaz@york.ac.uk> wrote:
Once I wrapped the supplied example in "server tls {....} "
Why would you do that?
Get a "Failed to find clients radsec {..} message" even though the config is there.
The example works as-is. You don't need to wrap it in a "server tls" section.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
Spoke too soon Unpacked and built FR 4.0 from git symbolic linked tls, default,.buffered-sql and inner-tunnel from sites-available to sites-enabled ran /usr/local/sbin/radiusd -d /etc/freeradius -X -l /var/log/freeradius/radius.log > /var/log/freeradius/radius.log and got Error : /etc/freeradius/sites-enabled/tls[7]: Listeners of type 'auth+acct' MUST be defined in a server. Edited tls to add server tls {....} and got Dec 2 16:20:56 2016 : Debug : cipher_list = "DEFAULT" Fri Dec 2 16:20:56 2016 : Debug : cipher_server_preference = yes Fri Dec 2 16:20:56 2016 : Debug : allow_renegotiation = no Fri Dec 2 16:20:56 2016 : Debug : require_client_cert = yes Fri Dec 2 16:20:56 2016 : Debug : ecdh_curve = "prime256v1" Fri Dec 2 16:20:56 2016 : Debug : cache { Fri Dec 2 16:20:56 2016 : Debug : lifetime = 24 Fri Dec 2 16:20:56 2016 : Debug : verify = no Fri Dec 2 16:20:56 2016 : Error : /etc/freeradius/sites-enabled/tls[253]: Configuration pair "enable" is deprecated commented out #enable = no ran again Fri Dec 2 16:21:51 2016 : Debug : auto_chain = yes Fri Dec 2 16:21:51 2016 : Debug : check_crl = no Fri Dec 2 16:21:51 2016 : Debug : cipher_list = "DEFAULT" Fri Dec 2 16:21:51 2016 : Debug : cipher_server_preference = yes Fri Dec 2 16:21:51 2016 : Debug : allow_renegotiation = no Fri Dec 2 16:21:51 2016 : Debug : require_client_cert = yes Fri Dec 2 16:21:51 2016 : Debug : ecdh_curve = "prime256v1" Fri Dec 2 16:21:51 2016 : Debug : cache { Fri Dec 2 16:21:51 2016 : Debug : lifetime = 24 Fri Dec 2 16:21:51 2016 : Debug : verify = no Fri Dec 2 16:21:51 2016 : Error : /etc/freeradius/sites-enabled/tls[269]: Configuration pair "max_entries" is deprecated commented out # # The maximum number of entries in the # cache. Set to "0" for "infinite". # # This could be set to the number of users # who are logged in... which can be a LOT. # #max_entries = 255 and got Fri Dec 2 16:22:46 2016 : Debug : staple { Fri Dec 2 16:22:46 2016 : Debug : enable = no Fri Dec 2 16:22:46 2016 : Debug : override_cert_url = no Fri Dec 2 16:22:46 2016 : Debug : use_nonce = yes Fri Dec 2 16:22:46 2016 : Debug : timeout = 0 Fri Dec 2 16:22:46 2016 : Debug : softfail = no Fri Dec 2 16:22:46 2016 : Debug : } Fri Dec 2 16:22:46 2016 : Debug : } Fri Dec 2 16:22:46 2016 : Debug : limit { Fri Dec 2 16:22:46 2016 : Debug : max_connections = 16 Fri Dec 2 16:22:46 2016 : Debug : lifetime = 0 Fri Dec 2 16:22:46 2016 : Debug : idle_timeout = 30 Fri Dec 2 16:22:46 2016 : Debug : } Fri Dec 2 16:22:46 2016 : Debug : clients = "radsec" Fri Dec 2 16:22:46 2016 : Error : /etc/freeradius/sites-enabled/tls[8]: Failed to find clients radsec {...} but further down in tls we have listen { ipaddr = * port = 2083 # # TCP and TLS sockets can accept Access-Request and # Accounting-Request on the same socket. # # auth = only Access-Request # acct = only Accounting-Request # auth+acct = both # type = auth+acct # For now, only TCP transport is allowed. proto = tcp # Send packets to the default virtual server virtual_server = default clients = radsec # # Connection limiting for sockets with "proto = tcp". # limit { limit { # # Limit the number of simultaneous TCP connections to the socket # # The default is 16. # Setting this to 0 means "no limit" max_connections = 16 # The per-socket "max_requests" option does not exist. # # The lifetime, in seconds, of a TCP connection. After # this lifetime, the connection will be closed. # # Setting this to 0 means "forever". lifetime = 0 # # The idle timeout, in seconds, of a TCP connection. # If no packets have been received over the connection for # this time, the connection will be closed. # # Setting this to 0 means "no timeout". # # We STRONGLY RECOMMEND that you set an idle timeout. # idle_timeout = 30 } # This is *exactly* the same configuration as used by the EAP-TLS # module. It's OK for testing, but for production use it's a good # idea to use different server certificates for EAP and for RADIUS # transport. # # If you want only one TLS configuration for multiple sockets, # then we suggest putting "tls { ...}" into radiusd.conf. # The subsection below can then be changed into a reference: # # tls = ${tls} # # Which means "the tls sub-section is not here, but instead is in # the top-level section called 'tls'". # # If you have multiple tls configurations, you can put them into # sub-sections of a top-level "tls" section. There's no need to # call them all "tls". You can then use: # # tls = ${tls.site1} # # to refer to the "site1" sub-section of the "tls" section. # tls { private_key_password = whatever private_key_file = ${certdir}/server.pem # If Private key & Certificate are located in # the same file, then private_key_file & # certificate_file must contain the same file # name. # # If ca_file (below) is not used, then the # certificate_file below MUST include not # only the server certificate, but ALSO all ..... # in the directory when the server starts. # tmpdir = /tmp/radiusd # The command used to verify the client cert. # We recommend using the OpenSSL command-line # tool. # # The ${..ca_path} text is a reference to # the ca_path variable defined above. # # The %{TLS-Client-Cert-Filename} is the name # of the temporary file containing the cert # in PEM format. This file is automatically # deleted by the server when the command # returns. # client = "/path/to/openssl verify -CApath ${..ca_path} %{TLS-Client-Cert-Filename}" } } } clients radsec { client 127.0.0.1 { ipaddr = 127.0.0.1 # # Ensure that this client is TLS *only*. # proto = tls ....... # # TCP clients can have any shared secret. # # TLS clients MUST have the shared secret # set to "radsec". Or, for "proto = tls", # you can omit the secret, and it will # automatically be set to "radsec". # secret = radsec # # You can also use a "limit" section here. # See raddb/clients.conf for examples. # # Note that BOTH limits are applied. You # should therefore set the "listen" limits # higher than the ones for each individual # client. # } } home_server tls { ipaddr = 127.0.0.1 port = 2083 ..... I know you said I didn't need the server blockbut without it can't even get as far as I did with the standard raddb configs A On 2 December 2016 at 13:52, Alex Sharaz <alex.sharaz@york.ac.uk> wrote:
So it does thx A
On 2 December 2016 at 13:47, Alan DeKok <aland@deployingradius.com> wrote:
On Dec 2, 2016, at 8:04 AM, Alex Sharaz <alex.sharaz@york.ac.uk> wrote:
Once I wrapped the supplied example in "server tls {....} "
Why would you do that?
Get a "Failed to find clients radsec {..} message" even though the config is there.
The example works as-is. You don't need to wrap it in a "server tls" section.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list /users.html
On Dec 2, 2016, at 11:31 AM, Alex Sharaz <alex.sharaz@york.ac.uk> wrote:
Spoke too soon
Unpacked and built FR 4.0 from git
We're in the process re-working 4.0. So I'm hesitant to look at any issues with it.
Error : /etc/freeradius/sites-enabled/tls[7]: Listeners of type 'auth+acct' MUST be defined in a server.
That can be fixed, I guess.
Edited tls to add server tls {....}\
Please don't. I've already said that's wrong. If the error message says that the "listen" section belongs in a "server" block... then put the "listen" section into a "server" block. Don't put the entire "tls" file into a "server" block.
Fri Dec 2 16:22:46 2016 : Error : /etc/freeradius/sites-enabled/tls[8]: Failed to find clients radsec {...}\
See the other example virtual servers for how to set a "clients" section. You can't put a "clients" section into a virtual server like that.
I know you said I didn't need the server blockbut without it can't even get as far as I did with the standard raddb configs
Honestly, all of this will change in a few months as we re-do version 4. There is just no reason for anyone to run v4 until January or so. Alan DeKok.
o.k thanks. putting the server round just the listen section worked .... .it brought up other errors elsewhere but got rid of this one. This is just a playtoy server, am running 3.0.12 in production A On 2 December 2016 at 16:56, Alan DeKok <aland@deployingradius.com> wrote:
On Dec 2, 2016, at 11:31 AM, Alex Sharaz <alex.sharaz@york.ac.uk> wrote:
Spoke too soon
Unpacked and built FR 4.0 from git
We're in the process re-working 4.0. So I'm hesitant to look at any issues with it.
Error : /etc/freeradius/sites-enabled/tls[7]: Listeners of type 'auth+acct' MUST be defined in a server.
That can be fixed, I guess.
Edited tls to add server tls {....}\
Please don't. I've already said that's wrong.
If the error message says that the "listen" section belongs in a "server" block... then put the "listen" section into a "server" block. Don't put the entire "tls" file into a "server" block.
Fri Dec 2 16:22:46 2016 : Error : /etc/freeradius/sites-enabled/tls[8]: Failed to find clients radsec {...}\
See the other example virtual servers for how to set a "clients" section.
You can't put a "clients" section into a virtual server like that.
I know you said I didn't need the server blockbut without it can't even get as far as I did with the standard raddb configs
Honestly, all of this will change in a few months as we re-do version 4. There is just no reason for anyone to run v4 until January or so.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
Hi,
o.k thanks. putting the server round just the listen section worked .... .it brought up other errors elsewhere but got rid of this one. This is just a playtoy server, am running 3.0.12 in production
'playtoy' 3.1.x - that gives you all the TLS/RADSEC stuff, REDIS cache, EAP caches and the like. 4 HEAD will give you naught but grief and pain...promises and heartbreak..and soon a very very borked server as huge swathes of config have to be modified and rewritten/worded - as Alan says, dont use 4.x yet ;-) alan
:/))))) Just about to switch to 3.1 A Sent from my iPhone 6 plus
On 2 Dec 2016, at 20:01, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
o.k thanks. putting the server round just the listen section worked .... .it brought up other errors elsewhere but got rid of this one. This is just a playtoy server, am running 3.0.12 in production
'playtoy' 3.1.x - that gives you all the TLS/RADSEC stuff, REDIS cache, EAP caches and the like.
4 HEAD will give you naught but grief and pain...promises and heartbreak..and soon a very very borked server as huge swathes of config have to be modified and rewritten/worded - as Alan says, dont use 4.x yet ;-)
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
And loook at that! Wrapped the tls "listen" statement with a "server tls { }" and it all seems to have worked .... well there's something listening on the right ports perhaps I will ignore 4.0 for a while A On 2 December 2016 at 22:41, Alex Sharaz <alex.sharaz@york.ac.uk> wrote:
:/))))) Just about to switch to 3.1 A
Sent from my iPhone 6 plus
On 2 Dec 2016, at 20:01, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
o.k thanks. putting the server round just the listen section worked .... .it brought up other errors elsewhere but got rid of this one. This is just a playtoy server, am running 3.0.12 in production
'playtoy' 3.1.x - that gives you all the TLS/RADSEC stuff, REDIS cache, EAP caches and the like.
4 HEAD will give you naught but grief and pain...promises and heartbreak..and soon a very very borked server as huge swathes of config have to be modified and rewritten/worded - as Alan says, dont use 4.x yet ;-)
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
On 2 Dec 2016, at 18:18, Alex Sharaz <alex.sharaz@york.ac.uk> wrote:
And loook at that!
Wrapped the tls "listen" statement with a "server tls { }" and it all seems to have worked .... well there's something listening on the right ports perhaps I will ignore 4.0 for a while
The secret flags which actually enable the new state machines in v4.0.x are not public. If you use 4.0.x you'll see an ever shrinking pool of modules which actually work with the old state machines, and no real benefit. For example the radius client module, rlm_rest and rlm_delay simply won't work anymore unless you switch to the new state machine. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
participants (4)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Alex Sharaz -
Arran Cudbard-Bell