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

30 Oct 2024


      Thank you, Alan! Worked like a charm!


     client wifi@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@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@location-type-x@ap1
     location-a@location-type-x@ap2
     location-b@location-type-x@ap1
     location-c@location-type-z@ap1
     location-c@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