FreeRADIUS Proxy configuration not working

[Alan DeKok]

On May 11, 2020, at 12:37 PM, Thomas Schachtner <Thomas.schachtner at eltheim.de> wrote:
> this was very helpful, indeed!
> It helped me understand better how FreeRADIUS works.
> Now some pars of the documentation make more sense to me ;-)

  That's good.

> I still have some questions left, though. Hope you don't mind me asking...

  Despite rumours. it's what I do.  :)

>>  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?

  The decision to proxy is something that happens *in* the default virtual server.  If the server just proxied everything it received, you could replace it with a wire.

  The default virtual server examines the packets, decides where (or if) to proxy them, and also processes / edited them before / after proxying.  These steps are all required.

> 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?

 Because the local server may not have the users account information.

  This is called "roaming".  This happens not just for RADIUS, but also for cell phone service.  The process is the same conceptually.

> 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.

  The default server *also* applies local policies, and *also* knows about local users.  It is *not* just a wire.

  e.g. the home server may say "assign the user IP X".  The local RADIUS server needs to delete that information, because the local IP address space is different.

> But I guess, my understanding is completely wrong :-)

  Not large enough in scope.

> 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...

  It all depends on what you want to do.

> 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?

 No.  It's because you changed massive things without testing.

> Should the proxy send the answer back to the default server?

  It depends..

>>  Hmm.. and no EAP-Message attribute.  That's bad. :(
> Yes, it is. But why? Do you know?

  Probably an issue with internal proxying in v3.

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

  Exactly.  Proxying is a solution for a particular problem.  If you don't have that problem, then proxying isn't helpful.

> 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 doubt very much that will work.  You simply cannot control *how* the authentication protocols work.  They do what they do, and any 2FA needs to work *within* the existing framework.

  i.e. read the documentation for your L2TP server.  If it says it can do 2FA with mschap and an OTP system, then it might be possible.  Otherwise, it's impossible.

> 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.

 I suggest first seeing if it's possible.  Otherwise you waste time reading documentation that's complex and confusing, which results in no benefit.

> 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)?

  Yubikey takes are of that.

> Is my setup unusual? I guess that there might be many people out there
> having similar setups...

  It may be unusual.

  People usually get into difficulties when they first decide what they want to do, and secondly see if it's possible.  That's backwards.

  You first need to understand how things work.  Then, see if you can get OTP, etc. to function within the limitations of existing things.

  i.e. if you need to pull a ten ton load, you can't hook it up to a hatchback and expect it to go anywhere.  It's just not possible.  And it doesn't help to say "but I really need to pull a ten ton load, and I only have a hatchback".  You need to see what tools can meet your requirements, and then see if you can use those tools.

  Alan DeKok.