EAP proxing with client-balance

[Alexander Clouter]

Hi,

Being part of the 'eduroam' clan we have a lot of EAP traffic proxying 
about the place, even more so being part of the 'University Triangle' in 
London so those peskey students and staff mooch where ever they can.

My setup is generally:
----
home_server_pool eduroam {
        #type           = fail-over           <-- works
        #type           = client-balance      <-- grumbles
        #type           = client-port-balance <-- grumbles
        type            = keyed-balance       <-- grumbles

        home_server     = jrs.0
        home_server     = jrs.1
        home_server     = jrs.2
}
----

The proxy topology in eduroam (incase you do not know) is:
  [us x 2] ---------- [ .ja.net proxies x 3 ] ---------- [them x 2]

<ramble>
I used 'keyed-balance' as 'client-balance'/'client-port-balance' load 
balance terribly when your NAS's use the same source port and most of 
our traffic comes from the same IP (the single infernal WLC 4400 we 
have).

This however is not important, as I only started to use 'keyed-balance' 
about an hour ago.

I noticed after the summer FreeRADIUS overhaul I am finishing off that a 
number of proxied requests to particular realms failed for no reason.  
Speaking to my counterparts at the other universities they could see 
nothing wrong in their *FreeRADIUS* installations.  Because I have a 
general knowledge of whats going on in the nearby universities I know 
there are some filthy MS IAS installations about and pretty quickly 
noticed queries to these places were working fine whilst request to my 
FreeRADIUS buddies did not.
</ramble>

Looking closer at the detail logs I saw that mid-EAP conversation the 
packets started to get proxied to different national proxies which 
resulted (expectedly) with a Access-Reject; also explaining why my 
counterparts never saw an inner authentication.

Looks like MS IAS does not really care where the proxied packets come 
from, it only key's on Proxy-State (I'm guessing here); FreeRADIUS being 
a lot more picky...which is just what I like :)  With this in mind I 
moved to 'fail-over' and everything started working.  Alas I cannot 
leave it on 'fail-over' otherwise Alan Buxey gets grumbly.

<ramble>
I figured out how to enable super verbosity to get at those RDEBUG3's in 
realms.c:home_server_ldb() and saw (when using anything other than 
'fail-over'):
----
[first packet]
PROXY jrs 2.0 jrs 0.0
PROXY jrs 2.0 jrs 1.0

[a latter EAP packet had something like]
PROXY jrs 2.0 jrs 0.0
PROXY jrs 1.0 jrs 0.0
----

I think this was a red herring for me, but it got me to look more closer 
at the realms.c code.
</ramble>

The conclusion, we should not be paying any attention to 
'currently_outstanding' or 'fr_rand()' when there is EAP traffic; I 
decided to add the clause !HOME_POOL_LOAD_BALANCE; things now work.

What do you think of the following patch, I think there is sound 
reasoning behind it, however of course I am just a network monkey?

Cheers

-- 
Alexander Clouter
.sigmonster says: There is no grief which time does not lessen and soften.

diff --git a/src/main/realms.c b/src/main/realms.c
index a0cb796..71640d0 100644
--- a/src/main/realms.c
+++ b/src/main/realms.c
@@ -1938,8 +1938,12 @@ home_server *home_server_ldb(const char *realmname,
 
 		/*
 		 *	We've found the first "live" one.  Use that.
+		 *	The !HOME_POOL_LOAD_BALANCE clause is for the EAP
+		 *	case when we want to do CLIENT/KEY based balancing
+		 *	and avoid inconsistent proxying
 		 */
-		if (pool->type == HOME_POOL_FAIL_OVER) {
+		if (pool->type == HOME_POOL_FAIL_OVER
+				|| pool->type != HOME_POOL_LOAD_BALANCE) {
 			found = home;
 			break;
 		}