Issues with vendor 3375 (F5) and FreeRADIUS

[Alan DeKok]

On Nov 21, 2023, at 10:52 AM, Coy Hile (BLOOMBERG/ 919 3RD A) <chile1 at bloomberg.net> wrote:
> We're running into issues with F5 devices and authorization against FreeRADIUS. Our network team have included the following dictionary (which is loaded via a $INCLUDE directive in /etc/raddb/dictionary):

  OK.  There isn't much point in posting it to the list.  We've already seen it.

> Further, Shane has configured the server to return the following VSAs for a superuser:
> 
> Tue Nov 14 13:51:39 2023
> Packet-Type = Access-Accept
> F5-LTM-User-Role = Administrator
> F5-F5OS-GID = 9000
> F5-F5OS-UID = 1001
> Timestamp = 1699987899

  That's good.

> However, tcpdump shows the following:
> ...
> Vendor-Specific Attribute (26), length: 12, Value: Vendor: Unknown (3375)
> Vendor Attribute: 1, Length: 4, Value: ....
> 0x0000: 0000 0d2f 0106 0000 0000
> Vendor-Specific Attribute (26), length: 12, Value: Vendor: Unknown (3375)
> Vendor Attribute: 22, Length: 4, Value: ..#(
> 0x0000: 0000 0d2f 1606 0000 2328
> Vendor-Specific Attribute (26), length: 12, Value: Vendor: Unknown (3375)
> Vendor Attribute: 21, Length: 4, Value: ....
> 0x0000: 0000 0d2f 1506 0000 03e9
> 
> Why is the vendor showing up as "unknown (3375)" when 3375 is the vendor ID for F5?

  Because tcpdump doesn't have the FreeRADIUS dictionaries.

  The dictionary names aren't sent in RADIUS packets.  So this is expected behavior.  It's how RADIUS works.

> The attributes that FreeRADIUS says it's sending back actually match the vendor attributes, but they're all jumbled.

  They're being printed as hex data, instead of integer, string, etc.  That's all tcpdump can do if it doesn't have the dictionaries.

  Alan DeKok.