Hello Community, I am doing store and proxy accounting to different servers, Now I want to remove the proxy-state attribute from the proxied packet. The problem is that other accounting servers that are not FreeRadius are not accepting proxy-state attribute. So they are not sending the acccounting response back. This makes the detail file size increase. I am using FreeRadius version 2.1.10 with roubust-accounting configuration. the proxy servers are being load-balanced. and detail file is being created correctly Thank you Waqas Toor
Waqas Toor wrote:
I am doing store and proxy accounting to different servers, Now I want to remove the proxy-state attribute from the proxied packet. The problem is that other accounting servers that are not FreeRadius are not accepting proxy-state attribute. So they are not sending the acccounting response back.
The other server does not follow the RFCs. It is broken in a way that violates the RADIUS protocol. Alan DeKok.
On Sat, Apr 16, 2011 at 11:22 AM, Alan DeKok <aland@deployingradius.com> wrote:
Waqas Toor wrote:
I am doing store and proxy accounting to different servers, Now I want to remove the proxy-state attribute from the proxied packet. The problem is that other accounting servers that are not FreeRadius are not accepting proxy-state attribute. So they are not sending the acccounting response back.
The other server does not follow the RFCs. It is broken in a way that violates the RADIUS protocol.
Yes, Understood, Can I can limit those proxy-state attributes to lets say 100 attributes only. Because the other server is complaining about possible DoS attacks.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Waqas Toor wrote:
Yes, Understood, Can I can limit those proxy-state attributes to lets say 100 attributes only. Because the other server is complaining about possible DoS attacks.
<sigh> It would have been useful for you to say that at the beginning. If there are 100 Proxy-State attributes, it's likely because you screwed up proxying somewhere. It makes *no* sense to proxy packets through 100 servers. And *don't* CC me on messages sent to the list. In case you hadn't noticed, I do read the list. Alan DeKok.
On Sat, Apr 16, 2011 at 9:19 PM, Alan DeKok <aland@deployingradius.com> wrote:
Waqas Toor wrote:
Yes, Understood, Can I can limit those proxy-state attributes to lets say 100 attributes only. Because the other server is complaining about possible DoS attacks.
<sigh> It would have been useful for you to say that at the beginning.
If there are 100 Proxy-State attributes, it's likely because you screwed up proxying somewhere. It makes *no* sense to proxy packets through 100 servers.
Ok here is my robust-example-accounting that I am using for proxy ============================================================== home_server home1.example.com { type = acct ipaddr = 10.1.67.37 port = 1813 secret = free-rad512 # Mark this home server alive ONLY when it starts being responsive status_check = request username = "test_user_status_check" response_window = 6 } home_server home2.example.com { type = acct ipaddr = 10.1.67.28 port = 1813 secret = free-rad512 # Mark this home server alive ONLY when it starts being responsive status_check = request username = "test_user_status_check" response_window = 6 } home_server acct_detail.example.com { virtual_server = acct_detail.example.com } home_server_pool acct_pool.example.com { type = load-balance # other types are OK, too. home_server = home1.example.com home_server = home2.example.com fallback = acct_detail.example.com virtual_server = home.example.com } realm test_cpe.com{ acct_pool = acct_pool.example.com nostrip } server acct_detail.example.com { accounting { detail.example.com } } server home.example.com { pre-proxy { } post-proxy { Post-Proxy-Type Fail { detail.example.com } } listen { type = detail filename = "${radacctdir}/detail.example.com/detail-*:*" load_factor = 10 } accounting { update control { Proxy-To-Realm := "test_cpe.com" } } } ================================================ It works fine, but when one of the server goes down of a long period, It sends a lot of proxy state attributes. Regards Waqas
Waqas Toor wrote:
Ok here is my robust-example-accounting that I am using for proxy
Which I didn't ask for.
It works fine, but when one of the server goes down of a long period, It sends a lot of proxy state attributes.
Then you didn't follow the example. You configured it so that the detail file reader would write packets *back* to the detail file in the "Post-Proxy-Type Fail" section. Don't do that. Go read the sample "robust-proxy-accounting" file. This is documented. Alan DeKok.
It works fine, but when one of the server goes down of a long period, It sends a lot of proxy state attributes.
Then you didn't follow the example. You configured it so that the detail file reader would write packets *back* to the detail file in the "Post-Proxy-Type Fail" section.
Don't do that.
Go read the sample "robust-proxy-accounting" file. This is documented.
OK thanks Alan, but please clear one confusion. Now if one of the server goes down then this part accounting { update control { Proxy-To-Realm := "test_cpe.com" } } where in the pool I have fallback defined as home_server_pool acct_pool.example.com { type = load-balance # other types are OK, too. home_server = home1.example.com home_server = home2.example.com fallback = acct_detail.example.com virtual_server = home.example.com } will it update the detail file ? Waqas
Waqas Toor wrote:
OK thanks Alan, but please clear one confusion. Now if one of the server goes down then this part ... will it update the detail file ?
I have no idea. Follow the example. It works. It's documented. It Does the Right Thing. If one of the home servers goes down, it Does the Right Thing. The documentation says this. I don't know what you've changed, and it doesn't really matter. If you're following the example, it will work. If not, it won't work. Alan DeKok.
participants (2)
-
Alan DeKok -
Waqas Toor