post-proxy and detecting dead upstream realms
I'd like to do something like this: pre-proxy { update control { Tmp-Integer-0 := "%{some_scoring_thing:%{Realm}}" } if (Tmp-Integer-0 > 10) { reject } } post-proxy { Post-Proxy-Type Timeout { some_scoring_thing } } The idea is that I have an upstream proxy (eduroam) with potentially hundreds of realms behind it. Some realms just don't respond, and when that happens above a certain threshold, I'd like to locally blacklist the realm and avoid sending them to the upstream proxy for some time period. I'm not willing to maintain a manual blacklist. The question: what method can I use to run a module/expansion when a proxy request isn't replied to. "Post-Proxy-Type Fail" doesn't seem to do it (in fact, I can't make it trigger at all in my tests). Looking at the source this might be impossible?
Hi Phil, Sorry I cannot help with evaluating the code, but I've got a question... On Thu, Jan 15, 2015 at 8:39 AM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
I'd like to do something like this:
pre-proxy { update control { Tmp-Integer-0 := "%{some_scoring_thing:%{Realm}}" } if (Tmp-Integer-0 > 10) { reject } }
post-proxy { Post-Proxy-Type Timeout { some_scoring_thing } }
The idea is that I have an upstream proxy (eduroam) with potentially hundreds of realms behind it. Some realms just don't respond, and when that happens above a certain threshold, I'd like to locally blacklist the realm and avoid sending them to the upstream proxy for some time period.
Why do you care if the realm doesn't respond? Thanks, -m
On 15/01/15 14:48, Matt Zagrabelny wrote:
Why do you care if the realm doesn't respond?
Cleanliness, mainly. The outstanding response consumes a radius packet ID on the proxy socket, and on the receive auth socket. On a busy NAS, the latter is likely to get re-used while waiting, resulting in: Error: Received conflicting packet from client xxx port 32770 - ID: 182 due to unfinished request 51899386. Giving up on old request That is, the NAS sent a request, ID#182, which got proxied to a blackhole realm. 15 seconds later it re-used that packet ID for something else. I'd like to eliminate sources of this message which are not local problems; then if I see the message, I know I have to investigate it. "Real" cause of this message are something to worry about. In particular, on some current equipment (cough Cisco cough) those messages might indicate you're very close to the "offered load of doom" threshold where the NAS's single radius UDP socket has >255 legitimate packet IDs in-flight and your wireless network is about to explode. (Yes, Cisco should fix this) More generally - such a mechanism would be useful for blacklisting horribly mis-configured clients before even trying to proxy them, saving a round-trip and various lookup/logging load.
Hi,
"Real" cause of this message are something to worry about. In particular, on some current equipment (cough Cisco cough) those messages might indicate you're very close to the "offered load of
thats the main issue. at least on the new releases they have a seperate 255 for the accounting datagrams.... I dont see why they dont use a different NAS-Port for each access point on the controller...that would be a nice simple solution alan
On 15/01/15 15:27, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
"Real" cause of this message are something to worry about. In particular, on some current equipment (cough Cisco cough) those messages might indicate you're very close to the "offered load of
thats the main issue. at least on the new releases they have a seperate 255 for the accounting datagrams.... I dont see why they dont use a different NAS-Port for each access point on the controller...that would be a nice simple solution
NAS-Port? How would changing the RADIUS attribute help, surely the packet IDs would still be limited to 255? Really they just need to open new UDP sockets when they've exhausted IDs. It's not rocket science... ;o)
On 15 Jan 2015, at 22:47, Phil Mayers <p.mayers@IMPERIAL.AC.UK> wrote:
On 15/01/15 15:27, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
"Real" cause of this message are something to worry about. In particular, on some current equipment (cough Cisco cough) those messages might indicate you're very close to the "offered load of
thats the main issue. at least on the new releases they have a seperate 255 for the accounting datagrams.... I dont see why they dont use a different NAS-Port for each access point on the controller...that would be a nice simple solution
NAS-Port? How would changing the RADIUS attribute help, surely the packet IDs would still be limited to 255?
Really they just need to open new UDP sockets when they've exhausted IDs. It's not rocket science... ;o) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Configure rlm_cache with a key matching realm: Set cache TTL to be the length of time you want a realm to be blacklisted (+ timeout). In Pre-Proxy: If there's no existing entry, create one with a date attribute set to the current time. If there's an existing entry, merge it, check date attribute, if now() - date > proxy timeout respond locally, assume realm is blacklisted. In Post-Proxy: Assuming proxy was successful - expire cache entry. When request goes out, an entry is created, it's removed on expiry or when a valid response is received. If it hasn't been removed within the timeout then we know the proxy server didn't respond. You can do more complex versions, where you maintain a counter using another rlm_cache instance, but the above mechanism at least gives you a simple (and fairly clean) way of detecting when timeouts have occurred. If you want to share state between a cluster of server you could use the memcached cache backend. If you want persistence, feel free to write another backend for rlm_cache. I was thinking an rlm_cache_file backend might be nice, which would do something very similar to the session resumption code in rlm_eap. There's an internal API in rlm_cache now, and there's the 'exfile' (we need more punny names in the server) API Alan wrote to manage exclusive access to files. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Jan 15, 2015, at 9:39 AM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
I'd like to do something like this: ... post-proxy { Post-Proxy-Type Timeout {
That’s hard.
The idea is that I have an upstream proxy (eduroam) with potentially hundreds of realms behind it. Some realms just don't respond, and when that happens above a certain threshold, I'd like to locally blacklist the realm and avoid sending them to the upstream proxy for some time period.
That’s useful. It should be an example in the default configuration. In v3, you can use the “cache” module to do this.
The question: what method can I use to run a module/expansion when a proxy request isn't replied to. "Post-Proxy-Type Fail" doesn't seem to do it (in fact, I can't make it trigger at all in my tests).
The issue is that the server is asynchronous. It triggers "Post-Proxy-Type Fail” from client retransmissions. If the client doesn’t retransmit… there isn’t much you can do.
Looking at the source this might be impossible?
Doing exactly what you want is hard. Doing something related may be possible. In proxy.conf, set: no_response_fail = yes And then update the realm counter in “Post-Auth-Type Reject” Arran and I are looking at changes to v3 which will make all of this much easier. Alan DeKok.
participants (5)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Arran Cudbard-Bell -
Matt Zagrabelny -
Phil Mayers