[RADIATOR] Problems with radiator to radsecproxy TLS connections

Ralf Paffrath paffrath at dfn.de
Fri Mar 28 05:28:21 CDT 2014


Hi Elmar,

I'm afraid that this problem has nothing do to with radiator or with different architecture. I've realised that the same problem is between radsecproxy <-> radsecproxy (version 1.6.5 on DEBIAN). It is exactly like you described. 
The only chance to notice this behaviour is to check the status server on BOTH!! side (client and server) in the logfiles. Although netstat tells you that the server port is available and the connection is still established I can't see any status server in my logfiles. So the connection must be down but radsecproxy does not notice this. 
I think the thread who sends out the status server request dies or stops silently and there is no warning or something similar.

I would appreciate any idea, clue.

Ralf
  
On 24 Mar 2014, at 17:10, Elmar Dreher <Elmar.Dreher at uni-konstanz.de> wrote:

> Hello all,
> 
> i am systemadministrator for eduroam at the university of Konstanz.
> We are using radiator and radsecproxy:
> 1. Radiator is hosted in an Application Zone
> 2. Radsecproxy is hosted in a DMZ and connected to the DFN for eduroam purposes
> 3. OS on both environments is Ubuntu 12.04
> 
> The setup is the following:
> 1. All connection (beetween radiator and radsecproxy) are implemented by using TLS
> 2. On radiator the RADSEC implementaion is used to realize TLS connetion from and to radsecproxy
> 3. Radiator an radsecproxy are redundant (2 radiators and 2 radsecproxies) and are connected redundant
> 
> 
> Now the problem:
> Soemtimes it happens that the connection between radsecproxy <-> radiator is broken (experience has shown after 5 to 6 weeks):
> At case of an eduroam Login attempt radsecproxy or radiator is logging that the remote peer isn't available.
> Looking an the network connection with netstat -tapen everythink looks ok.
> 
> Does everbody have the same experience with this architecture or does have an idea or hint what could be the problem or how to solve the problem (we already have a weekly reboot of all radsecproxy and radiator services and everything works fine).
> 
> Many greetings from Konstanz, Elmar Dreher

--
Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
Alexanderplatz 1, D - 10178 Berlin
Tel.: 030 88 42 99 23
Fax: 030 88 42 99 70
http://www.dfn.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4552 bytes
Desc: not available
Url : http://www.open.com.au/pipermail/radiator/attachments/20140328/c354704e/attachment-0001.bin 


More information about the radiator mailing list