FreeRadius 3.0.15 - some radius requests with realm @mylocal.org wrongly get assigned to Default realm (and then proxied)
Thorsten Fritsch
wiesentalfreunde at gmail.com
Mon Sep 24 11:49:58 CEST 2018
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 at 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 at 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 at 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 at 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.
>
>
>
>
More information about the Freeradius-Users
mailing list