[RADIATOR] Radiator and radsecproxy, status-server and failover algo, one step forward

Karl Gaissmaier karl.gaissmaier at uni-ulm.de
Sun Jul 14 10:28:19 CDT 2013


Hi radiator team,

now I proved my suspicion, that the upstream radsecproxy is stripping
the radiator proxy-state, at least in status-server requests.

I used monkey patching in AuthBy RADSEC, just quick and dirty
to get the result (you know, it's sunday):

> Sun Jul 14 16:56:43 2013 009313: DEBUG: Packet dump:
> *** Sending request to RadSec radius2.dfn.de:2083 ....
> Code:       Status-Server
> Identifier: 5
> Authentic:  4<160><179><224><193><233><154><132>+<190>2O<227>f<205>&
> Attributes:
>         Message-Authenticator = <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0>
>         Proxy-State = OSC-Extended-Id=5
>
> Sun Jul 14 16:56:43 2013 014566: DEBUG: ############### UULM DUMP##########
> *** Unmatched Ext-Id in Proxy-State for reply in AuthRADSEC from radius2.dfn.de:2083....
> Code:       Access-Accept
> Identifier: 5
> Authentic:  <247><230>&<26><254><245><<134>C<128><219>>p<216><223>I
> Attributes:
>
> Sun Jul 14 16:56:51 2013 115473: DEBUG: Packet dump:
> *** Sending request to RadSec radius1.dfn.de:2083 ....
> Code:       Status-Server
> Identifier: 6
> Authentic:  0<217><255><198><172>F<23><213><140><155>2<162>f1{<189>
> Attributes:
>         Message-Authenticator = <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0>
>         Proxy-State = OSC-Extended-Id=6
>
> Sun Jul 14 16:56:51 2013 138708: DEBUG: ############### UULM DUMP##########
> *** Unmatched Ext-Id in Proxy-State for reply in AuthRADSEC from radius1.dfn.de:2083....
> Code:       Access-Accept
> Identifier: 6
> Authentic:  <233>;<136>k<187><9>s#<200>v<232><208><137><150>Wv
> Attributes:
>
> Sun Jul 14 16:56:53 2013 210994: INFO: AuthRADSEC: No reply from radius2.dfn.de:2083 for Status-Server request ()

Now it's clear, that failover between radsecproxy (used at dfn.de) and 
Radiator with status-server keepalives could not work. It took me a long
time and I had to dig into the code, since I could not establish
debugging for returned packets in AuthBy RADSEC in production systems
and TLS encryption is unbreakable for me, I'm not the NSA and not
working for PRISM, sigh.

Question: Do you have a working test setup between radsecproxy and 
Radiator for 'UseStatusServerForFailureDetect'?

Can you send me your radsecproxy config and tell me the radsecproxy
version number. I'll will send it to DFN to recheck their config.

Worse, it seems that buggy clients with unroutable @Realms trigger
answers with proxy-state stripped. So I get NoreplyTimeouts for
any buggy client request and my upstream connections break away.

Seems that all german @Realms in eduroam using Radiator have the same
problem, because all of them use the same upstream radsecproxy at DFN,
sigh.

Best Regards
    Charly

-- 
Karl Gaissmaier
Universität Ulm / Germany


More information about the radiator mailing list