[RADIATOR] AuthDNSROAM DNS SRV Lookup Failure

[Frank Danielson]

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/20170317/31d52a0a/attachment-0001.html>