Dualstack NAS ignored by RADIUS server when using IPv4
Hello all, I'm running freeRADIUS 2.2.0 server on dualstack machine. Some of the NAS devices that are using this server are dualstack, but they are not able to use IPv6 for communicating with RADIUS server so they use only the IPv4. Problem is that these NAS devices are rejected by RADIUS server with following error: Error: Ignoring request to authentication address 10.0.0.1 port 1812 from unknown client 10.0.0.2 port 1812 DNS: freeRADIUS server: radius.example.com - IPv4: 10.0.0.1 - IPv6: 2001:a:b:c::1 NAS device: dev1.example.com - IPv4: 10.0.0.2 - IPv6: 2001:a:b:c::2 RADIUS nas table: id | nasname | shortname | type | ports | secret | community | description | server ----+-------------------+-----------+-------+--------+---------------+-----------+-------------+-------------- 1 | dev1.example.com | dev1 | other | <NULL> | shared_secret | <NULL> | <NULL> | inner-tunnel By adding folloving to nas table it works: id | nasname | shortname | type | ports | secret | community | description | server ----+-------------------+-----------+-------+--------+---------------+-----------+-------------+-------------- 2 | 10.0.0.2 | dev1 | other | <NULL> | shared_secret | <NULL> | <NULL> | inner-tunnel ( it works as workaround but i think that it should work as well with hostname only ) Having IPv4-only or IPv6-only NAS doesn't trigger this problematic behaviour, as well as having dualstack NAS taht can communicate with RADIUS over IPv6. looks like bug to me, anyone experienced similiar problems? -- Ondrej Famera unix@fi
Hello, freeradius not working in normal mode but working in debug mode Please suggest. Thanks, Nand
On 02/11/2013 08:57 AM, Nandkumar Palkar wrote:
Hello,
freeradius not working in normal mode but working in debug mode
Stop that. That's the 3rd time you've posted, and this time you've hijacked someone elses thread. That's rude.
Firstly, I'd suggest not posting the same question 3 times in 1 hour. I don't have a problem with it (personally), but it's rather rude, especially on a low volume list like this. The reason it's not working is probably to do with permissions - check what user account you are running it as in Debug mode, and what user account you are running it in in normal mode. I've had this exact same issue, and it was because I was testing it as root, but when trying to run it, it was being run as another user account (probably "nobody" or "freeradius"). Regards, -- Jon "The Nice Guy" Spriggs On 11 February 2013 08:57, Nandkumar Palkar <nandupalkar@yahoo.com> wrote:
Hello,
freeradius not working in normal mode but working in debug mode
Please suggest.
Thanks, Nand
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Ondrej Famera <famera@fi.muni.cz> writes:
freeRADIUS server: radius.example.com - IPv4: 10.0.0.1 - IPv6: 2001:a:b:c::1
NAS device: dev1.example.com - IPv4: 10.0.0.2 - IPv6: 2001:a:b:c::2
RADIUS nas table: id | nasname | shortname | type | ports | secret | community | description | server ----+-------------------+-----------+-------+--------+---------------+-----------+-------------+-------------- 1 | dev1.example.com | dev1 | other | <NULL> | shared_secret | <NULL> | <NULL> | inner-tunnel
Never use DNS to identify a client. A client is uniqueliy identified by its IP address. Hiding this behind DNS is just confusing. For example: * You thought a single client with multiple IPs would work - It won't * You might think that you can change the DNS entry without restarting FreeRADIUS - you cannot * You might think that you can configure a client without knowing its address first - you cannot.
By adding folloving to nas table it works: id | nasname | shortname | type | ports | secret | community | description | server ----+-------------------+-----------+-------+--------+---------------+-----------+-------------+-------------- 2 | 10.0.0.2 | dev1 | other | <NULL> | shared_secret | <NULL> | <NULL> | inner-tunnel
( it works as workaround but i think that it should work as well with hostname only )
That is not a "workaround". It is the correct way to configure a client. If you want to allow a client to use multiple addresses, then you need to add an entry for each address. But you should really not do that. Choose a single source address for each client. This implies that you must choose a single address family. There is no such thing as a "dual stack RADIUS client". Either you use IPv4 or you use IPv6. This goes for *any* managment protocol. It's not some service you are providing to any random Internet client. You explicitly configure each end and you want to do that as precisely as possible. Try configuring your BGP peers using DNS ans see how well that works... Bjørn
Hello Bjørn, On 02/11/2013 10:27 AM, Bjørn Mork wrote: > Ondrej Famera <famera@fi.muni.cz> writes: > >> freeRADIUS server: >> radius.example.com >> - IPv4: 10.0.0.1 >> - IPv6: 2001:a:b:c::1 >> >> NAS device: >> dev1.example.com >> - IPv4: 10.0.0.2 >> - IPv6: 2001:a:b:c::2 >> >> RADIUS nas table: >> id | nasname | shortname | type | ports | secret | community | description | server >> ----+-------------------+-----------+-------+--------+---------------+-----------+-------------+-------------- >> 1 | dev1.example.com | dev1 | other | <NULL> | shared_secret | <NULL> | <NULL> | inner-tunnel > > Never use DNS to identify a client. A client is uniqueliy identified by > its IP address. Hiding this behind DNS is just confusing. For example: > * You thought a single client with multiple IPs would work - It won't > * You might think that you can change the DNS entry without restarting > FreeRADIUS - you cannot > * You might think that you can configure a client without knowing its > address first - you cannot. * I hoped that if i got reliable DNS with correct records then RADIUS would resolve them the right way (either all of them or none) - but it resolves only one of them > >> By adding folloving to nas table it works: >> id | nasname | shortname | type | ports | secret | community | description | server >> ----+-------------------+-----------+-------+--------+---------------+-----------+-------------+-------------- >> 2 | 10.0.0.2 | dev1 | other | <NULL> | shared_secret | <NULL> | <NULL> | inner-tunnel >> >> ( it works as workaround but i think that it should work as well with hostname only ) > > That is not a "workaround". It is the correct way to configure a > client. If you want to allow a client to use multiple addresses, > then you need to add an entry for each address. > > But you should really not do that. Choose a single source address for > each client. This implies that you must choose a single address family. > There is no such thing as a "dual stack RADIUS client". Either you use > IPv4 or you use IPv6. - In my case the hard work is done by script which knows which devices should be put into client table and puts them there based on their hostnames, - so as more correct approach i see that script would also do resolving hostnames to addresses before putting them in clients table. ( i got list of hostnames, so the lazy approach is to use them if it's possible ) > This goes for *any* managment protocol. It's not some service you are > providing to any random Internet client. You explicitly configure each > end and you want to do that as precisely as possible. Try configuring > your BGP peers using DNS ans see how well that works... > > > Bjørn > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > Thanks for quick response and clarification, the address-based approach now looks much better than before :) -- Ondrej Famera unix@fi
Hi,
By adding folloving to nas table it works: id | nasname | shortname | type | ports | secret | community | description | server ----+-------------------+-----------+-------+--------+---------------+-----------+-------------+-------------- 2 | 10.0.0.2 | dev1 | other | <NULL> | shared_secret | <NULL> | <NULL> | inner-tunnel
but did you either 1) restart the RADIUS server after this entry got added (plain SQL entries are not dynamic!) or 2) configure the dynamic clients module so that your entries could be read from SQL dynamically? alan
Hi Alan, On 02/11/2013 11:25 AM, A.L.M.Buxey@lboro.ac.uk wrote: > Hi, > >> By adding folloving to nas table it works: >> id | nasname | shortname | type | ports | secret | community | description | server >> ----+-------------------+-----------+-------+--------+---------------+-----------+-------------+-------------- >> 2 | 10.0.0.2 | dev1 | other | <NULL> | shared_secret | <NULL> | <NULL> | inner-tunnel > > > but did you either > > 1) restart the RADIUS server after this entry got added (plain SQL entries are not dynamic!) - yes, I restart RADIUS after adding/removing record from DB, but result is that only one address is resolved per hostname (so dualstack hostname get resolved only to single IPv6 address - in context of RADIUS server, regular DNS query returns both IPv4 and IPv6 address) > or > > 2) configure the dynamic clients module so that your entries could be read from SQL dynamically? - i haven't tried this yet, but it looks like i still need to resolve hostnames to addresses somewhere while my goal was to avoid this and let the RADIUS to do this stuff - furthermore i have a different secret for every hostname on the same network (like 10.0.0.0/24) and according to documentation (raddb/sites-available/dynamic_clients) i need to assign secrets to addresses not hostnames, so it looks again as no-go solution for me - thanks for suggesting this as improvement for not needing to restart radius every time i add new nas, i should do some research into it > alan > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- Ondrej Famera unix@fi
Ondrej Famera wrote:
- yes, I restart RADIUS after adding/removing record from DB, but result is that only one address is resolved per hostname (so dualstack hostname get resolved only to single IPv6 address - in context of RADIUS server, regular DNS query returns both IPv4 and IPv6 address)
RADIUS uses the source IP address to look up the shared secret. There is no "multiple IPs map to one secret" functionality. I'd be opposed to adding that, as it doesn't follow traditional RADIUS practice. i.e. The other RADIUS clients/servers on the network don't behave this way, either. On top of that, it gets into issues of responsibility. The DNS system may not be managed by the RADIUS department. And you don't want the DNS people to take down your RADIUS server by breaking DNS. So it's safer to use IP addresses.
- i haven't tried this yet, but it looks like i still need to resolve hostnames to addresses somewhere while my goal was to avoid this and let the RADIUS to do this stuff
RADIUS depends on addresses, not host names. Using host names is wrong.
- furthermore i have a different secret for every hostname on the same network (like 10.0.0.0/24) and according to documentation (raddb/sites-available/dynamic_clients) i need to assign secrets to addresses not hostnames, so it looks again as no-go solution for me
You can just use addresses. But maybe you mean you have two hostnames, both mapping to one address, but with different secrets. No, that's not going to work. It's impossible. RADIUS doesn't work that way. Alan DeKok.
participants (7)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Bjørn Mork -
Jon Spriggs -
Nandkumar Palkar -
Ondrej Famera -
Phil Mayers