Pass client attributes from client.conf to post-auth section

[Alexey D. Filimonov]

Thank you, Alan! Worked like a charm!


     client wifi at location-a@ap1 {

       ipaddr = 1.1.1.1/32
       secret = "Secret123"
       vlan_for_ssid1 = 1
       vlan_for_ssid2 = 2
     }

     authorize {
       rewrite_called_station_id

       if (!Called-Station-SSID) {
         update request {
           &Module-Failure-Message += 'Rejected: No SSID in 
Called-Station-Id'
         }
         reject
       }

       if ("%{client:vlan_for_%{Called-Station-SSID}}") {
         update session-state {
           Tunnel-Private-Group-Id := 
"%{client:vlan_for_%{Called-Station-SSID}}"
         }
       } else {
         update request {
           &Module-Failure-Message += "Rejected: No 
vlan_for_%{Called-Station-SSID} defined for client %{client:shortname}"
         }
         reject
       }
       ...
     }

     post-auth {
       ...
       update {
           &reply: += &session-state:
       }
       ...
     }


On 2024-10-30 23:33, Alan DeKok wrote:
> On Oct 30, 2024, at 4:19 PM, Alexey D. Filimonov <alexey at filimonic.net> wrote:
>> Is it possible to have client shortname (from clients.conf) or any custom per-client property inside post-auth and post-proxy block?
>    Yes.  Because the client is associated with the entire lifetime of the request.
>
>> Problem: I have multiple physical locations of different "types", each location type has it's own requirement for Tunnel-Private-Group-Id.
>>
>> With MS NPS, I have AAA clients named
>>
>>      location-a at location-type-x@ap1
>>      location-a at location-type-x@ap2
>>      location-b at location-type-x@ap1
>>      location-c at location-type-z@ap1
>>      location-c at location-type-z@ap2
>>
>> And I build access rules logic with conditions like "rule when client name match /@location-type-x@/" and "another rule when client name match /@location-type-z@/".
>>
>> With FreeRADIUS I found no information about client shortname in debug_all output inside post-auth block.
>>
>> I can build huge ruleset of additional unlang logic like this, or maybe more simple...
>>
>> if (&NAS-IP-Address == "1.1.1.1" && Called-Station-Id =~ /:ssid1/) {
>>    update response { Tunnel-Private-Group-Id = "100" }
>> } elsif (&NAS-IP-Address == "1.1.1.1" && Called-Station-Id =~ /:ssid2/) {
>>    update response { Tunnel-Private-Group-Id = "101" }
>> } elsif (&NAS-IP-Address == "1.1.1.2" && Called-Station-Id =~ /:ssid1/) {
>>    update response { Tunnel-Private-Group-Id = "100" }
>> } elsif (&NAS-IP-Address == "1.1.1.2" && Called-Station-Id =~ /:ssid2/) {
>>    update response { Tunnel-Private-Group-Id = "101" }
>> } elsif (&NAS-IP-Address == "1.1.2.1" && Called-Station-Id =~ /:ssid1/) {
>>    update response { Tunnel-Private-Group-Id = "203" }
>> } elsif (&NAS-IP-Address == "1.1.2.1" && Called-Station-Id =~ /:ssid2/) {
>>    update response { Tunnel-Private-Group-Id = "204" }
>> } ...
>>
>> But in my opinion, 1) there must be a way not to duplicate client address information in both post-auth and clients.conf 2) amount of code looks stupid when scaled to tens of locations.
>    Yes.  You can do:
>
> client foo {
> 	ipaddr = 1.2.3.4
> 	secret = testing123
> 	...
>
> 	my_group_id = 101  # just put anything here!
> }
>
>    and then at run time:
>
> update reply {
> 	Tunnel-Private-Group-Id = "%{client:my_group_id}"
> }
>
>    The "client" section is really a simple key-value store.  :)
>
>    Alan DeKok.
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html