[RADIATOR] Using a single instance Radiator with FarmSize >1 for EAP sessions ?

[Ehlers, Y.W. (Ydo)]

Hi,


we have been running a multi-instance radiator setup for Eduroam for a long time, without many fundamental changes over the past years.
As the hardware has been written off and both hardware and OS will soon be unsupported, it was time to build a new setup.

So new hardware, new OS and the latest version of radiator.
It seemed to me a golden opportunity to also review the Radiator configuration and try to simplify it wherever possible.
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?

The old setup on a single server was as follows:
* 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

* There are 4 very basic backend instances with a handler for the inner and outer tunnels and a LDAP authentication backend

* 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.


The server itself is oversized for this setup and the load generated and barely broke a sweat on busy moments.
With newer hardware, I would like to get rid of the many instances and configuration files for each.
So I broke everything down to the seperate components and Lego'd it back together in a single instance with a farmsize of 4.

Everything seemed in order: all regular handlers work perfectly, rejecting realm-less requests, proxying other realms, etcetera.
However, EAP sessions for our own realm did not always work and sometimes broke up with the following error:

     INFO: Access rejected for ######@ru.nl: EAP Response type 21 in unexpected state.
          NAS did RADIUS server failover for an ongoing EAP authentication?



This does happen most, but not all of the times and it completely disappears when using a farmsize of 0.
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.


So, my first question: is that indeed what is happening?
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?
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.




The most important settings of my testing environment:


[...]


FarmSize                    4
FarmChildHook               file:"/etc/radiator/hooks/farmchild.pl"

DupCache                    shared
EAP_UseState


[...]

# Generic EAP-settings

<AuthBy FILE>
   Identifier                  EAP4WIFI
   EAPType                     TTLS,PEAP
   EAPTLS_CertificateType      PEM
   EAPTLS_CAFile               /etc/pki/tls/certs/ca-bundle.crt
   EAPTLS_CertificateChainFile /etc/radiator/cert/#####.pem
   EAPTLS_PrivateKeyFile       /etc/radiator/cert/#####.key
   EAPTLS_MaxFragmentSize      1300
   EAPTLS_TraceState
   EAPTLS_Protocols            TLSv1.3 TLSv1.2
   EAPTLS_Ciphers              DEFAULT:!EXPORT:!LOW:!RC4:!MD5:!SSLv2:!DES:!NULL:TLSv1.2:TLSv1.3
   EAPTLS_DHFile               /etc/radiator/cert/ffdhe2048
   EAPTLS_ECDH_Curve           prime256v1
   AutoMPPEKeys
</AuthBy>


[...]


# INNER TUNNELS

<Handler TunnelledByTTLS=1>
   RewriteUsername             s/^([^@]+).*/$1/
   <AuthBy LDAP2>
      Version                  3
      UsernameMatchesWithoutRealm
      HoldServerConnection
      Host                     ######
      Port                     636
      UseSSL
      SSLCAFile                /etc/pki/tls/certs/ca-bundle.crt
      AuthDN                   cn=######,ou=######,o=######,c=######
      AuthPassword            ######
      BaseDN                   o######,c######
      Scope                    subtree
      UsernameAttr             uid
      SearchFilter             (&(uid=%1))
      EAPType                  MSCHAP-V2
      NoDefault
   </AuthBy>
   PostProcessingHook          file:"/etc/radiator/hooks/eap_acct_username.pl"
   AuthLog                     tlslog
</Handler>


[...]


# OUTER TUNNEL


<Handler Client-Identifier=####, Realm=/^####\.####$/i>
   PreAuthHook                 sub { ${$_[0]}->add_attr('Category', '#####');}
   AuthBy                      EAP4WIFI

   AddToReply                  Tunnel-Type="VLAN"
   AddToReply                  Tunnel-Medium-Type="802"
   PostProcessingHook          file:"/etc/radiator/hooks/wifi_vlan.pl"
   AuthLog                     authlog
</Handler>

[...]




Everything that doesn't concern our realm is fine and it works with a single child, but not with more childs.
It looks like the EAP/HASH Balance issue,, but I can't use that within this setup without having to build multiple instances again.

So, what am I missing?
Is it just impossible or have I overlooked some settings for this?



With kind regards,



ydo




--
Ydo Ehlers | IT Beheerder | ICT Service Center | Radboud Universiteit | Postbus 9102, 6500 HC Nijmegen | (024) 361 78 94 |www.ru.nl/isc<http://www.ru.nl/isc>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.open.com.au/pipermail/radiator/attachments/20210614/c5c78ed5/attachment.html>