On Thu, 24 May 2012, Graeme Hamilton wrote:
Ideally, I'd like a generic default virtual server which would process
all authentications initially, but which would act upon the suffix (e.g.
':eduroam') appended to the Called-Station-Id by our wireless
controllers to proxy the request off to another virtual server dedicated
to that particular function, where further actions specific to that
purpose can be carried out. Reading the comments in proxy.conf suggests
that it's possible to proxy requests containing a particular realm off
to another virtual server, but that such requests cannot subsequently be
proxied again. This would break Eduroam, since visitors to our campus
need to have their requests proxied off to the national proxy servers
once we've processed them.
I thought it was only that you couldn't nest virtual servers more than
two deep -- I'm not sure if you can proxy from a virtual server to a
different external server. I would guess you can.
However, handling EAP involves proxying from the outer server (virtual or
otherwise) to the inner virtual server, so you can't stack the layers
there.
Since we have clients of our RADIUS server (for eduroam) which are in
colleges and departments and then our own wireless system, I had the idea
of handling our wireless system as a virtual server, then proxying to a
generic virtual server* to handle eduroam (local or proxied). Everyone
else would point at the generic server, but our wireless system would use
the virtual server which puts the extra policies on for that (and logging,
etc.).
However, you can't proxy from the wireless virtual server -> generic
server -> inner-tunnel virtual server as that's two deep.
I ended up having the 'default' server handling the generic RADIUS/eduroam
proxying (including to the inner-tunnel virtual server) and then a
separate virtual server for our wireless system. That proxied directly to
the inner-tunnel one for our local eduroam home service.
I moved most of the logic in 'authorize {}', 'accounting {}' and so on
into 'policy.conf', where you can call them a bit like subroutines. That
means I'm only changing that in one place. The specific parts can then go
into the appropriate 'sites-available' entries directly.
[I also used to have to handle both Cisco and Aruba APs, so had some logic
to pick the ESSID out of the different requests and set a local dictionary
attribute 'UCam-Essid-Name', so I could separate that part out.]
- Bob
* I don't believe you can proxy to the 'default' server from a virtual
server, so I essentially disabled the default server and reconfigured one
of the virtual ones to listen on the default ports, during testing;
however, I've not stuck with this implementation, so I undid it again!
--
Bob Franklin <[email protected]> +44 1223 748479
Network Division, University of Cambridge Computing Service
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
