FreeRADIUS Proxy configuration not working

[Alan DeKok]

On May 5, 2020, at 12:22 PM, Thomas Schachtner <Thomas.schachtner at eltheim.de> wrote:
> 
> I need to authenticate different services coming from the same NAS with a
> different set of policies.
> The NAS is signalling the different services using a specific
> "NAS-Identifier" for every service.
> 
> For example, I have a NAS-Identifier == "wifi" when WiFi clients are to be
> authenticated and I have a NAS-Identifier == "l2tp" when a VPN user should
> be authenticated.

  OK.  That should be relatively simple to manage.

> I need to authenticate WiFi users using their Active Directory computer
> certificate (using PEAP) and I need to authenticate VPN users using their
> Active Directory user name (plus their Yubikey, but I am not yet as far...)
> 
> Using the available information and guidelines, I managed it to
> authenticate both services using the same server. It automatically accepts
> either MSCHAPv2 or EAP requests.

  That's good.

> But that is not what I want. I would like to have the VPN guys processed
> with another ruleset that the one used for the WiFi folks...
> 
> Following the advice at
> http://freeradius.1045715.n5.nabble.com/Go-to-virtual-server-by-nas-id-td5755723.html
> I added some home_servers and some home_server_pools in order to take care
> of the different jobs.
> In the default server config file, I added the following:
> 
>        if (NAS-Identifier == "wifi") {
>                update control {
>                        Home-Server-Pool := "wifi-clients-pool"
>                }
>        }
>        if (NAS-Identifier == "l2tp") {
>                update control {
>                        Home-Server-Pool := "vpn-pool"
>                }
>        }

  OK, that should proxy those packets to different home server pools.

> I left all the rest of the file as it was (in order not to break anything).
> As it was mentioned in the comments of the default server config file, I
> also added the same lines to the inner-tunnel config file.

  It shouldn't be necessary to add that to the inner-tunnel virtual server.

> After some time (two seconds or so), the authentication succeeded. But it
> seems as if the default server configuration would be used (instead of the
> wifi server) as you can see in the listing below (Listing 1).

  Yes, when the packets are received, they are processed through the default virtual server.  THEN they are proxied.

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

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

> Here are the added contents to the proxy.conf file
> home_server wifi-clients {
>        virtual_server = wifi-clients
>        type = auth
> }
> 
> home_server vpn {
>        virtual_server = vpn
>        type = auth
> }
> 
> home_server_pool wifi-clients-pool {
>        home_server = wifi-clients
>        type = fail-over
> }
> 
> home_server_pool vpn-pool {
>        home_server = vpn
>        type = fail-over
> }

  That should work.

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

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

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

  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.

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

  It can't get much simpler than that. :)

  Alan DeKok.