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

Ehlers, Y.W. (Ydo) ydo.ehlers at ru.nl
Tue Jun 15 11:08:30 UTC 2021


Hugh,


after some time, you start using the Ref. to lookup those things that are new or new to you.
And although I have reread many pages concerning inner & outer tunnels, EPA settings, different ###Balance modes and multiple goodies-files, I did not reread the FarmSize entry.
It is a very straightforward setting and quite self-explanatory, so it didn't even occur to me, unfortunately.

As I was pointed out, the (very small) entry in the ref cautions that it cannot be used with EAP protocols.
This even amounts to 30% of the total entry, so it's hard to overlook, but still, I did....


So, back to the drawing board for me.
And a personal reminder to always check everything involved, how insignificant it may seem.....


Thanks!

Ydo
    

--
Ydo Ehlers | IT Beheerder | ICT Service Center | Radboud Universiteit | Postbus 9102, 6500 HC Nijmegen | (024) 361 78 94 |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.

________________________________________
Van: Hugh Irvine <hugh at irvine.com.au>
Verzonden: dinsdag 15 juni 2021 00:36
Aan: Ehlers, Y.W. (Ydo)
CC: radiator at lists.open.com.au
Onderwerp: Re: [RADIATOR] Using a single instance Radiator with FarmSize >1 for EAP sessions ?

Hello Ydo -

Your assumption around Farmsize and different children receiving parts of the same EAP sequence is correct - this will definitely fail as you describe.

As you suspect, you need multiple Radiator instances on different ports behind a single front-end with EAPBALANCE.

regards

Hugh


> On 14 Jun 2021, at 19:40, Ehlers, Y.W. (Ydo) <ydo.ehlers at ru.nl> wrote:
>
> 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 |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.
> _______________________________________________
> radiator mailing list
> radiator at lists.open.com.au
> https://urldefense.com/v3/__https://lists.open.com.au/mailman/listinfo/radiator__;!!HJOPV4FYYWzcc1jazlU!vifvZ8WCRC5Nn1m5S_KcqfsrOK_KR42pTptFSen2V87YLq-mvQxPNwaNxuVckN4$



More information about the radiator mailing list