Proxy CoA packet from network control to NAS(same as CoA server) configs in case of many many NASes.

[Brian Julin]

Sergey Komarov [sergey.komaroff at 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.