Robust Authentication Proxying

Ivan Kalik tnt at kalik.net
Fri Jul 10 16:45:58 CEST 2009


> I must be missing something, because even after the home_server has been
> marked as a zombie, the proxy is still ignoring the retransmits.
> Furthermore, it's taking much longer than the response_window for the
> home_server to be marked as a zombie.
>
> rad_recv: Access-Request packet from host 127.0.0.1 port 39091, id=56,
> length=59
> +- entering group authorize {...}
> ++[control] returns notfound
> +- entering group pre-proxy {...}
> [attr_filter.pre-proxy]         expand: %{Realm} -> DEFAULT
>   attr_filter: Matched entry DEFAULT at line 50
> ++[attr_filter.pre-proxy] returns updated
> Sending Access-Request of id 175 to xxx.xxx.xxx.12 port 1812
> Proxying request 0 to home server xxx.xxx.xxx.12 port 1812
> Sending Access-Request of id 175 to xxx.xxx.xxx.12 port 1812
> Going to the next request
> Waking up in 0.9 seconds.
> Waking up in 3.9 seconds.
> rad_recv: Access-Request packet from host 127.0.0.1 port 39091, id=56,
> length=59
> Sending duplicate proxied request to home server xxx.xxx.xxx.12 port
> 1812 - ID: 175
> Sending Access-Request of id 175 to xxx.xxx.xxx.12 port 1812
> Rejecting request 0 due to lack of any response from home server
> xxx.xxx.xxx.12 port 1812
>    Found Post-Proxy-Type
> +- entering group Fail {...}
> ++[control] returns noop
> ++- entering policy do_not_respond {...}

That's why!

> +++[control] returns noop
> +++[handled] returns handled
> ++- policy do_not_respond returns handled
> Going to the next request
> PROXY: Marking home server xxx.xxx.xxx.12 port 1812 as zombie (it looks
> like it is dead).
> Sending Status-Server of id 81 to xxx.xxx.xxx.12 port 1812
>          Message-Authenticator := 0x00000000000000000000000000000000
>          NAS-Identifier := "Status Check. Are you alive?"
> Waking up in 3.9 seconds.
> Waking up in 3.9 seconds.
> rad_recv: Access-Request packet from host 127.0.0.1 port 39091, id=56,
> length=59
> Ignoring retransmit from client SERVERS port 39091 - ID: 56, no reply
> was configured

I can see your point. You would like to argue that the request should be
taken of the list even if no response was configured - since server didn't
respond because of the do_not_respond policy. I am not sure that can be
made to work.

Ivan Kalik
Kalik Informatika ISP




More information about the Freeradius-Users mailing list