On Wed, Sep 7, 2022 at 3:42 PM Alan DeKok <aland@deployingradius.com> wrote:
Are these from different NASes? i.e. are the RADIUS packets for WiFi coming from a different IP address than RADIUS packets for wired?
They are now, but this might change in the future as they might come from the same NASes.
Don't set a DEFAULT which applies to all packets. Instead, read the debug output to see how the MAB packets are different from the 802.1X packets.
Then, write "unlang" rules to match the MAB packets (but not the 802.1X packets!). Something like:
The only thing I found that could identify the packet as being MAB (well, Cisco's MAB implementation) is: Cisco-AVPair = "method=mab" It seems to always be in 3rd position, but I don't know if this is reliable. (1) Cisco-AVPair = "service-type=Call Check" (1) Cisco-AVPair = "audit-session-id=AC1CAFF4000000222E048EA2" (1) Cisco-AVPair = "method=mab" This seems to work fine for me: if ("%{request:Cisco-AVPair[2]}" == "method=mab" && !EAP-Message) -> TRUE as well as this: if ("%{request:Cisco-AVPair[*]}" =~ /method=mab/ && !EAP-Message) -> TRUE I don't know if I should also check for the presence of "service-type=Call Check". So anyway, I can set the following condition in authorize and "accept" without filtering: if ("%{request:Cisco-AVPair[*]}" =~ /method=mab/ && !EAP-Message) { accept } In post-auth I will then add a condition to lookup the MAC addr. in local DB, eg: if (EAP-Message) { # all my wireless and wired EAP-TLS/PEAP clients should go here # determine &MY_VLAN_ID (local DB lookup) update reply { &Tunnel-Type := VLAN &Tunnel-Medium-Type := IEEE-802 &Tunnel-Private-Group-Id := &MY_VLAN_ID } } else { # all my other clients should end up here (in my case, via MAB only) # determine &MY_VLAN_ID (different local DB lookup) else &MY_VLAN_ID = 1 update reply { &Tunnel-Type := VLAN &Tunnel-Medium-Type := IEEE-802 &Tunnel-Private-Group-Id := &MY_VLAN_ID } } It seems to be working for me now. Do you see anything foolish security-wise in my setup? Thanks!