Hi List, Sorry if it's a stupid question but since Freeradius 3.0.4 ( Version 3.0.4 (git #9b5c955) ), my custom virtual server is ignored by freeradius at startup Log: rlm_sql (sql): Executing query: 'SELECT id, nasname, shortname, type, secret, server FROM nas' rlm_sql (sql): Adding client 192.168.0.1 (AP01) to rif clients list Failed to find virtual server rif Failed to add client, possible duplicate? rlm_sql (sql): Adding client 192.168.0.2 (AP02) to rif clients list Failed to find virtual server rif Failed to add client, possible duplicate? rlm_sql (sql): Adding client 192.168.0.3 (AP03) to rif clients list Failed to find virtual server rif Failed to add client, possible duplicate? rlm_sql (sql): Adding client 192.168.0.4 (AP04) to rif clients list Failed to find virtual server rif Failed to add client, possible duplicate? rlm_sql (sql): Adding client 192.168.0.5 (AP05) to rif clients list Failed to find virtual server rif Failed to add client, possible duplicate? rlm_sql (sql): Adding client 192.168.0.6 (AP06) to rif clients list Thanks.
On Mon, Sep 8, 2014 at 2:30 PM, <nicolas.clo@ricoh-industrie.fr> wrote:
Hi List,
Sorry if it's a stupid question but since Freeradius 3.0.4 ( Version 3.0.4 (git #9b5c955) ), my custom virtual server is ignored by freeradius at startup
Log:
rlm_sql (sql): Executing query: 'SELECT id, nasname, shortname, type, secret, server FROM nas' rlm_sql (sql): Adding client 192.168.0.1 (AP01) to rif clients list *Failed to find virtual server rif*
The usual response would be "what does the debug log show"? It should print which config files it reads, and also what virtual servers it finds. Also, what version did you test that it worked the last time? -- Fajar
I was just about to post to the list about the same issue!
Failed to find virtual server rif
I’m getting the same issue using the latest v2.x.x branch from Github with Alan’s fix for the loading clients into virtual servers from SQL issue. (Possible connection? I think the fix was also pulled into the v3.0.4 branch too…) rlm_sql (sql): Processing generate_sql_clients rlm_sql (sql) in generate_sql_clients: query is SELECT id, nasname, shortname, type, secret, server FROM nas rlm_sql (sql): Reserving sql socket id: 4 rlm_sql_mysql: query: SELECT id, nasname, shortname, type, secret, server FROM nas rlm_sql (sql): Read entry nasname=128.0.0.0/1,shortname=upper,secret=testing1 rlm_sql (sql): Adding client 128.0.0.0 (upper, server=vs3001) to clients list Failed to find virtual server vs3001 rlm_sql (sql): Released sql socket id: 4 rlm_sql (sql): Failed to add client 128.0.0.0 (upper) to clients list. Maybe there's a duplicate? Failed to load clients from SQL. I also tried two static defined clients same name and IP pointing to different virtual servers and got: Sun Sep 7 02:41:06 2014 : Debug: radiusd: #### Loading Realms and Home Servers #### Sun Sep 7 02:41:06 2014 : Debug: radiusd: #### Loading Clients #### Sun Sep 7 02:41:06 2014 : Debug: client 1.1.1.1 { Sun Sep 7 02:41:06 2014 : Debug: ipaddr = 1.1.1.1 Sun Sep 7 02:41:06 2014 : Debug: require_message_authenticator = no Sun Sep 7 02:41:06 2014 : Debug: secret = "testing1" Sun Sep 7 02:41:06 2014 : Debug: virtual_server = "vs3001" Sun Sep 7 02:41:06 2014 : Debug: } Sun Sep 7 02:41:06 2014 : Debug: client 1.1.1.1 { Sun Sep 7 02:41:06 2014 : Debug: ipaddr = 1.1.1.1 Sun Sep 7 02:41:06 2014 : Debug: require_message_authenticator = no Sun Sep 7 02:41:06 2014 : Debug: secret = "testing2" Sun Sep 7 02:41:06 2014 : Debug: virtual_server = "vs3002" Sun Sep 7 02:41:06 2014 : Debug: } Sun Sep 7 02:41:06 2014 : Error: Failed to add duplicate client 1.1.1.1 Sun Sep 7 02:41:06 2014 : Error: /etc/freeradius/radiusd.conf[216]: Failed to add client 1.1.1.1 Sun Sep 7 02:41:06 2014 : Debug: Failed to load clients It’s as if its loading the clients before the virtual servers and therefore has no knowledge of them. I then tried putting the statically defined clients inside each of the virtual server blocks and this loads fine: } # server server vs3001 { # from file /etc/freeradius/radiusd.conf modules { Module: Checking authenticate {...} for more modules to load Module: Checking authorize {...} for more modules to load } # modules } # server server vs3002 { # from file /etc/freeradius/radiusd.conf modules { Module: Checking authenticate {...} for more modules to load Module: Checking authorize {...} for more modules to load } # modules } # server radiusd: #### Opening IP addresses and Ports #### listen { type = "control" listen { socket = "/var/run/freeradius/freeradius.sock" mode = "rw" } } listen { type = "auth" ipaddr = * port = 3001 client dynamic_all_3001 { ipaddr = 0.0.0.0 netmask = 0 require_message_authenticator = no dynamic_clients = "dynamic_client_server" lifetime = 3600 } client 1.1.1.1 { ipaddr = 1.1.1.1 require_message_authenticator = no secret = "testing1" } } listen { type = "auth" ipaddr = * port = 3002 client dynamic_all_3002 { ipaddr = 0.0.0.0 netmask = 0 require_message_authenticator = no dynamic_clients = "dynamic_client_server" lifetime = 3600 } client 1.1.1.1 { ipaddr = 1.1.1.1 require_message_authenticator = no secret = "testing2" } } Listening on command file /var/run/freeradius/freeradius.sock Listening on authentication address * port 3001 as server vs3001 Listening on authentication address * port 3002 as server vs3002 Ready to process requests. Hope this helps, Cheers Kev/.
Kev Pearce wrote:
I’m getting the same issue using the latest v2.x.x branch from Github with Alan’s fix for the loading clients into virtual servers from SQL issue. (Possible connection? I think the fix was also pulled into the v3.0.4 branch too…)
Yes. There are a few issues here. In reality, clients belong to "listen" sections, not to virtual servers. That's how RADIUS works. Which means that the configuration of the server is misleading. i.e. let's say you have two virtual servers defined. You want each virtual server to have a client which uses the same IP, but different secrets. This won't work. Ever. You MUST define two "listen" sections, one for each virtual server. You can then tie a client to each "listen" section, and it will work. Putting clients into SQL will work when: a) you have UNIQUE client IPs, and a global "listen" section. OR b) each virtual server has it's own "listen" section. If people could confirm what they're doing, that would help. Alan DeKok.
Virtual server "rif" is loaded. See below: including files in directory /etc/freeradius/policy.d/ including configuration file /etc/freeradius/policy.d/update_lastconnexion including configuration file /etc/freeradius/policy.d/split_domain_host including configuration file /etc/freeradius/policy.d/control including configuration file /etc/freeradius/policy.d/vlan including configuration file /etc/freeradius/policy.d/bad_username including configuration file /etc/freeradius/policy.d/dhcp including configuration file /etc/freeradius/policy.d/check_mac including configuration file /etc/freeradius/policy.d/ssid including configuration file /etc/freeradius/policy.d/check_last_connexion including configuration file /etc/freeradius/policy.d/debug including configuration file /etc/freeradius/policy.d/operator-name including configuration file /etc/freeradius/policy.d/canonicalization including configuration file /etc/freeradius/policy.d/log_eap_error including configuration file /etc/freeradius/policy.d/filter including configuration file /etc/freeradius/policy.d/cui OPTIMIZING no yes --> FALSE OPTIMIZING no yes --> FALSE including configuration file /etc/freeradius/policy.d/accounting including configuration file /etc/freeradius/policy.d/check_host_mac including configuration file /etc/freeradius/policy.d/eap including files in directory /etc/freeradius/sites-enabled/ including configuration file /etc/freeradius/sites-enabled/default including configuration file /etc/freeradius/sites-enabled/rif including configuration file /etc/freeradius/sites-enabled/status including configuration file /etc/freeradius/sites-enabled/inner-tunnel All logs is too big to send (sorry) Thanks. On Mon, Sep 8, 2014 at 2:30 PM, <nicolas.clo@ricoh-industrie.fr> wrote: Hi List, Sorry if it's a stupid question but since Freeradius 3.0.4 ( Version 3.0.4 (git #9b5c955) ), my custom virtual server is ignored by freeradius at startup Log: rlm_sql (sql): Executing query: 'SELECT id, nasname, shortname, type, secret, server FROM nas' rlm_sql (sql): Adding client 192.168.0.1 (AP01) to rif clients list Failed to find virtual server rif The usual response would be "what does the debug log show"? It should print which config files it reads, and also what virtual servers it finds. Also, what version did you test that it worked the last time? -- Fajar- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
If I put nas clients in clients.conf file, everything works fine. On Mon, Sep 8, 2014 at 2:30 PM, <nicolas.clo@ricoh-industrie.fr> wrote: Hi List, Sorry if it's a stupid question but since Freeradius 3.0.4 ( Version 3.0.4 (git #9b5c955) ), my custom virtual server is ignored by freeradius at startup Log: rlm_sql (sql): Executing query: 'SELECT id, nasname, shortname, type, secret, server FROM nas' rlm_sql (sql): Adding client 192.168.0.1 (AP01) to rif clients list Failed to find virtual server rif The usual response would be "what does the debug log show"? It should print which config files it reads, and also what virtual servers it finds. Also, what version did you test that it worked the last time? -- Fajar- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
nicolas.clo@ricoh-industrie.fr wrote:
Sorry if it's a stupid question but since Freeradius 3.0.4 ( Version 3.0.4 (git #9b5c955) ), my custom virtual server is ignored by freeradius at startup
...
rlm_sql (sql): Executing query: 'SELECT id, nasname, shortname, type, secret, server FROM nas' rlm_sql (sql): Adding client 192.168.0.1 (AP01) to rif clients list *Failed to find virtual server rif*
I've pushed a fix. Alan DeKok.
Ok thanks Alan, it works. But just last question, now if I have same entry in clients.conf than nas mysql table (with mod-enabled - sql --> read_clients = yes) , at Freeradius startup, it tell me that duplicate rows exists but just for global section and not for rif section. Is it normal ? rlm_sql (sql): Adding client 192.168.48.73 (SERVER) to global clients list Failed to add duplicate client SERVER Failed to add client, possible duplicate? rlm_sql (sql): Adding client 192.168.50.182 (TEST) to rif clients list rlm_sql (192.168.50.182): Client "TEST" (sql) added rlm_sql (sql): Adding client 192.168.50.186 (AP03) to rif clients list rlm_sql (192.168.50.186): Client "AP03" (sql) added rlm_sql (sql): Released connection (4) nicolas.clo@ricoh-industrie.fr wrote:
Sorry if it's a stupid question but since Freeradius 3.0.4 ( Version 3.0.4 (git #9b5c955) ), my custom virtual server is ignored by freeradius at startup
...
rlm_sql (sql): Executing query: 'SELECT id, nasname, shortname, type, secret, server FROM nas' rlm_sql (sql): Adding client 192.168.0.1 (AP01) to rif clients list *Failed to find virtual server rif*
I've pushed a fix. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
nicolas.clo@ricoh-industrie.fr wrote:
But just last question, now if I have same entry in clients.conf than nas mysql table (with mod-enabled - sql --> * read_clients = yes*) , at Freeradius startup, it tell me that duplicate rows exists but just for global section and not for rif section. Is it normal ?
If that's how you configured it. I'd need to know more about your configuration before being sure. Alan DeKok.
Update: Alan, See my virtual server rif listen conf: server rif { listen { ipaddr = * port = 3812 type = auth } ..... ...... } If I try that, there is the same problem. log: rlm_sql (sql): Adding client 192.168.50.190 (AP07) to rif clients list rlm_sql (192.168.50.190): Client "AP07" (sql) added Listening on auth address * port 1812 as server default Listening on auth address * port 3812 as server rif Listening on status address * port 18121 as server status Listening on auth address 127.0.0.1 port 18120 as server inner-tunnel Ready to process requests Ignoring request to auth address * port 1812 as server default from unknown client 192.168.50.190 port 1645 proto udp Ready to process requests My nas is configured to send request to rif ( port 3812 ) If I don't use nas table but clients.conf, it works. Thanks. nicolas.clo@ricoh-industrie.fr wrote:
But just last question, now if I have same entry in clients.conf than nas mysql table (with mod-enabled - sql --> * read_clients = yes*) , at Freeradius startup, it tell me that duplicate rows exists but just for global section and not for rif section. Is it normal ?
If that's how you configured it. I'd need to know more about your configuration before being sure. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
If I don't use nas table but clients.conf, it works.
yes - the clients.conf has FAR more features than the SQL table method - there are a whoel load of things you can do with clients/conf that you cant do with the nas table in sql module - look at the code - you'll see the few hardcoded, ordered columns that you can use. alan
No sorry, it doesn't work == Contenu de la table nas |7192.168.50.190|AP07|cisco|NULL|Password|rif|NULL|RADIUS Client rlm_sql (sql): Adding client 192.168.50.190 (AP07) to rif clients list rlm_sql (192.168.50.190): Client "AP07" (sql) added Listening on auth address * port 1812 as server default Listening on auth address 127.0.0.1 port 3812 as server rif Listening on status address * port 18121 as server status Listening on auth address 127.0.0.1 port 18120 as server inner-tunnel Ready to process requests Ignoring request to auth address * port 1812 as server default from unknown client 192.168.50.190 port 1645 proto udp --> It listen on 1812 port instead of 3812 for rif virtual server __________________________________________________________________________ Nicolas CLO Industrial and Network Technician ITS RICOH INDUSTRIE FRANCE SAS 144, route de Rouffach, 68920 WETTOLSHEIM Tel: +33 (0) 3 89 20 48 84 nicolas.clo@ricoh-industrie.fr | www.ricoh-thermal.com De : Alan DeKok <aland@deployingradius.com> A : FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Date : 08/09/2014 17:35 Objet : Re: Virtual Server Envoyé par : freeradius-users-bounces+nicolas.clo=ricoh-industrie.fr@lists.freeradius.org nicolas.clo@ricoh-industrie.fr wrote:
Sorry if it's a stupid question but since Freeradius 3.0.4 ( Version 3.0.4 (git #9b5c955) ), my custom virtual server is ignored by freeradius at startup
...
rlm_sql (sql): Executing query: 'SELECT id, nasname, shortname, type, secret, server FROM nas' rlm_sql (sql): Adding client 192.168.0.1 (AP01) to rif clients list *Failed to find virtual server rif*
I've pushed a fix. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
nicolas.clo@ricoh-industrie.fr wrote:
No sorry, it doesn't work
Yes, it does.
|7192.168.50.190|AP07|cisco|NULL|Password|rif|NULL|RADIUS Client
Public IP... going to virtual server "rif"
Listening on auth address * port 1812 as server default Listening on auth address 127.0.0.1 port 3812 as server rif
Virtual server "rif" is listening only on a local IP.
*Ignoring request to auth address * port 1812 as server default from unknown client 192.168.50.190 port 1645 proto udp*
The packet is being sent to address "*", not 127.0.0.1. So it won't ever be sent to the virtual server. I meant what I said in my previous message... clients are tied to a "listen" section, OR global. In this case, they're tied to the "listen" section which is listening on 127.0.0.1, port 3812. So packets sent to ANOTHER destination IP will never match that client. Alan DeKok.
Ok but I don't understand why if I put he same rows in clients.conf and if I comment " with mod-enabled - sql --> * read_clients = yes*" it works. nicolas.clo@ricoh-industrie.fr wrote:
No sorry, it doesn't work
Yes, it does.
|7192.168.50.190|AP07|cisco|NULL|Password|rif|NULL|RADIUS Client
Public IP... going to virtual server "rif"
Listening on auth address * port 1812 as server default Listening on auth address 127.0.0.1 port 3812 as server rif
Virtual server "rif" is listening only on a local IP.
*Ignoring request to auth address * port 1812 as server default from unknown client 192.168.50.190 port 1645 proto udp*
The packet is being sent to address "*", not 127.0.0.1. So it won't ever be sent to the virtual server. I meant what I said in my previous message... clients are tied to a "listen" section, OR global. In this case, they're tied to the "listen" section which is listening on 127.0.0.1, port 3812. So packets sent to ANOTHER destination IP will never match that client. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
nicolas.clo@ricoh-industrie.fr wrote:
Ok but I don't understand why if I put he same rows in clients.conf and if I comment " with mod-enabled - sql --> * read_clients = yes*" it works.
Because the configuration files have more flexibility than the SQL tables. The configuration files allow you tie a client to a "listen" section AND a virtual server. You do this by listing a global client (which ties it to the global listen sections), and then setting "virtual_server" in the client definition. You can't do that with SQL. There's only a field for virtual server. As I already said, the clients in SQL are tied to a virtual server... and to any "listen" section for that virtual server. If you want them to be tied to the global listen sections, you'll have to: (a) remove the "listen" from the virtual server or (b) put the clients into the configuration files. Alan DeKok.
Ah Ok, this is new since 3.0.4. Thanks for your time and explanations. Regards. nicolas.clo@ricoh-industrie.fr wrote:
Ok but I don't understand why if I put he same rows in clients.conf and if I comment " with mod-enabled - sql --> * read_clients = yes*" it works.
Because the configuration files have more flexibility than the SQL tables. The configuration files allow you tie a client to a "listen" section AND a virtual server. You do this by listing a global client (which ties it to the global listen sections), and then setting "virtual_server" in the client definition. You can't do that with SQL. There's only a field for virtual server. As I already said, the clients in SQL are tied to a virtual server... and to any "listen" section for that virtual server. If you want them to be tied to the global listen sections, you'll have to: (a) remove the "listen" from the virtual server or (b) put the clients into the configuration files. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
nicolas.clo@ricoh-industrie.fr wrote:
Ah Ok, this is new since 3.0.4.
Sort of. The issue is that prior to 3.0.4, clients loaded from SQL were ALWAYS attached to the global listeners. This causes problems, because people want to use the same client IP in multiple virtual servers. And that doesn't work. In order to fix that, some behavior is changed. There is no perfect solution, because the SQL tables have LESS information than the configuration files. So... delete the "listen" section from the "rif" virtual server. It will then do what you want. Alan DeKok.
Alan, See my virtual server rif listen conf: server rif { listen { ipaddr = * port = 3812 type = auth } ..... ...... } If I try that, there is the same problem. log: rlm_sql (sql): Adding client 192.168.50.190 (AP07) to rif clients list rlm_sql (192.168.50.190): Client "AP07" (sql) added Listening on auth address * port 1812 as server default Listening on auth address * port 3812 as server rif Listening on status address * port 18121 as server status Listening on auth address 127.0.0.1 port 18120 as server inner-tunnel Ready to process requests Ignoring request to auth address * port 1812 as server default from unknown client 172.29.50.190 port 1645 proto udp Ready to process requests My nas is configured to send request to rif ( port 3812 ) If I don't use nas table but clients.conf, it works. Thanks. nicolas.clo@ricoh-industrie.fr wrote:
No sorry, it doesn't work
Yes, it does.
|7192.168.50.190|AP07|cisco|NULL|Password|rif|NULL|RADIUS Client
Public IP... going to virtual server "rif"
Listening on auth address * port 1812 as server default Listening on auth address 127.0.0.1 port 3812 as server rif
Virtual server "rif" is listening only on a local IP.
*Ignoring request to auth address * port 1812 as server default from unknown client 192.168.50.190 port 1645 proto udp*
The packet is being sent to address "*", not 127.0.0.1. So it won't ever be sent to the virtual server. I meant what I said in my previous message... clients are tied to a "listen" section, OR global. In this case, they're tied to the "listen" section which is listening on 127.0.0.1, port 3812. So packets sent to ANOTHER destination IP will never match that client. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
nicolas.clo@ricoh-industrie.fr wrote:
See my virtual server rif listen conf:
*server rif {*
*listen {* * ipaddr = ** * port = 3812* * type = auth* *}*
*.....* *......* *}*
If I try that, there is the same problem.
Yes. I really don't know how to make this any more clear. That's how it works. I've told you repeatedly that's how it works. I've told you repeatedly how to fix it. Alan DeKok.
participants (5)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Fajar A. Nugraha -
Kev Pearce -
nicolas.clo＠ricoh-industrie.fr