FreeRadius 3.0.15 - some radius requests with realm @mylocal.org wrongly get assigned to Default realm (and then proxied)
Hi, we're running FreeRadius 3.0.15 and frequently see a proxy errors in the radius.log such as " "ERROR: Failing proxied request for user "dummy.user@mylocal.org", due to lack of any response from home server <remote ip> port 1812" The problem as it seems is that for some users (by far not for all - just for a few) who provide the correct suffix @mylocal.org the radius request is still wrongly assigned to the default realm and then proxied to the remote radius server defined in the default realm instead of proxied to the local realm as show in this log: (948091) Tue Sep 18 17:42:20 2018: Debug: suffix: Looking up realm " mylocal.org " for User-Name = "dummy.user@mylocal.org " (948090) Tue Sep 18 17:42:20 2018: Debug: eap_peap: Peer indicated complete TLS record size will be 126 bytes (948089) Tue Sep 18 17:42:20 2018: Debug: } # Auth-Type eap = handled (948091) Tue Sep 18 17:42:20 2018: Debug: suffix: Found realm "~.*$" For the other let's say 99% who are providing the very same suffix @ mylocal.org the request is correctly proxied to the local realm (inner tunnel auth processed locally): Debug: suffix: Looking up realm "stud.unibas.ch" for User-Name = " other.user@mylocal.org" (946065) Tue Sep 18 17:41:41 2018: Debug: suffix: Found realm "mylocal.org" (946065) Tue Sep 18 17:41:41 2018: Debug: suffix: Adding Realm = " mylocal.org" (946065) Tue Sep 18 17:41:41 2018: Debug: suffix: Authentication realm is LOCAL Interestingly it's again and again the same users are wrongly assigned to the default realm. It looks like a loop but the operator of the remote radius server informed us no requests for @mylocal.org are seen on his side. Thanks, T.C.
On Sep 21, 2018, at 9:44 AM, Thorsten Fritsch <wiesentalfreunde@gmail.com> wrote:
we're running FreeRadius 3.0.15 and frequently see a proxy errors in the radius.log such as " "ERROR: Failing proxied request for user "dummy.user@mylocal.org", due to lack of any response from home server <remote ip> port 1812"
You could try upgrading to 3.0.17. That contains many fixes. Or, use the v3.0.x head from git, which will become 3.0.18 real soon now.
The problem as it seems is that for some users (by far not for all - just for a few) who provide the correct suffix @mylocal.org the radius request is still wrongly assigned to the default realm and then proxied to the remote radius server defined in the default realm instead of proxied to the local realm as show in this log:
(948091) Tue Sep 18 17:42:20 2018: Debug: suffix: Looking up realm " mylocal.org " for User-Name = "dummy.user@mylocal.org " (948091) Tue Sep 18 17:42:20 2018: Debug: suffix: Found realm "~.*$"
TBH, I suspect that the user is logging in with non-ASCII in the realm name. That may be why it doesn't match, The reason I saw this is that the matching code is pretty well tested. You can believe that the user did something stupid, or you can believe that the code is broken... even though it works for 99% of the users, and for every other network on the planet. i.e. I haven't seen this issue before.
Interestingly it's again and again the same users are wrongly assigned to the default realm. It looks like a loop but the operator of the remote
radius server informed us no requests for @mylocal.org are seen on his side.
He might be receiving them, but with a non-ASCII name. So a "grep" through the log files for that domain won't show anything. If the debug log shows those users actually being proxied, then the issue is most likely non-ASCII names. Alan DeKok.
looks like a whitespace at the end of their realm...probably a smartphone with autocorrect junk. alan
On Sep 21, 2018, at 11:59 AM, Alan Buxey <alan.buxey@gmail.com> wrote:
looks like a whitespace at the end of their realm...probably a smartphone with autocorrect junk.
Ah, yes. I missed that. The default config in v3 checks for problematic whitespace, and rejects users with it. So using the default config is a good idea. :) Alan DeKok.
thanks our checks this morning revealed that this is the problem. The user requests all were containing whitespaces. The ../policy.d/filter file is configured by default as follows: # reject all whitespace # e.g. "user@ site.com", or "us er", or " user", or "user " # if (&User-Name =~ / /) { update request { &Module-Failure-Message += 'Rejected: User-Name contains whitespace' } reject } But for some reason our FreeRadius 3.0.15 still does not reject these user requests but tries to forward them to the radius server (in our case SWITCH.CH) to which all default realm requests are proxied. Any idea what is going wrong and why the request is not rejected locally but still being proxied ? Thanks very much, Thorsten Am Fr., 21. Sep. 2018 um 15:44 Uhr schrieb Thorsten Fritsch < wiesentalfreunde@gmail.com>:
Hi,
we're running FreeRadius 3.0.15 and frequently see a proxy errors in the radius.log such as " "ERROR: Failing proxied request for user "dummy.user@mylocal.org", due to lack of any response from home server <remote ip> port 1812"
The problem as it seems is that for some users (by far not for all - just for a few) who provide the correct suffix @mylocal.org the radius request is still wrongly assigned to the default realm and then proxied to the remote radius server defined in the default realm instead of proxied to the local realm as show in this log:
(948091) Tue Sep 18 17:42:20 2018: Debug: suffix: Looking up realm " mylocal.org " for User-Name = "dummy.user@mylocal.org "
(948090) Tue Sep 18 17:42:20 2018: Debug: eap_peap: Peer indicated complete TLS record size will be 126 bytes
(948089) Tue Sep 18 17:42:20 2018: Debug: } # Auth-Type eap = handled
(948091) Tue Sep 18 17:42:20 2018: Debug: suffix: Found realm "~.*$"
For the other let's say 99% who are providing the very same suffix @ mylocal.org the request is correctly proxied to the local realm (inner tunnel auth processed locally):
Debug: suffix: Looking up realm "stud.unibas.ch" for User-Name = " other.user@mylocal.org"
(946065) Tue Sep 18 17:41:41 2018: Debug: suffix: Found realm "mylocal.org "
(946065) Tue Sep 18 17:41:41 2018: Debug: suffix: Adding Realm = " mylocal.org"
(946065) Tue Sep 18 17:41:41 2018: Debug: suffix: Authentication realm is LOCAL
Interestingly it's again and again the same users are wrongly assigned to the default realm. It looks like a loop but the operator of the remote
radius server informed us no requests for @mylocal.org are seen on his side.
Thanks,
T.C.
On Sep 24, 2018, at 5:49 AM, Thorsten Fritsch <wiesentalfreunde@gmail.com> wrote:
thanks our checks this morning revealed that this is the problem. The user requests all were containing whitespaces. The ../policy.d/filter file is configured by default as follows:
We don't need to see the default policies. We wrote them, we know what they do.
But for some reason our FreeRadius 3.0.15 still does not reject these user requests but tries to forward them to the radius server (in our case SWITCH.CH) to which all default realm requests are proxied.
Likely because you changed the default configuration to remove that check, or bypassed it, or broke it.
Any idea what is going wrong and why the request is not rejected locally but still being proxied ?
It's a total mystery. If only there was some kind of "debug output" which would tell you what the server is doing. Alan DeKok.
participants (3)
-
Alan Buxey -
Alan DeKok -
Thorsten Fritsch