[RADIATOR] AuthDNSROAM DNS SRV Lookup Failure

[Fernando Reis]

Hello,

I have selinux in permissive mode so it should doesn’t interfere with traffic
Running the command you told me to result is ok. I seems to be a radiator bug.
Can it be linux limits? I added the following lines do my security.conf file:
*       soft    nofile  70000
*       hard    nofile  80000

These are very high limits for our number of users

Regards,

Fernando Reis
IT Services | Polytechnic Institute of Castelo Branco
Av. Pedro Álvares Cabral n.º 12 6000-084 Castelo Branco - Portugal
T +351 272 339 600 | F +351 272 339 601 | @ fereis at ipcb.pt

From: Frank Danielson [mailto:FDanielson at csky.com]
Sent: 17 de março de 2017 19:45
To: Fernando Reis <fereis at ipcb.pt>
Cc: radiator at lists.open.com.au
Subject: Re: [RADIATOR] AuthDNSROAM DNS SRV Lookup Failure

Hi Fernando-

Try checking the /var/log/audit/audit.log file to see if selinux is denying the traffic. That has bitten me more than once.

Also try to do the lookup with Net::DNS outside of Radiator. This lookup yielded both the NAPTR and SRV records.

perl -e 'use Net::DNS;
my $res   = Net::DNS::Resolver->new;
my $reply = $res->query("id.fccn.pt<http://id.fccn.pt>", "NAPTR");
foreach $rr ($reply->answer) {
$rr->print;
if ($rr->service eq "x-eduroam:radius.tls"){
my $reply = $res->query($rr->replacement, "SRV");
foreach $rr ($reply->answer) {$rr->print;}}}'

id.fccn.pt<http://id.fccn.pt>.
84181 IN
NAPTR ( 100 10 s x-eduroam:radius.tls ""
_radsec._tcp.fccn.pt<http://tcp.fccn.pt>. )
_radsec._tcp.fccn.pt<http://tcp.fccn.pt>.
84181 IN
SRV 0 0 2083 radius01.fccn.pt<http://radius01.fccn.pt>.
_radsec._tcp.fccn.pt<http://tcp.fccn.pt>.
84181 IN
SRV 0 10 2083 radius02.fccn.pt<http://radius02.fccn.pt>.

ClearSky Technologies, Inc.
Frank Danielson | Chief Technology Officer
• fdanielson at csky.com<applewebdata://B42CE82B-00AD-4466-A1C0-45CE1FB8AEBB/notifications@csky.com>

On Mar 17, 2017, at 2:06 PM, Fernando Reis <fereis at ipcb.pt<mailto:fereis at ipcb.pt>> wrote:

Hello,

We are in the process of implementing radsec on our server but when using authby DNSROAM the SRV lookup always fail:

Radiator logs:
Fri Mar 17 15:56:20 2017: DEBUG: Handling with Radius::AuthDNSROAM
Fri Mar 17 15:56:20 2017: DEBUG: Resolver doing NAPTR lookup for id.fccn.pt<http://id.fccn.pt/>,
Fri Mar 17 15:56:20 2017: DEBUG: AuthBy DNSROAM result: IGNORE, Discovering RadSec servers
Fri Mar 17 15:56:20 2017: DEBUG: Resolver found NAPTR record for realm id.fccn.pt<http://id.fccn.pt/>: id.fccn.pt<http://id.fccn.pt/>.  73857   IN      NAPTR   ( 100 10 s x-eduroam:radius.tls ""
        _radsec._tcp.fccn.pt<http://tcp.fccn.pt/>. )
Fri Mar 17 15:56:20 2017: DEBUG: Resolver doing SRV lookup for _radsec._tcp.fccn.pt<http://tcp.fccn.pt/>, Protocol radius Transport tcp UseTLS 1 Order 100 Preference 10
Fri Mar 17 15:56:25 2017: INFO: Resolver: No reply from DNS for SRV request for realm id.fccn.pt<http://id.fccn.pt/>
Fri Mar 17 15:56:25 2017: DEBUG: AuthBy DNSROAM: No hardwired Route, no discovered Route, using DEFAULT Route for id.fccn.pt<http://id.fccn.pt/>

When we do a tcpdump on the radius server we see that the dns server responds to the request but the radius sends (final line) port unreachable and the resolving of the SRV request fails:

Tcpdump radius (193.137.66.131) > dns (193.137.66.129):
12:37:13.937148 IP 193.137.66.131.40586 > 193.137.66.129.53: 63986+ NAPTR? id.fccn.pt<http://id.fccn.pt/>. (28)
12:37:13.937383 IP 193.137.66.129.53 > 193.137.66.131.40586: 63986 1/0/6 NAPTR (268)
12:37:13.945746 IP 193.137.66.131.40586 > 193.137.66.129.53: 37804+ SRV? _radsec._tcp.fccn.pt<http://tcp.fccn.pt/>. (38)
12:37:13.946034 IP 193.137.66.129.53 > 193.137.66.131.40586: 37804 2/0/4 SRV radius01.fccn.pt<http://radius01.fccn.pt/>.:2083 0 0, SRV radius02.fccn.pt<http://radius02.fccn.pt/>.:2083 0 10 (198)
12:37:13.946058 IP 193.137.66.131 > 193.137.66.129: ICMP 193.137.66.131 udp port 40586 unreachable, length 234

I’ve installed all the necessary modules: Net::DNS + Socket6 + IO::Socket::INET6 for this to work but it always fails.

Anyone has an idea how to solve this?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.open.com.au/pipermail/radiator/attachments/20170320/5a091b6c/attachment-0001.html>