Sergey Komarov [sergey.komaroff@gmail.com] wrote
Thank you Brian! But actually what I do now is that our external network controls(CoA portal) sends these coa packets to change users policy(I don't need to bind it to access req) and I wanted just proxy it via FreeRadius (to have more control about contents of these packets and have ability to modify something on the fly in CoA packet later if needed just inside of FreeRadius).
Right, so what you do to use my scripts is proxy all the CoAs to some dummy server which just accepts them, and unlang the script into the config so it runs pre-proxy when forwarding the CoA request, sending attributes from the CoA request to the script with your modifications. Basically you originate a CoA to replace the one sent by the AS. You might even be able to finagle using rlm_exec or something to return accurate responses if the NAS rejects the CoA, I don't know. I haven't had the opportunity to deal with an AS that will actually send me back the CoAs as mine will only send them direct to the NAS, which is why my example acted during auth packets rather than dynauth.
I understand that all home servers must be in configs to address them correctly and I did it. Problem is that my home servers are in config, but packet doesn't proxy in case of Dst-IP usage (home server not found)...
If that's not working, perhaps some rlm_realm magic may be able to map IPs to home_servers. You'd have to autogen the realm rules to match the server defs. Personally, though, I try to avoid anything that requires me to maintain a database of all my NASes. If it knows the secret for its class of device, it's a NAS :-) I have better things to do with my time.