Deleting VLAN information while proxying

[Phil Mayers]

A.L.M.Buxey at lboro.ac.uk wrote:
> 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 

I can see what you're saying, but to be honest I think it's wisest to 
keep the NRPSes totally transparent. I can come up with (at least 
halfway reasonable! :o) hypothetical cases for institutions trusting 
layer2 attributes on remote realms but still wanting to peer via the 
NRPSes rather than direct.

(FYI for anyone reading not knowing what we're talking about, various 
countries academic and in some cases other networks have national and 
even international radius peerings for 802.1x and such - google "eduroam")

> 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.

That's not the issue, FreeRadius has rlm_attr_filter as you mention 
below. But the only stanza you could filter these attributes is the 
post-auth stanza, and the rlm_attr_filter module does not run in (have a 
handler for) post-auth in FreeRadius 1.1.0 at least.

*If* it ran there (I have no idea if there's a fundamental reason it 
can't), you could potentially set this in the users file:

DEFAULT Client-IP-Address == "1.2.3.4", Post-Auth-Type := "PROXY"

Then do:

modules {
   attr_filter filter_downstream {
     # filter file
   }
}
# snip
post-auth {
   Post-Auth-Type PROXY {
     filter_downstream
   }
}


> Should it have? perhaps. RADIATOR doesnt IIRC - you throw external PERL
> scripts at the problem.  

Yes.

> 

> ........................................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.

It can't, because there's no stanza it can run in currently.

rlm_attr_rewrite *does* run in/handle post-auth, indicating there's no 
fundamental server reason you can't change a packet there, but you can't 
remove an attribute completely with rewrite; though you could truncate 
it, you'd risk poorly configured home sites putting NO vlans on the NAS 
port :o)

Alan (DeKok) - is there a quick two-line description of what issues 
would need to be addressed to run attr_filter in post-auth? If it's easy 
I'll take a crack at it, as it would simplify our config as well.