terminating EAP tunnels, proxy and realms
Hi all, we're using FreeRadius 1.1.6 to give access to our WLAN with EAP-TTLS. Worked great so far. No we want to participate in inter University roaming (eduroam) and thus have to proxy some requests a parent server. Everything works great except regarding the outer identity. If it's just "anonymous" everything is ok, but if it's "anonymous@<somerealm>" and <somerealm> is configured in proxy.conf the EAP-Request ist proxied instead of terminated. This is correct by configuration but not wanted. Is there a way to terminate the EAP regardless of the outer identity? Here's an example: User-Name = "anonymous@tu-darmstadt.de" Calling-Station-Id = "00-18-DE-B5-3A-E2" ... EAP-Message = 0x0201001e01616e6f6e796d6f75734074752d6461726d73746164742e 6465 Message-Authenticator = 0x7a211176339c3e2ee9f7a0fe56864b2a ... rlm_realm: Looking up realm "tu-darmstadt.de" for User-Name = "anonymous@tu-darmstadt.de" rlm_realm: Found realm "tu-darmstadt.de" rlm_realm: Adding Stripped-User-Name = "anonymous" rlm_realm: Proxying request from user anonymous to realm tu-darmstadt.de rlm_realm: Adding Realm = "tu-darmstadt.de" rlm_realm: Preparing to proxy authentication request to realm "tu-darmstadt. de" modcall[authorize]: module "suffix" returns updated for request 6 rlm_eap: Request is supposed to be proxied to Realm tu-darmstadt.de. Not doing EAP. modcall[authorize]: module "eap" returns noop for request 6 ... How can I bypass proxy authentication for EAP-Messages? This is the setup in users: ... # matches request without any realm (local) DEFAULT FreeRADIUS-Proxied-To == 127.0.0.1, Realm !* "NULL", Proxy-To-Realm := MyRealm User-Name = `%{User-Name}`,Fall-Through = Yes # matches requests going explicitly to tu-darmstadt.de (local) DEFAULT FreeRADIUS-Proxied-To == 127.0.0.1, Realm == "tu-darmstadt.de", Proxy-To-Realm := MyRealm User-Name = `%{User-Name}`,Fall-Through = Yes # matches requests going parent radius DEFAULT FreeRADIUS-Proxied-To == 127.0.0.1, Realm == DEFAULT, Proxy-To-Realm := Parent User-Name = `%{User-Name}`,Fall-Through = Yes ... Thanks a lot, -Andreas -- Andreas Liebe/Darmstadt University of Technology/+49 6151 16-3150/3050(FAX)
Hello Andreas,
No we want to participate in inter University roaming (eduroam) and thus have to proxy some requests a parent server. Everything works great except regarding the outer identity.
If it's just "anonymous" everything is ok, but if it's "anonymous@<somerealm>" and <somerealm> is configured in proxy.conf the EAP-Request ist proxied instead of terminated. This is correct by configuration but not wanted.
Is there a way to terminate the EAP regardless of the outer identity?
why do you want this. The EAP Tunnel should terminate on the last RADIUS where the user belongs. On your RADIUS only the EAP-Tunnels for your users should be terminating. Read http://www.dfn.de/content/fileadmin/1Dienstleistungen/GWIN/sonstiges/Konfigu... it is for DFN-Roaming, but it is the same as EDUROAM. regards Helmut
Hi Helmut,
Is there a way to terminate the EAP regardless of the outer identity?
why do you want this. The EAP Tunnel should terminate on the last RADIUS where the user belongs. On your RADIUS only the EAP-Tunnels for your users should be terminating.
I do not want to terminate the EAP tunnels for the foreign realms, but I have to terminate the local one (@tu-darmstadt.de and NULL) as I have to forward the requests to a set of internal radius servers not capable of speaking EAP. Any idea how to do this? Thanks, -Andreas
Andreas Liebe wrote:
Hi Helmut,
Is there a way to terminate the EAP regardless of the outer identity?
why do you want this. The EAP Tunnel should terminate on the last RADIUS where the user belongs. On your RADIUS only the EAP-Tunnels for your users should be terminating.
I do not want to terminate the EAP tunnels for the foreign realms, but I have to terminate the local one (@tu-darmstadt.de and NULL) as I have to forward the requests to a set of internal radius servers not capable of speaking EAP.
Any idea how to do this?
Simple answer ... you can't .
Andreas Liebe wrote:
I do not want to terminate the EAP tunnels for the foreign realms, but I have to terminate the local one (@tu-darmstadt.de and NULL) as I have to forward the requests to a set of internal radius servers not capable of speaking EAP.
Set Proxy-To-Realm := LOCAL for the realms you want to terminate locally. Make sure that this is done before the "eap" module is run in the "authorise" section. Then, put the following in the "users" file to proxy the inner request to another realm: DEFAULT FreeRADIUS-Proxied-To == 127.0.0.1, Proxy-To-Realm = oldservers 2.0.0 should have a much more fine-grained way to control this. Alan DeKok.
Alan DeKok wrote:
Andreas Liebe wrote:
I do not want to terminate the EAP tunnels for the foreign realms, but I have to terminate the local one (@tu-darmstadt.de and NULL) as I have to forward the requests to a set of internal radius servers not capable of speaking EAP.
Set Proxy-To-Realm := LOCAL for the realms you want to terminate locally. Make sure that this is done before the "eap" module is run in the "authorise" section.
Then, put the following in the "users" file to proxy the inner request to another realm:
DEFAULT FreeRADIUS-Proxied-To == 127.0.0.1, Proxy-To-Realm = oldservers
2.0.0 should have a much more fine-grained way to control this.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
So the eap module extracts the attributes encoded in the eap message ? I can see that working for EAP GTC and EAP PAP but not MschapV2 ?
Arran Cudbard-Bell wrote:
So the eap module extracts the attributes encoded in the eap message ? I can see that working for EAP GTC and EAP PAP but not MschapV2 ?
It works for GTC, PAP, and MS-CHAPv2. The server can terminate PEAP, and proxy the inner EAP-MSCHAPv2 session as plain MS-CHAPv2. With the new virtual server support, it's now possible to have the inner tunnel session run through it's own virtual server, independent of the outer tunnel session. Just set "Virtual-Server = foo" via "update control", and the inner tunnel session will be run through "server foo". 30 lines of code changed: incredible new flexibility. Alan DeKok.
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
So the eap module extracts the attributes encoded in the eap message ? I can see that working for EAP GTC and EAP PAP but not MschapV2 ?
It works for GTC, PAP, and MS-CHAPv2. The server can terminate PEAP, and proxy the inner EAP-MSCHAPv2 session as plain MS-CHAPv2.
Ah cool, thats actually really useful . Does only one packet need to be proxied per EAP authentication ?
With the new virtual server support, it's now possible to have the inner tunnel session run through it's own virtual server, independent of the outer tunnel session. Just set "Virtual-Server = foo" via "update control", and the inner tunnel session will be run through "server foo".
30 lines of code changed: incredible new flexibility.
Yes look forward to trying it ;) Built on failover partner and same result , so deffinately not a hardware error, points to either the architecture or the compiler...
Arran Cudbard-Bell wrote: ...
It works for GTC, PAP, and MS-CHAPv2. The server can terminate PEAP, and proxy the inner EAP-MSCHAPv2 session as plain MS-CHAPv2.
Ah cool, thats actually really useful . Does only one packet need to be proxied per EAP authentication ?
Yes. Alan DeKok.
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
So the eap module extracts the attributes encoded in the eap message ? I can see that working for EAP GTC and EAP PAP but not MschapV2 ?
It works for GTC, PAP, and MS-CHAPv2. The server can terminate PEAP, and proxy the inner EAP-MSCHAPv2 session as plain MS-CHAPv2.
With the new virtual server support, it's now possible to have the inner tunnel session run through it's own virtual server, independent of the outer tunnel session. Just set "Virtual-Server = foo" via "update control", and the inner tunnel session will be run through "server foo".
30 lines of code changed: incredible new flexibility.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Yes :) I was just looking at the protocol filters, they look interesting and will make a lot of people on the list happy ... Just finished building on my 32bit machine and .. ++? if ("%{NAS-IP-Address}" == "127.0.0.1") -> TRUE ++- entering if ("%{NAS-IP-Address}" == "127.0.0.1") expand: %{Packet-Src-IP-Address} -> 139.184.14.161 Segmentation fault *sigh* bt radius_update_attrlist (request=0x80280840, cs=0x8004c798, input_vps=0x8016bc60, name=0x8004c7f0 "request") at evaluate.c:854 854 if ((from_list[i]->operator == T_OP_EQ) || (gdb) bt #0 radius_update_attrlist (request=0x80280840, cs=0x8004c798, input_vps=0x8016bc60, name=0x8004c7f0 "request") at evaluate.c:854 #1 0x80014afa in modcall (component=1, c=0x8016bdb0, request=0x80280840) at modcall.c:396 #2 0x8001141a in indexed_modcall (space=<value optimized out>, comp=1, idx=0, request=0x80280840) at modules.c:413 #3 0x80006c30 in rad_authenticate (request=0x80280840) at auth.c:540 #4 0x8001f096 in radius_handle_request (request=0x80280840, fun=0x80006b10 <rad_authenticate>) at event.c:2174 #5 0x80019fe6 in thread_pool_addrequest (request=0x80280840, fun=0x80006b10 <rad_authenticate>) at threads.c:836 #6 0x80015c5f in main (argc=2, argv=0xbfb42524) at radiusd.c:716 Same as on the apples !!! Are you compiling with GCC ? If you are compiling on GCC with the default configuration options ... then it can only be my config ... it's the only constant... and a bug in a source *somewhere*, just in a very obscure place. :\ Would you like the core dumps from the 32bit machine ? --- Arran
Arran Cudbard-Bell wrote:
I was just looking at the protocol filters, they look interesting and will make a lot of people on the list happy ...
rlm_protocol_filter? I put that in 2 years ago, and I didn't think anyone was using it...
Just finished building on my 32bit machine and ..
++? if ("%{NAS-IP-Address}" == "127.0.0.1") -> TRUE ++- entering if ("%{NAS-IP-Address}" == "127.0.0.1") expand: %{Packet-Src-IP-Address} -> 139.184.14.161 Segmentation fault
Fixed, thanks. Alan DeKok.
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
I was just looking at the protocol filters, they look interesting and will make a lot of people on the list happy ...
rlm_protocol_filter? I put that in 2 years ago, and I didn't think anyone was using it...
Well it's a little obscure, it's not included in the default radiusd.conf file ? I guess if it's just working off EAP-Type then it's functionality can be replicated in unlang ... I've just seen a few requests with people saying how can I limit EAP to xyz. Can you clear something up for me with inner/outer identity. The outer identity is in the User-Name attribute , it's a standard RADIUS attribute... Inner identity is encoded in the EAP message, and is pulled out by the EAP module prior to internal proxying and set as the User-Name attribute (which should overwrite the User-Name attribute in the request) ? And it's standard practice to leave the outer identity as anonymous, as the only communication between the NAS and the Supplicant is EAP based when using EAPOL, and so the NAS would have to understand EAP to be able to extract the User-Name string and write it into the Access-Request packet ? So although the NAS must send an EAP-Identity-Request when the client connects it's not required to understand the EAP-Identity-Response ? Thanks, Arran
Can you clear something up for me with inner/outer identity. The outer identity is in the User-Name attribute , it's a standard RADIUS
yep
attribute... Inner identity is encoded in the EAP message, and is pulled
yep
out by the EAP module prior to internal proxying and set as the User-Name attribute (which should overwrite the User-Name attribute in the request) ?
yep
And it's standard practice to leave the outer identity as anonymous, as
varies. some supplicants just set outer==inner e.g. winXP.
the only communication between the NAS and the Supplicant is EAP based when using EAPOL, and so the NAS would have to understand EAP to be able to extract the User-Name string and write it into the Access-Request packet ?
In fact, since the inner identity is normally sent in an encrypted EAP flow, the NAS would have to break the encryption to access it. Basically the NAS can't see the inner User-Name
So although the NAS must send an EAP-Identity-Request when the client connects it's not required to understand the EAP-Identity-Response ?
Correct. One final thing to add - the EAP standard specifies that in the final Access-Accept, the radius server (which DOES know the inner User-Name) should copy it to a User-Name attribute in the Access-Accept - so, the radius server tells the NAS what the user is. This is *slightly* complicated because by default, FreeRadius proxies the inner EAP to itself, so when it sends that Access-Accept it sends it to itself; and you need to "use_tunneled_reply" to actually get that back to the NAS. That is: NAS: Access-Request User-Name=anonymous@bar.com SRV: Access-Challenge NAS: Access-Request User-Name=anonymous@bar.com SRV: Access-Challenge NAS: Access-Request SRV: <ok, I've got all the EAP - proxy to myself> SRV(outer): Access-Request User-Name=foo@bar.com SRV(inner): Access-Accept User-Name=foo@bar.com SRV: <ok, copy tunneled reply to outer and...> SRV: Access-Accept User-Name=foo@bar.com Hope that helps.
Alan,
I do not want to terminate the EAP tunnels for the foreign realms, but I have to terminate the local one (@tu-darmstadt.de and NULL) as I have to forward the requests to a set of internal radius servers not capable of speaking EAP.
Set Proxy-To-Realm := LOCAL for the realms you want to terminate locally. Make sure that this is done before the "eap" module is run in the "authorise" section.
Then, put the following in the "users" file to proxy the inner request to another realm:
DEFAULT FreeRADIUS-Proxied-To == 127.0.0.1, Proxy-To-Realm = oldservers
I've already had these rules in user. The final hint was to set authhost = LOCAL in proxy.conf. Now it works as expected. Thanks a lot to all who helped, especially to Alan of course! -Andreas -- Andreas Liebe/Darmstadt University of Technology/+49 6151 16-3150/3050(FAX)
participants (5)
-
Alan DeKok -
Andreas Liebe -
Arran Cudbard-Bell -
Helmut Tröbs -
Phil Mayers