Re: FreeRADIUS Proxy configuration not working

5 May 2020

      On May 5, 2020, at 12:22 PM, Thomas Schachtner <Thomas.schachtner@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-td575...
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.