Deleting VLAN information while proxying

A.L.M.Buxey at lboro.ac.uk A.L.M.Buxey at lboro.ac.uk
Thu Feb 9 21:27:06 CET 2006


Hi,
> We have the following problem arising form the eduroam project.
> Our university radius server sets VLAN information based on user
> attributes form the LDAP directory.
> This works fine when the system is used internally. However when our
> user authenticates while visiting another institution, this VLAN
> information should not be sent out. In such a situation, the
> authentication request arrives via the national proxy.  We have managed
> to configure VLAN blocking for EAP-TLS since then we can use
> Client-IP-Address information. If this address corresponds to the
> address of the national proxy then we do not set VLAN information at
> all. This approach breaks down with EAP-TTLS. The internal proxy
> mechanism rewrites the Client-IP-Address to localhost and all requests
> look the same.
> We could in principle base our decision on huntgroups, creating a
> huntgroup for all out NASes, but his looks so clumsy and a mess to
> administer.
> Is there a better trick to solve this?

I cant see WHY the VLAN info needs to reach other sites at all...perhaps
the National Proxy should be stripping out such things? anyway, if memory 
server correctly, the VLAN stuff is in RFC3580. you have 2 main attributes:

Tunnel-Type = VLAN (13)
Tunnel-Private-Group-ID = VLANID

these would have to be stripped out. much like User-ID, REALM etc can be 
pruned and changed.... now, FreeRADIUS has such a mechanism? I'm not sure.
Should it have? perhaps. RADIATOR doesnt IIRC - you throw external PERL
scripts at the problem.  

alternatively....simply do as you say...but REVERSE your logic. put non
local systems into the huntgroup....ie the national proxies. but
there might be an alternative.......

........................................use the attrs.pre-proxy stuff with
the rlm_attr_filter. with this, you should be able to clear any attribute
that you dont want leaving your site. I havent played with this myself
but it does look like it could do the magic you may require along with attr_rewrite.
both of these already have very verbose presence (though commented out) in
the radiusd.conf

Alan



More information about the Freeradius-Users mailing list