I thought a little about filtering access-reject packets. Perhaps it's not very useful, but here is my personal opinion. 1. Allowing VSA in the reply packets is really a bug: if you have an existing username with a wrong password, the VSA useful to set up a connection were pulled from the database during autorize and are send in the reject packet. 2. Making the option user-defined may bring more confusion. Too many options make the server more difficult to configure. Moreover the administrator may not figure out easily that turning this option on will hit the bug in (1). 3. Moving the function to a module is a bit dangerous. The modules are optional, and I don't want the server to do something crazy when removing one of the modules. 4. I like software that figure out themselves what to do ;-) Apparently the users complaining about the problem are using FreeRADIUS as a proxy for RFC-ignorant third party servers. That's why I think we could relax the filter on proxy replies *only*. The rationale is when FreeRADIUS is acting as a home server, it's hard to configure it to intentionally reply VSA in access-reject, therefore the current behaviour should be fine. When FreeRADIUS is acting as proxy, we are not really responsible if the incoming packets are not RFC-compliant. Then perhaps it makes sense to allow the VSA in the latter case. -- Nicolas Baradakis