freeradius 2.1.1, configured to use multiple virtual servers, seems to select the server to use depending on the host sending the request, not depending on the NAS-IP-Address in the request. When using radtest I get: norbert@suse:~$ radtest 000000000002 000000000002 psucoll 0 secret dummy 1.1.1.1 Sending Access-Request of id 227 to 123.25.153.210 port 1812 User-Name = "000000000002" User-Password = "000000000002" NAS-IP-Address = 1.1.1.1 NAS-Port = 0 Framed-Protocol = PPP rad_recv: Access-Accept packet from host 123.25.153.210 port 1812, id=227, length=20 while radiusd -X shows ..... Going to the next request Waking up in 4.9 seconds. rad_recv: Access-Request packet from host 149.246.185.169 port 54115, id=244, length=70 User-Name = "000000000001" User-Password = "000000000001" NAS-IP-Address = 1.1.1.1 NAS-Port = 0 Framed-Protocol = PPP server enterasys { .... 1.1.1.1 is a nas belonging to the server cisco, 149.246.185.169 belongs to the server enterasys. I would have expected, the server is choosen because of the NAS-IP-Address. Thanks Norbert Wegener
Norbert Wegener wrote:
freeradius 2.1.1, configured to use multiple virtual servers, seems to select the server to use depending on the host sending the request, not depending on the NAS-IP-Address in the request.
Yes. See raddb/sites-available/README. When a client is tied to a virtual server, it is done by source IP address.
I would have expected, the server is choosen because of the NAS-IP-Address.
That configuration can be added manually, by doing internal proxying to the virtual server. Alan DeKok.
Alan DeKok schrieb:
Norbert Wegener wrote:
freeradius 2.1.1, configured to use multiple virtual servers, seems to select the server to use depending on the host sending the request, not depending on the NAS-IP-Address in the request.
Yes. See raddb/sites-available/README. When a client is tied to a virtual server, it is done by source IP address.
Ok.
I would have expected, the server is choosen because of the NAS-IP-Address.
That configuration can be added manually, by doing internal proxying to the virtual server.
Will this also be possible, when freeradius gets its information out of a mysql database? The only place to modify addresses I found is the preproxy_users file, which seems to be used by the rlm_files module only. Norbert Wegener
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Will this also be possible, when freeradius gets its information out of a mysql database? The only place to modify addresses I found is the preproxy_users file, which seems to be used by the rlm_files module only.
You can change server in authorize too. Ivan Kalik Kalik Informatika ISP
Norbert Wegener wrote:
That configuration can be added manually, by doing internal proxying to the virtual server.
Will this also be possible, when freeradius gets its information out of a mysql database?
Of course!
The only place to modify addresses I found is the preproxy_users file, which seems to be used by the rlm_files module only.
I'm not sure what that means... You could do something like: ... update control { Proxy-To-Realm := "%{sql:SELECT ... from.. where %{NAS-IP-Addres}" } Could you describe more of your requirements?? Alan DeKok.
Alan DeKok schrieb:
Norbert Wegener wrote:
That configuration can be added manually, by doing internal proxying to the virtual server.
Will this also be possible, when freeradius gets its information out of a mysql database?
Of course!
The only place to modify addresses I found is the preproxy_users file, which seems to be used by the rlm_files module only.
I'm not sure what that means...
You could do something like:
... update control { Proxy-To-Realm := "%{sql:SELECT ... from.. where %{NAS-IP-Addres}" }
OK, but I did not yet hear about that before and it seems no topic for the mass media: googling for Proxy-To-Realm gives 94 results.
Could you describe more of your requirements??
In a greater installation there are numerous different rules for vlan assignements. Before applying even the slightest configuration change to a production system, I want to make sure, that as much different configurations as possible have been checked to deliver those attributes that they are expected to. Obviously a part of those checks can be done using radtest. Running radtest with nasip as an argument should therefore bring freeradius to use the server the nasip belongs to, and not the server the machine running radtest belongs to. Btw: Is eapol_test *the* tool to do such checks in an automated way for eap/tls authentications or is there a better one available? Norbert Wegener
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Norbert Wegener wrote:
update control { Proxy-To-Realm := "%{sql:SELECT ... from.. where %{NAS-IP-Addres}" }
OK, but I did not yet hear about that before and it seems no topic for the mass media: googling for Proxy-To-Realm gives 94 results.
It's not well documented...
In a greater installation there are numerous different rules for vlan assignements. Before applying even the slightest configuration change to a production system, I want to make sure, that as much different configurations as possible have been checked to deliver those attributes that they are expected to. Obviously a part of those checks can be done using radtest. Running radtest with nasip as an argument should therefore bring freeradius to use the server the nasip belongs to, and not the server the machine running radtest belongs to.
Hmm... OK. That's reasonable, and can be done. But it may take some minor effort. My $0.02: - set up one fake realm for each virtual server - point the realm to a home server pool - point the home server pool to a home server - point the home server to the virtual_server Then: - create a "listen" section ONLY for testing - point it to a "testing" virtual server - configure a policy to switch over NAS-IP-Address: switch "%{NAS-IP-Address}" { case 1.2.3.4 { update control { Proxy-To-Realm = "home_server_foo" } } ... It's a fair bit of typing, unfortunately. I can take a look at poking the code to simplify it a little bit. i.e. create the listen section for testing, and then in it, do: update control { Proxy-To-Virtual-Server := "%{config:client[%{NAS-IP-Address].virtual_server}" } i.e. proxy to a virtual server rather than a realm (this isn't implemented yet). Then... look for a "client" section in the configuration, that has a name matching the NAS-IP-Address of the current packet... and grab the "virtual_server" configuration from that client section.
Btw: Is eapol_test *the* tool to do such checks in an automated way for eap/tls authentications or is there a better one available?
It's the best tool by far. I'm thinking of deleting radeapclient from the FreeRADIUS source, because it does a lot less. Alan DeKok.
participants (3)
-
Alan DeKok -
Norbert Wegener -
tnt＠kalik.net