On Jul 17, 2015, at 9:15 AM, Sergey Komarov <sergey.komaroff@gmail.com> wrote:
Yes, I'm using 3.0.9: FreeRADIUS Version 3.0.9, for host x86_64-unknown-linux-gnu, built on Jul 14 2015 at 19:39:49 Linux version 2.6.32-504.el6.x86_64 (mockbuild@c6b9.bsys.dev.centos.org) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC) ) #1 SMP Wed Oct 15 04:27:16 UTC 2014
OK.
(7) update reply { (7) Cisco-AVPair += "url-redirect-acl=acl" (7) EXPAND url-redirect=http://login.domain... (7) --> url-redirect=http://login.domain (7) Cisco-AVPair += url-redirect=http://login.domain (7) Packet-Dst-IP-Address := 10.56.33.190 <------------ here I just override real NAS IP with another NAS fixed address (it present in clients too)
No, that is NOT the same as what you did for CoA packets. This isn't about sending the reply to a different NAS-IP. That will NEVER be supported, because it's wrong. It's about can you *proxy* the packet to a home server. You should instead do: update control { Packet-Dst-IP-Address := ip.of.home.server. }
FreeRadius still sends to NAS IP instead of my override IP. So it doesn't matter in CoA or in authorize section it is same behavior - FreeRadius ignores NAS ip override via Packet-DST.
The server will ALWAYS send replies to the IP that the request came from. Anything else is wrong.
Could you please check any simple scenario - just try to override Packet-Dst-IP-Address and than add to override Packet-Dst-Port?
I won't have time for a while. Until then, please try the correct test for Access-Request packets. Alan DeKok.