Request is supposed to be proxied to Realm SOMEREALM. Not doing EAP.

[Axel Luttgens]

Le 9 sept. 2014 à 15:14, Alan DeKok a écrit :

> Axel Luttgens wrote:
>> [...]
>> Is this the behavior to be expected?
> 
>  Yes.  EAP uses multiple packet exchanges.

In fact, I wasn't surprised by those roundtrips, but by the hardcoded behavior of the eap module: to return a noop in that precise case.
After all, it has done "something", by recognizing the request as an EAP one but then taking the decision to not interfere with a subsequent proxy operation; in some sense, it has taken over the request.
I was thus wondering whether a noop was the most appropriate return code; on the other hand, I had a doubt, because I could also have induced it myself, by some misconfiguration.

But that noop return code is thus expected behavior.
And you have even anticipated some subsequent questions I intended to ask. :-)


>  Put all of the DB lookups into the inner-tunnel virtual server.  

Wow, this is indeed a nice way to handle the problem for an EAP-only context!
Wondering when I'll finally get sufficiently acquainted with FR for being able to devise such things myself... :-(


> If you need to use non-EAP authentication methods, you can protect them
> with an "if" condition:
> 
> 	if (!EAP-Message) {
> 		# complex DB stuff here
> 	}

Unfortunately, yes, I'll need non-EAP methods as well.

Again, that test based on the absence of an EAP-Message attribute is representative of that kind of simple criterion I am too often looking for...

Incidentally, may that "# complex DB stuff here" just be an invocation of the sql module? As in:

	if (!EAP-Message) {
		sql
	}

It seems to work, but aren't there some side-effects to be expected?

Finally, there's the problem of logging.
I need to keep some trace of access requests, but wouldn't be really happy to have 10 lines written to the log for each connection attempt...
Which kind of criterion, if any, could be easily used for writing one line per connection only?

Many thanks,
Axel