Bug 1685546

Summary: radiusd fails to resolve hostname in ipaddr if the hostname points to ipv6 address.
Product: Red Hat Enterprise Linux 8 Reporter: Ivan Nikolchev <inikolch>
Component: freeradiusAssignee: Alex Scheel <ascheel>
Status: CLOSED ERRATA QA Contact: Filip Dvorak <fdvorak>
Severity: medium Docs Contact: Filip Hanzelka <fhanzelk>
Priority: medium    
Version: 8.0CC: ads.kuknus, alancuberoab, andreeone23, ascheel, berrange, garrisonhudson520268, hennysmath12, jwakely, kkimdavenport, ladyjames6600, laetotoid, lmanasko, luckywin89, mathersondferwqe, mharmsen, nikolai.kondrashov, otis5842, pasik, pkis, pochardwillowherb, raymondbarry78, rharwood, thursday0147, zetisonapi
Target Milestone: rcKeywords: Reopened
Target Release: 8.1   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: freeradius-3.0.17-6 Doc Type: Bug Fix
Doc Text:
.FreeRADIUS now resolves hostnames pointing to IPv6 addresses In previous RHEL 8 versions of FreeRADIUS, the `ipaddr` utility only supported IPv4 addresses. Consequently, for the `radiusd` daemon to resolve IPv6 addresses, a manual update of the configuration was required after an upgrade of the system from RHEL 7 to RHEL 8. This update fixes the underlying code, and `ipaddr` in FreeRADIUS now uses IPv6 addresses, too.
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-11-05 20:54:08 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1683260    
Bug Blocks:    

Description Ivan Nikolchev 2019-03-05 12:55:28 UTC
Description of problem:

If we configure ipaddr to be something like "ipaddr = radiusipv6.test.com" and 
radiusipv6.test.com points to ::1, radiusd tries to resolve the hostname to ipv4 address and fails with:
"Failed resolving "radiusipv6.test.com" to IPv4 address: Name or service not known"

radiusipv6.test.com resolves correctly with nslookup and dig:

Server:         127.0.0.1
Address:        127.0.0.1#53

Name:   radiusipv6.test.com
Address: ::1

$ dig radiusipv6.test.com ANY @127.0.0.1

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-16.P2.el8 <<>> radiusipv6.test.com ANY @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4984
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: b6aea33c0406a5db47e36d9f5c7e6e3517a04cf1ad42adf9 (good)
;; QUESTION SECTION:
;radiusipv6.test.com.           IN      ANY

;; ANSWER SECTION:
radiusipv6.test.com.    86400   IN      AAAA    ::1

;; AUTHORITY SECTION:
test.com.               86400   IN      NS      dns1.test.com.

;; ADDITIONAL SECTION:
dns1.test.com.          86400   IN      A       127.0.0.1

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Mar 05 07:40:21 EST 2019
;; MSG SIZE  rcvd: 139


Version-Release number of selected component (if applicable):
freeradius-3.0.17-3.module+el8+2746+2e560403.x86_64
bind-9.11.4-16.P2.el8.x86_64

How reproducible:
Always

Steps to Reproduce:
1.Setup local bind server with a zone that contains something like "radiusipv6 IN  AAAA      ::1"
2.Configure the default site in sites-enabled to listen on this hostname with "ipaddr = radiusipv6.test.com"
3.run "radiusd -X"

Actual results:

radiusd: #### Loading Virtual Servers ####
server { # from file /etc/raddb/radiusd.conf
} # server
server default { # from file /etc/raddb/sites-enabled/default
 # Loading authenticate {...}
 # Loading authorize {...}
Ignoring "sql" (see raddb/mods-available/README.rst)
Ignoring "ldap" (see raddb/mods-available/README.rst)
 # Loading preacct {...}
 # Loading post-proxy {...}
 # Loading post-auth {...}
} # server default
radiusd: #### Opening IP addresses and Ports ####
listen {
        type = "auth"
Failed resolving "radiusipv6.test.com" to IPv4 address: Name or service not known


Expected results:
radiusd should start to listen on address ::1 port 1812 .

This is output from freeradius-3.0.15-18:

radiusd: #### Loading Virtual Servers ####
server { # from file /etc/raddb/radiusd.conf
} # server
server default { # from file /etc/raddb/sites-enabled/default
 # Loading authenticate {...}
 # Loading authorize {...}
Ignoring "sql" (see raddb/mods-available/README.rst)
Ignoring "ldap" (see raddb/mods-available/README.rst)
 # Loading preacct {...}
 # Loading post-proxy {...}
 # Loading post-auth {...}
} # server default
radiusd: #### Opening IP addresses and Ports ####
listen {
        type = "auth"
        ipaddr = radiusipv6.test.com IPv 6 address [::1]
        port = 0
   limit {
        max_connections = 16
        lifetime = 0
        idle_timeout = 30
   }
}
Listening on auth address ::1 port 1812 bound to server default
Listening on proxy address :: port 60405


Additional info:

relevant test: /CoreOS/freeradius/Sanity/check-ipaddr-ipv4addr-and-ipv6addr-address-usage

Comment 1 Alex Scheel 2019-03-05 19:03:34 UTC
Per discussion on IRC, users should use `ipv6addr` instead of `ipaddr` in the case of IPv6-only addresses.

Comment 2 Ivan Nikolchev 2019-03-12 11:10:37 UTC
I went to review the test and I saw that setting ipv6 address directly in ipaddr works without problem, its only when there is hostname in ipaddr and that hostname is pointing to ipv6.

radiusd: #### Loading Virtual Servers ####
server { # from file /etc/raddb/radiusd.conf
} # server
server default { # from file /etc/raddb/sites-enabled/default
 # Loading authenticate {...}
 # Loading authorize {...}
Ignoring "sql" (see raddb/mods-available/README.rst)
Ignoring "ldap" (see raddb/mods-available/README.rst)
 # Loading preacct {...}
 # Loading post-proxy {...}
 # Loading post-auth {...}
} # server default
radiusd: #### Opening IP addresses and Ports ####
listen {
        type = "auth"
        ipaddr = ::1
        port = 0
   limit {
        max_connections = 16
        lifetime = 0
        idle_timeout = 30
   }
}
Listening on auth address ::1 port 1812 bound to server default
Listening on proxy address :: port 43671
Ready to process requests

If ipaddr only supports ipv4 then using something like "ipaddr = ::1" should not be allowed. Should we open new bug for that?

Comment 3 Alex Scheel 2019-04-22 19:00:07 UTC
I can confirm that setting an IPv6 address directly works and that changing to ipv6addr works as well, but that ipaddr doesn't seem to work with a IPv6-only hostname.


It appears to have broken sometime between 3.0.16 and 3.0.17... and it is still broken on latest v3.0.x branch. The commit in question (via bisect):
https://github.com/FreeRADIUS/freeradius-server/commit/5452b13cefa3b30f1da467ff5d68b3c1aa471188


And in particular, the new line 616:
https://github.com/FreeRADIUS/freeradius-server/commit/5452b13cefa3b30f1da467ff5d68b3c1aa471188#diff-fdb142d675e35dd830c2de8b17218c6eR616


I've added it as a PR upstream, we'll see what the feedback is:
https://github.com/FreeRADIUS/freeradius-server/pull/2627


The behavior of listen.ipaddr is weird even without this change. From the upstream documentation, this picks *whichever resolves first* (of the A and AAAA records); in implementation, this is always the A record because it is tried first.

I'm still inclined to leave this as an open bug (+ doc text update) and at most roll this into the next update. Most users will know if they're using a IPv6-only domain and can switch to ipv6addr if they need to on update. The error message is obvious enough, and the comments in the configuration refer to the alternate value (use ipv6addr instead).

Comment 14 errata-xmlrpc 2019-11-05 20:54:08 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2019:3353

Comment 19 Sasuke2690 2022-11-23 04:50:05 UTC Comment hidden (spam)
Comment 21 andreeoren 2022-12-14 09:08:24 UTC Comment hidden (spam)
Comment 32 pochardwillowherb 2023-05-18 08:16:22 UTC Comment hidden (spam)
Comment 33 zetiano 2023-07-01 01:13:16 UTC Comment hidden (spam)