(RADIATOR) Load balancing radiator part 2

[Hugh Irvine]

Hello Alex -

As you have discovered, you can loadbalance simple radius requests,  
because they are single packet send, single packet response.

However, you have also discovered that you cannot do the same thing  
with EAP, due to the multiple exchanges of radius requests required  
for EAP. Therefore you cannot use loadbalancing for EAP.

regards

Hugh


On 27 Apr 2006, at 02:43, Alex Sharaz wrote:

> Chaps,
>
> A while back I sent a mail message to the list about load balancing
> auth/accounting to multiple radiator servers via a serverironXL box.
>
> The config at the time had the serveriron performing source address
> translation so all the radiator server saw from a client point of view
> was the ip address of the serveriron.
>
> I've now configured the serveriron not to perform source address
> translation and each radiator server now sees the ip address of the  
> ras
> client.
>
> Well, it sort of works.
>
> Our web caching service is configured to use radius pap auth and that
> works just fine via the assigned virtual ip address for the load
> balancing radius service.
>
> Using a dot1x client (Meetinghouse and the Odyssey, one on a laptop  
> and
> one of a desktop) I can configure a switch to point to each of the  
> real
> servers in succession and eap-ttls /mschapv2 and eap-peap/eap-mschapv2
> both work just fine
>
> However, if I go via the vip assigned to the load balanced service for
> either of the eap-XX methods, you get prompted for a userid and then
> nothing. The clients time out and ask for the userid again a couple of
> times and then give up.
>
> In the radiator logfile, I've got single line entries ( Resuming  
> session
> for Radius:context......)
> that I don't see if I go directly to the real servers.
>
> It only affects the eap type connections. I'm running radiator 3.14  
> with
> a patch set from 07/04/06
>
> Is there anything else I should be configuring at the Radiator end?
> Alex
>
>
> Tue Apr 25 12:38:06 2006: DEBUG: Handling with Radius::AuthFILE:  
> eapAuth
> Tue Apr 25 12:38:06 2006: DEBUG: Handling with EAP: code 2, 9, 25
> Tue Apr 25 12:38:06 2006: DEBUG: Response type 1
> Tue Apr 25 12:38:06 2006: DEBUG: Resuming session for
> Radius::Context=HASH(0x9d9147c)
>
> Tue Apr 25 12:38:06 2006: DEBUG: EAP result: 3, EAP TTLS Challenge
> Tue Apr 25 12:38:06 2006: DEBUG: AuthBy FILE result: CHALLENGE, EAP  
> TTLS
> Challenge
> Tue Apr 25 12:38:06 2006: DEBUG: Access challenged for
> anonymous at hull.ac.uk: EAP TTLS Challenge
> Tue Apr 25 12:38:06 2006: DEBUG: Packet dump:
> :********************************************************************* 
> ********************
> To view the terms under which this email is distributed, please go  
> to http://www.hull.ac.uk/legal/email_disclaimer.html
> ********************************************************************** 
> *******************


NB:

Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/ 
radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.


--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.