[RADIATOR] AuthRADSEC and radsecproxy are incompatible!

[Ralf Paffrath]

On Jul 17, 2013, at 8:58 AM, Karl Gaissmaier <karl.gaissmaier at uni-ulm.de> wrote:

> Hello,
> 
> Am 15.07.2013 10:07, schrieb Ralf Paffrath:
> ...
>> anyway it's a bit proprietary that Radiator ignores the correct identifier in an Access-Reject packet.
>> 
>> The Identifier is also part of RFC2865:
>> Identifier
>>       The Identifier field is one octet, and aids in matching requests
>>       and replies.  The RADIUS server can detect a duplicate request if
>>       it has the same client source IP address and source UDP port and
>>       Identifier within a short span of time.
> 
> in case of connection oriented RADSEC/TCP proxying, it's problem to
> decide on client addresses and client ports, It's always the same peer
> socket and 8 bits can be very soon to short on a heavy used proxy
> connection.
> 
> RADSEC/TCP or RADIUS/TCP came after RFC-2865, maybe we should make
> an RFC addendum, that Proxy-State MUST ALWAYS be replied, even in
> Status-Server requests.
> 
> Meanwhile we could/should add a config flag in radsecproxy to allow
> this.

Meanwhile you can put a radsecproxy between your Radiator and let radsecproxy to handle all the request.
If the request is local radsecproxy would forward your request to your Radiator. All other requests would be 
upstreamed. If you want to solve your problem with dead realm, voila.
  
> 
> Best Regards
>   Charly
> 
> -- 
> Karl Gaissmaier
> Universität Ulm / Germany

--
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/20130719/68e1f9d3/attachment.bin