<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none"><!--P{margin-top:0;margin-bottom:0;} p
        {margin-top:0;
        margin-bottom:0}--></style>
</head>
<body dir="ltr" style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">
<p>Hi,<br>
<br>
<br>
we have been running a multi-instance radiator setup for Eduroam for a long time, without many fundamental changes over the past years.<br>
As the hardware has been written off and both hardware and OS will soon be unsupported, it was time to build a new setup.</p>
<p>So new hardware, new OS and the latest version of radiator.<br>
It seemed to me a golden opportunity to also review the Radiator configuration and try to simplify it wherever possible.<br>
But now I run into a problem that is somewhat explainable, but on the other hand, is not what I would expect, so I was wondering if anyone else has encountered the same or that maybe my presumptions are incorrect?<br>
<br>
The old setup on a single server was as follows:<br>
* First a front-end Radiator process with a FarmSize 4; this one rejects all wrong accounts and forwards specific realms to another radius server, our own realm to the backend instances and the rest to the national Eduroam h</p>
<p>* There are 4 very basic backend instances with a handler for the inner and outer tunnels and a LDAP authentication backend</p>
<p>* Then there are other instances for special purposes: seperate SSID for a more secure network used for examinations, one several more for specific testing purposes.</p>
<p><br>
</p>
<p>The server itself is oversized for this setup and the load generated and barely broke a sweat on busy moments.<br>
With newer hardware, I would like to get rid of the many instances and configuration files for each.<br>
So I broke everything down to the seperate components and Lego'd it back together in a single instance with a farmsize of 4.<br>
<br>
Everything seemed in order: all regular handlers work perfectly, rejecting realm-less requests, proxying other realms, etcetera.<br>
However, EAP sessions for our own realm did not always work and sometimes broke up with the following error:<br>
</p>
<p>     INFO: Access rejected for ######@ru.nl: EAP Response type 21 in unexpected state. <br>
          NAS did RADIUS server failover for an ongoing EAP authentication?<br>
</p>
<p><br>
</p>
<p><br>
</p>
<p>This does happen most, but not all of the times and it completely disappears when using a farmsize of 0.<br>
So, it seems logical to me that EAP sessions get assigned to different child processes each time which then causes the EAP session to break.<br>
</p>
<p><br>
</p>
<p>So, my first question: is that indeed what is happening?<br>
And the second one:  are  ESP sessions and FarmSize by definition incompatible and do I need to go back to the front-/back-end setup again, or is there something I'm missing?<br>
I've read almost every config in the goodies bag containing EAP and/or FarmSize, but to no avail; everything seams to point to [EAP/HASH] balancing sessions to a different instance or server.</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p>The most important settings of my testing environment:</p>
<p><br>
</p>
<p>[...]</p>
<p><br>
</p>
<p>FarmSize                    4<br>
FarmChildHook               file:"/etc/radiator/hooks/farmchild.pl"<br>
<br>
DupCache                    shared<br>
EAP_UseState<br>
</p>
<p><br>
</p>
<p>[...]</p>
<p><br>
# Generic EAP-settings<br>
</p>
<p><AuthBy FILE><br>
   Identifier                  EAP4WIFI<br>
   EAPType                     TTLS,PEAP<br>
   EAPTLS_CertificateType      PEM<br>
   EAPTLS_CAFile               /etc/pki/tls/certs/ca-bundle.crt<br>
   EAPTLS_CertificateChainFile /etc/radiator/cert/#####.pem<br>
   EAPTLS_PrivateKeyFile       /etc/radiator/cert/#####.key<br>
   EAPTLS_MaxFragmentSize      1300<br>
   EAPTLS_TraceState<br>
   EAPTLS_Protocols            TLSv1.3 TLSv1.2<br>
   EAPTLS_Ciphers              DEFAULT:!EXPORT:!LOW:!RC4:!MD5:!SSLv2:!DES:!NULL:TLSv1.2:TLSv1.3<br>
   EAPTLS_DHFile               /etc/radiator/cert/ffdhe2048<br>
   EAPTLS_ECDH_Curve           prime256v1<br>
   AutoMPPEKeys<br>
</AuthBy></p>
<p><br>
</p>
<p>[...]</p>
<p><br>
</p>
<p># INNER TUNNELS<br>
</p>
<p><Handler TunnelledByTTLS=1><br>
   RewriteUsername             s/^([^@]+).*/$1/<br>
   <AuthBy LDAP2><br>
      Version                  3<br>
      UsernameMatchesWithoutRealm<br>
      HoldServerConnection<br>
      Host                     ######<br>
      Port                     636<br>
      UseSSL<br>
      SSLCAFile                /etc/pki/tls/certs/ca-bundle.crt<br>
      AuthDN                   cn=######,ou=######,o=######,c=######<br>
      AuthPassword            ######<br>
      BaseDN                   o######,c######<br>
      Scope                    subtree<br>
      UsernameAttr             uid<br>
      SearchFilter             (&(uid=%1))<br>
      EAPType                  MSCHAP-V2<br>
      NoDefault<br>
   </AuthBy><br>
   PostProcessingHook          file:"/etc/radiator/hooks/eap_acct_username.pl"<br>
   AuthLog                     tlslog<br>
</Handler><br>
<br>
</p>
[...]
<p><br>
</p>
<p># OUTER TUNNEL</p>
<p><br>
</p>
<p><Handler Client-Identifier=####, Realm=/^####\.####$/i><br>
   PreAuthHook                 sub { ${$_[0]}->add_attr('Category', '#####');}<br>
   AuthBy                      EAP4WIFI<br>
</p>
<p>   AddToReply                  Tunnel-Type="VLAN"<br>
   AddToReply                  Tunnel-Medium-Type="802"<br>
   PostProcessingHook          file:"/etc/radiator/hooks/wifi_vlan.pl"<br>
   AuthLog                     authlog<br>
</Handler><br>
<br>
[...]<br>
<br>
</p>
<p><br>
</p>
<p><br>
</p>
<p>Everything that doesn't concern our realm is fine and it works with a single child, but not with more childs.<br>
It looks like the EAP/HASH Balance issue,, but I can't use that within this setup without having to build multiple instances again.<br>
</p>
<p><br>
So, what am I missing?<br>
Is it just impossible or have I overlooked some settings for this?<br>
</p>
<p><br>
</p>
<p><br>
</p>
<p>With kind regards,<br>
<br>
<br>
<br>
ydo<br>
</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<div id="Signature">
<div name="divtagdefaultwrapper" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:; margin:0">
<span style="background-color:white">-- <br>
<div style="margin-top:14pt; margin-bottom:14pt"><font size="2" face="Calibri,sans-serif"><span style="font-size:11pt">Ydo Ehlers | IT Beheerder | ICT Service Center | Radboud Universiteit | Postbus 9102, 6500 HC Nijmegen | (024) 361 78 94 |</span></font><a href="http://www.ru.nl/isc" target="_blank" id="NoLP"><font size="2" face="Calibri,sans-serif"><span style="font-size:11pt">www.ru.nl/isc</span></font></a><font size="2" face="Calibri,sans-serif"><span style="font-size:11pt">
</span></font></div>
<div style="margin-top:14pt; margin-bottom:14pt"><font size="2" face="Calibri,sans-serif"><span style="font-size:9pt"><i>Dit bericht en elke eventuele bijlage is uitsluitend bestemd voor de geadresseerde(n) en kan vertrouwelijke informatie bevatten. Indien
 u niet de geadresseerde bent mag u dit bericht en de bijlage niet kopiëren of aan derden ter inzage geven of verspreiden. U wordt verzocht de afzender hiervan onmiddellijk op de hoogte te stellen en het bericht te vernietigen.
</i></span></font></div>
</span></div>
</div>
</body>
</html>