When using the radius monitor should the F5 accept the access-reject message as a successful response to the monitor?

documentation says: "Checks the status of Remote Access Dial-in User Service (RADIUS) servers. The check is successful if the server authenticates the requesting user. A RADIUS monitor requires a user name, a password, and a shared secret string for the code number."

 

i read that as you need a successful authentication, but i can't find it clearer then here.

 

As my late father used to say: "Bugger off is also an answer". Here's a null radius request:

Access-Request (1), id: 0x00, Authenticator: 00000000000000000000000000000000
  User-Name Attribute (1), length: 9, Value: 0000000
    0x0000:  3030 3030 3030 30
  User-Password Attribute (2), length: 18, Value: 
    0x0000:  3030 3030 3030 3030 3030 3030 3030 3030
  NAS-IP-Address Attribute (4), length: 6, Value: 127.0.0.1
    0x0000:  7f00 0001
  NAS-Identifier Attribute (32), length: 11, Value: localhost
    0x0000:  6c6f 6361 6c68 6f73 74 out slot1/tmm0 lis=

And its (valid) 'bugger off' answer:

Access-Reject (3), id: 0x00, Authenticator: xxxxxxxxxxxxxxxxxxxxxxxx in slot1/tmm0 lis= 

Here's the UDP hex strings to send & expect: Send:

\x01\x00\x00\x40\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x09\x30\x30\x30\x30\x30\x30\x30\x02\x12\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x04\x06\x7f\x00\x00\x01\x20\x0b\x6c\x6f\x63\x61\x6c\x68\x6f\x73\x74

Expect:

\xcc\xb4\x64\x08\x5e\x35\x2c\xaf\x85\x0f\x26\x42\x21\x51\x6a\xaf

Works a treat.

BR Jan

Hi Jan,

 

Awesome idea to construct the payload of a NULL-User Radius request. Thumps up for that one!

 

Note: The expect-string seems to trigger on the (encrypted) Response Authenticator field (16bytes), so other peers would need to know your Shared-Key to adopt this solution. Looking for a sequence of \x03\x00\x00 (responce code, request id, first byte of the length field) should be a slightly more generic approach.

 

Cheer, Kai