Guy Bitansky wrote:

Proxy requests that arrive to “MYREALM\<user_name>” to a custom virtual server that is handles LDAP requests.

I defined the right proxy definitions in the proxy.conf and created the virtual server properly.

That should be straightforward.

The problem is that EAP is not carried out.

In the default server it says: “eap : Request is supposed to be proxied to Realm XXXXXX. Not doing EAP.”.

Because you configured it to proxy the EAP packets to a custom virtual server.

The thing is that when the request arrives at the authorize section of the virtual server, eap is not started again because the request still contains a proxy field and eap module lets it go.

I don't know what that means.

I thought that I could proxy the different incoming requests according to the realm of the user to the correct server, weather a virtual internal server or an external proxy server. This works pretty good except the eap part.

If you want a virtual server to handle EAP authentication, you should list "eap" in that virtual server. Why are you proxying a realm to a different virtual server, and then expecting the default one to authenticate the user? It doesn't make any sense. I'll also note you've been careful to *not* post a sample debug output. I think you've misunderstood what a virtual server is. It's not a a database. You can't say "virtual server X does LDAP". That virtual server has to be a *complete* RADIUS server. You need to configure the authorize section, authenticate, etc. I think what you want to do is this: - copy "sites-available/default" to "sites-enabled/realm1" - copy "sites-available/default" to "sites-enabled/realm2" - copy "sites-available/default" to "sites-enabled/realm3" ... Edit each of the above files to look up users in LDAP, AD, etc. as needed. - create a *new* raddb/sites-enabled/default. All it should do is proxy requests to the other virtual servers. Alan DeKok.