eap_ttls not setting 'FreeRADIUS-Proxied-To'

[David Lord]

On 13 Jan 2016, at 12:58 AM, Alan DeKok <aland at deployingradius.com<mailto:aland at deployingradius.com>> wrote:

On Jan 11, 2016, at 11:35 PM, David Lord <d.lord at its.uq.edu.au<mailto:d.lord at its.uq.edu.au>> wrote:
I’m porting our config from v2.2.9 to v3.0.11.

The problem I’m experiencing is that the eap_peap submodule does set FreeRADIUS-Proxied-To, but eap_ttls does not.

I've pushed a fix.

Thanks for that. By the sound of it, we should move away from using it (as is now documented<https://github.com/FreeRADIUS/freeradius-server/commit/d4ad5e71228b788cac76171156a3d5e5034c48cd>, I note ;) ).

In v2, both submodules did. Unfortunately I’m currently relying on this attribute for tunnelling in one server.

 You shouldn't need to do that.  The "inner-tunnel" virtual server handles inner tunnel data.  Nothing else does.  You don't need to key off of FreeRADIUS-Proxied-To.

Time is limited so I’m sticking with the previous architecture, which looks like this (trimmed down):

authorize {
split_user_realm
choose_eduroam_proxy # reject invalid realm, set Proxy-To-Realm to national federation or do nothing so it goes internally
eap_eduroam
if (“%{%{FreeRADIUS-Proxied-To}:-}” == 127.0.0.1) {

 And that is *way* too complicated.  In v3, just do:

if (&FreeRADIUS-Proxied-To == 127.0.0.1) {

 But you still don't need to do that.  Just put the outer policies into the "default" virtual server, and the inner policies into the "inner-tunnel" virtual server.

 That's why I created virtual servers: to split the policies like this.  That's why the default configuration ships with multiple virtual servers.


Okay, I’d love to do that. Would appreciate input on this architecture.

The other branch of this port uses eduroam_inner, eduroam_IDP and eduroam_SP virtual servers, but I’ve been having trouble getting the right attributes forwarded.
In theory IDP is exposed to the national roaming operator and SP is for our campus wifi, and SP forwards auth to IDP or the NRO. Is that sensible?
However, SP needs a &Group derived from LDAP to set the right VLAN attributes, which is queried from _inner and can be passed to IDP via outer.control but is harder to forward to SP. I experimented with a custom attr_filter and didn’t find a reliable way to forward the Group attribute (putting it in a temporary attribute and extracting it in SP seems unstable).
Alternatively, IDP or _inner can set the VLAN attributes off &Group, and strip them if not replying to SP.

It may be worth having just two servers, SP&IDP and inner, and having the SP&IDP server conditionally set VLAN attributes based on the client (one of ours or NRO).

This RADIUS service does more than just eduroam, hence the prefixes.

 Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html