Alan DeKok napisał(a):

Tomasz Wolniewicz <Tomasz.Wolniewicz@uni.torun.pl> wrote:

...

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.

rlm_attr_filter should work, I think.

Alan DeKok.

Alan, thanks, but it seems that when freeradius does the internal proxy to service the eap-ttls then the pre-proxy and post-proxy are not being entered, and this is where we would expect to put attr_filter. We tried the post_auth but it refuses to take attr_filter. Tomasz

Alan DeKok wrote:

Can you not key off of the NAS information, and *not* add VLAN data, then?

I am not sure what you mean by that. Using NAS information is the only thing that came to our minds, that is we create a large hunt group containing all local NASes and add VLAN data only when this is hit. But we did not manage to make any comparison of NAS-IP-Address other then equality. If one could use regex then it would be easy, but somehow this did not seem to work. Obviously one could use another dirty hack - add another proxy server and do all cleaning there, but it seems that there should be a clean and simple way of doing what we need. Actually one might argue that it is the network provider that should be careful to filter out all foreign VLAN attributes on input as this can be a security hazard not to do so, and this task is easily done with attr_filter. Unfortunately if a user gets to a site that does not filter VLAN attributes on input, in most cases the VLAN will not match anything useful and the user will not get connected, so it makes a lot of sense to block the VLANs also on the output as a good service to our users (not to mention the fact that telling people our VLAN numbers is probably not very wise either). Tomasz

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

A.L.M.Buxey@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.

Alan DeKok wrote:

Phil Mayers <p.mayers@imperial.ac.uk> wrote:

...

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.

Port the changes from CVS head, I think.

Ha! I ought to have known you'd have done it already. Alan, in case anyone hasn't said it recently - you do an excellent job maintaining this project under difficult conditions. You have my and I suspect many other peoples sincere gratitude, and I can only hope it's as rewarding for you as it is helpful for us. Cheers, Phil