Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
.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.
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
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?
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).
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 19Sasuke2690
2022-11-23 04:50:05 UTC
Comment hidden (spam)
This comment was flagged a spam, view the edit history to see the original text if required.
Comment 21andreeoren
2022-12-14 09:08:24 UTC
Comment hidden (spam)
This comment was flagged a spam, view the edit history to see the original text if required.
Comment 32pochardwillowherb
2023-05-18 08:16:22 UTC
Comment hidden (spam)
ipaddr used to be able to handle both IPv4 and IPv6 addresses in older versions of FreeRADIUS. Now it... → .Hostname resolution for IPv6 addresses fails with FreeRADIUS. while using older versions of FreeRA. Setting an IPv6 address directly and switching to ipv6addr both work, however ipaddr doesn't seem to function with a hostname that only supports IPv6. https://driving-directions.co
Comment 33zetiano
2023-07-01 01:13:16 UTC
Comment hidden (spam)
Resolving hostnames to IP addresses is a fundamental aspect of networking. It allows systems to [paper io](https://paperio2.io) communicate effectively by translating human-readable names into machine-readable IP addresses. While IPv4 addresses have been traditionally used, the adoption of IPv6 is increasing, and radiusd should be able to handle the resolution of both IPv4 and IPv6 addresses seamlessly.
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