FreeRADIUS Proxy configuration not working

Thomas Schachtner Thomas.schachtner at eltheim.de
Mon May 11 18:37:38 CEST 2020


Hi Alan and all,

this was very helpful, indeed!
It helped me understand better how FreeRADIUS works.
Now some pars of the documentation make more sense to me ;-)

I still have some questions left, though. Hope you don't mind me asking...
>   Yes, when the packets are received, they are processed through the default virtual server.  THEN they are proxied.
What sense does proxying make if they are also processed by the default
virtual server? If there's alrady a decision made on how the
Authentication is to be done (i. e. Auth-Type), why should I then
delegate the job to another server?
In my understanding, a proxy server takes care of all the jobs and the
default server does not have to take care of them anymore.
But I guess, my understanding is completely wrong :-)
>> When removing all the rest of the default server config file, the
>> authentication does not succeed anymore.
>   Yes, because you deleted the policies that made it work.
Ok, got that. The server complained about a missing Auth-Type, so I
updated control and added "Auth-Type := Accept".
But then everything's done, right? There's no need anymore to jump to
the other server pool...
>> On some other site I found that it might have to be done like this:
>>
>>        if (NAS-Identifier == "wifi") {
>>                update control {
>>                        Proxy-To-Realm := "wifi-clients-realm"
>>                }
>>        }
>>        if (NAS-Identifier == "l2tp") {
>>                update control {
>>                        Proxy-To-Realm := "vpn-realm"
>>                }
>>        }
>>
>> But then, the authentication does not work at all anymore although now it
>> seems as if the wifi virtial server processes the request  (Listing 2).
>> Does anyone know how?
>   The debug log should be clear.
It seems as if the EAP handshake cannot be established. At least, in a
working example, there are serveral more stages with many lines
containing"Continuing EAP-TLS". Here, there are no such lines. So for
some reason the communication is not working. Is it due to the proxying?
Should the proxy send the answer back to the default server?
For me, that does not really make much sense, unfortunately. Am I too
stupid? ;-)
>> (The virtual server configuration files are copies of the default server
>> file without the NAS-Identifier switching part shown above.)
>   And presumably only containing Wifi or VPN policies for each one?
At that point of time, they were full copies, with just the
NAS-Identifier switching removed.
>> Originally, I wanted the main server just to be a dispatcher, forwarding
>> the request either to the one or to the other virtual server.
>> Can that be done?
>   Absolutely.
That's exactly what I would like to achieve... (for the moment)
>> ...
>> (5) # Executing group from file /etc/freeradius/3.0/sites-enabled/default
>> (5) Using Post-Auth-Type Challenge
>> (5) # Executing group from file /etc/freeradius/3.0/sites-enabled/default
>> (5)   Challenge { ... } # empty sub-section is ignored
>> (5) Sent Access-Challenge Id 253 from 10.10.8.43:1812 to 10.10.10.10:57160
>> length 0
>> (5)   State = 0x9af9b7683dae0ca97a5c4c6d28349ebf
>> (5) Finished request
>   Hmm.. and no EAP-Message attribute.  That's bad. :(
Yes, it is. But why? Do you know?
>
>   The simplest thing to do is this:
>
> 1) set up everything using the default virtual server, with the 'authorize' section having something like:
>
> authorize {
> 	if (NAS-Identifier == "wifi") {
> 		... wifi rules ...
> 	}
> 	elsif (NAS-Identifier == "l2tp") {
> 		... l2tp rules ...
> 	}
> }
>
>   And verify that each of them works.
Yes, that works.
> 2)  Then, take the contents of the "wifi rules" and "l2tp rules", and put them into raddb/policy.d/local:
>
> policy wifi {
> 	... wifi rules ...
> }
>
> policy l2tp {
> 	... l2tp rules ...
> }
>
>   And the "authorize" section now becomes:
>
> authorize {
> 	if (NAS-Identifier == "wifi") {
> 		wifi
> 	}
> 	elsif (NAS-Identifier == "l2tp") {
> 		l2tp
> 	}
> }

Ok, that works. But that's not really proxying, right?
Maybe I don't need proxying at all...

Now to the 2nd part of my setup.
I want to do 2 factor authentication for all l2tp users.
The first step should be the (already working) mschap authentication and
the 2nd step should be done using Yubikeys.
I found some documents in the Internet, but they all work with pam which
means I cannot use the mschap setup anymore which is now working fine...
This page is documenting the local part:
https://wiki.freeradius.org/guide/2FA-Active-Directory-plus-Proxy
The Yubikey part is then done by an external proxy. But how to set up
that external proxy? There seems to be a yubikey module, but I don't
really understand how to implent it.
And how can I link one specific Yubikey to one user (so that it's not
possible that they give away their keys and everyone having the key can
dial in via VPN)?
Is my setup unusual? I guess that there might be many people out there
having similar setups...
Are the all able to configure that manually? Or am I missing any
documentation?
(If so, then sorry for the questions...)

Best regards
Tom


More information about the Freeradius-Users mailing list