[RADIATOR] Is StatusServer broken in 4.19 and latest patches?

Tue Aug 8 15:08:11 UTC 2017

Hi Heikki,

some hours of debugging and testing later:

Radiator 4.19 is now running together with the german NREN upstream 
radsecproxy, but I don't know what went wrong yesterday, sic!

Yesterday I see the following lines in the debug file:

> Mon Aug  7 16:14:02 2017 030094: DEBUG: Radius::ServerRADSEC 
> FROM-DFN-PROXY setting TLS protocols to: TLSv1.2
> Mon Aug  7 16:14:02 2017 030455: DEBUG: Radius::ServerRADSEC 
> FROM-DFN-PROXY setting TLS_Ciphers to: DEFAULT:!EXPORT:!LOW
and then the output stopped until I switched back to 4.17 this morning.

Today, after a lot of local tests and well prepared to switch back, I 
started again 4.19 and the debug output looks now OK:
>
> Tue Aug  8 16:08:53 2017 919196: DEBUG: Radius::ServerRADSEC 
> FROM-DFN-PROXY setting TLS protocols to: TLSv1.2
> Tue Aug  8 16:08:53 2017 919756: DEBUG: Radius::ServerRADSEC 
> FROM-DFN-PROXY setting TLS_Ciphers to: DEFAULT:!EXPORT:!LOW
> Tue Aug  8 16:09:48 2017 760686: DEBUG: StreamServer: New connection 
> from 193.174.XX.YY:43818
> Tue Aug  8 16:09:48 2017 761077: DEBUG: Stream connected to 
> 193.174.XX.YY (193.174.XX.YY:43818)
> Tue Aug  8 16:09:48 2017 761305: DEBUG: StreamTLS sessionInit for 
> 193.174.XX.YY
> Tue Aug  8 16:09:48 2017 761870: DEBUG: StreamTLS SSL_accept result: 
> -1, 2, 8720
> Tue Aug  8 16:09:48 2017 762140: DEBUG: StreamTLS Server Started for 
> 193.174.XX.YY (193.174.XX.YY:43818)
> Tue Aug  8 16:09:48 2017 762303: DEBUG: New StreamServer Connection 
> created for 193.174.XX.YY:43818
> Tue Aug  8 16:09:48 2017 764352: DEBUG: StreamTLS SSL_accept result: 
> -1, 2, 8576
> Tue Aug  8 16:09:48 2017 777113: DEBUG: StreamServer: New connection 
> from 193.174.XX.YY:56619
> Tue Aug  8 16:09:48 2017 777344: DEBUG: Stream connected to 
> 193.174.XX.YY (193.174.XX.YY:56619)
> Tue Aug  8 16:09:48 2017 777540: DEBUG: StreamTLS sessionInit for 
> 193.174.XX.YY
> Tue Aug  8 16:09:48 2017 778054: DEBUG: StreamTLS SSL_accept result: 
> -1, 2, 8720
> Tue Aug  8 16:09:48 2017 778269: DEBUG: StreamTLS Server Started for 
> 193.174.XX.YY (193.174.XX.YY:56619)
> Tue Aug  8 16:09:48 2017 778434: DEBUG: New StreamServer Connection 
> created for 193.174.XX.YY:56619
> Tue Aug  8 16:09:48 2017 779349: DEBUG: StreamTLS SSL_accept result: 
> -1, 2, 8576
> Tue Aug  8 16:09:48 2017 784983: DEBUG: verifyFn start, hostname 
> 193.174.XX.YY
> Tue Aug  8 16:09:48 2017 785155: DEBUG: Verifying certificate with 
> Subject '...RADIUSY' presented by peer 193.174.XX.YY
> Tue Aug  8 16:09:48 2017 785326: DEBUG: Checking subjectAltName type 
> 2, value RADIUSY against 193.174.XX.YY
> Tue Aug  8 16:09:48 2017 785500: DEBUG: Certificate Subject matches 
> TLS_ExpectedPeerName
> Tue Aug  8 16:09:48 2017 804628: DEBUG: StreamTLS SSL_accept result: 
> -1, 2, 8608
> Tue Aug  8 16:09:48 2017 805828: DEBUG: StreamTLS SSL_accept result: 
> 1, 0, 3
> Tue Aug  8 16:09:48 2017 807842: DEBUG: verifyFn start, hostname 
> 193.174.XX.YY
> Tue Aug  8 16:09:48 2017 808009: DEBUG: Verifying certificate with 
> Subject '...RADIUSX' presented by peer 193.174.XX.YY
> Tue Aug  8 16:09:48 2017 808180: DEBUG: Checking subjectAltName type 
> 2, value RADIUSX against 193.174.XX.YY
> Tue Aug  8 16:09:48 2017 808339: DEBUG: Certificate Subject matches 
> TLS_ExpectedPeerName
> Tue Aug  8 16:09:48 2017 827839: DEBUG: StreamTLS SSL_accept result: 
> -1, 2, 8608
> Tue Aug  8 16:09:48 2017 828973: DEBUG: StreamTLS SSL_accept result: 
> 1, 0, 3

Am 08.08.2017 um 12:14 schrieb Heikki Vatiainen:
> With 4.18 and later there will also be Message-Authenticator in the 
> reply. This should be fine if the receiver respects RFC 5597 which 
> allows Reply-Message and Message-Authenticator in Access-Accepts.

OK, this stopped my local Status-Server checks since my script blamed 
that there is an Attribute other than a Reply-Message, yeah, it was the 
added Message-Authenticator, that was easy, it was just Murphys law, 
that both Status-Server checks stalled, arrgh.

Now it looks fine, but please don't ask me what stopped the local NREN 
radsecproxies to talk to me after the restart yesterday.

Sorry, Heikki and thanks again

    Charly

PS: I used one Radiator process in my tests today to talk between AuthBy 
RADSEC and Server RADSEC, here is the cfg snippet:

> #
> BindAddress     127.0.0.1
> #
> #  different ports to production server
> AuthPort        21812
> AcctPort        21813
>
> Trace           4
> Foreground
> LogStdout
>
> ############## NREN Proxy incoming tests ###############################
> #
>
> <ServerRADSEC>
>     Identifier          MY-RADSEC-SERVER
>     Port                22083
>     Secret              radsec
>
>     TLS_Protocols           TLSv1.2
>     TLS_CAFile              FOO.pem
>     TLS_CertificateFile     BAR.pem
>     TLS_PrivateKeyFile      BAZ.key
>     TLS_CertificateType     PEM
>
> </ServerRADSEC>
>
> <AuthBy RADSEC>
>     Identifier          TEST-MY-RADSEC-SERVER
>     Port                22083
>     Secret              radsec
>
>     UseStatusServerForFailureDetect
>     KeepaliveTimeout        3
>
>     LocalAddress            127.0.0.1
>     Host                    127.0.0.1
>
>     TLS_Protocols           TLSv1.2
>     TLS_CAFile              FOO.pem
>     TLS_ExpectedPeerName    CN=.*\.my-domain\.de
>
>     TLS_CertificateType     PEM
>     TLS_CertificateFile     BAR.pem
>     TLS_PrivateKeyFile      BAZ.key
>
> </AuthBy>
>
> ############## AuthBy modules ###########################################
> #
>
> <Client 127.0.0.1>
>     Identifier          SERVICE_CHECK
>     Secret              mysecret
> </Client>

-- 
Karl Gaissmaier
Universität Ulm
kiz, Kommunikations und Informationszentrum
89069 Ulm
Tel.: 49(0)731/50-22499
Fax : 49(0)731/50-12-22499