Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

RADIUS::avp causes invalid signature on the RADIUS server

Hi,

I have a RADIUS VServer that intercepts Radius requests and send them to a RADIUS pool member.

Once a Radius Accounting request is received by this VServer, I insert an AVP and send it to the pool member, this is achieved by using the following line in my IRule:

RADIUS::avp insert 8 $leasedip ip4

Unfortunately when the RADIUS pool member receives this modified RADIUS packet, it discards it:

[]Received Accounting-Request packet from client 4.4.4.4 with invalid signature! (Shared secret is incorrect.) Dropping packet without response.Going to the next request

Although the error message says the shared secret is incorrect, it is not the case, if I send the same request without RADIUS::avp insert 8 $leasedip ip4 then RADIUS stops complaining about the shared secret.

Do you know what's happening ? is inserting the AVP corrupting the packet ?

Thanks

1
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

is framed-ip-address' shared secret (in radius server configuration) correct indeed?

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Hi,

thanks for your answer, it turns out that the authenticator needs to be recalculated after AVP::insert and should replace the original one in the RADIUS payload.

https://devcentral.f5.com/questions/radius-irule-to-insert-vendor-attributes

I have it working now.

Thx

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Hi kt77,

It looks like you have a case where the RADIUS Accounting server is strictly checking the Request Authenticator field. Please have a look at Page #7 of RFC 2866.

In this case, the iRule needs to change the value of the Request Authenticator field after the insertion is conducted. This require the shared secret to be written in the iRule.

I never encounter such strict RADIUS server in my experience before but the following untested iRule should raise some ideas:

when RULE_INIT {
  set static::seckey "this is the shared secret"
}

when CLIENT_DATA {
  RADIUS::avp insert 8 $leasedip ip4
  binary scan [UDP::payload] H2H2x36H* rad_code rad_pid rad_attrs
  set a [binary format H*H*H*H*H*a* $rad_code $rad_pid [UDP::payload length] 00000000000000000000000000000000 $rad_attrs $static::seckey]
  UDP::payload replace 0 [UDP::payload length] [binary format a*@4a16 [UDP::payload] [md5 $a]]
}

Good luck...

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

nat and joko are absolutely correct. i did a bit test joko's rule as below.

root@(ve11a)(cfg-sync Changes Pending)(Active)(/Common)(tmos)# list ltm virtual bar
ltm virtual bar {
    destination 172.28.20.111:1813
    ip-protocol udp
    mask 255.255.255.255
    pool foo
    profiles {
        udp { }
    }
    rules {
        nat_rule
    }
    source 0.0.0.0/0
    source-address-translation {
        type automap
    }
    vs-index 2
}
root@(ve11a)(cfg-sync Changes Pending)(Active)(/Common)(tmos)# list ltm rule nat_rule
ltm rule nat_rule {
    when CLIENT_DATA {
  set secret "secret"

  RADIUS::avp insert 8 "2.2.2.2" ip4

  binary scan [UDP::payload] a1a1a2a16a* code id len auth attrs
  set zero "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
  set newauth [md5 "${code}${id}${len}${zero}${attrs}${secret}"]
  UDP::payload replace 4 16 $newauth
}
when SERVER_DATA {
  binary scan [UDP::payload] a1a1a2x16a* code id len attrs
  set newrespauth [md5 "${code}${id}${len}${auth}${attrs}${secret}"]
  UDP::payload replace 4 16 $newrespauth
}
}

# test

[root@client1 ~]# echo "Acct-Status-Type=1,NAS-IP-Address=1.1.1.1,Calling-Station-Id=1234567890" |radclient -c 1 172.28.20.111 acct secret
Received response ID 254, code 5, length = 20
root@(ve11a)(cfg-sync Changes Pending)(Active)(/Common)(tmos)# list ltm virtual bar
ltm virtual bar {
    destination 172.28.20.111:1813
    ip-protocol udp
    mask 255.255.255.255
    pool foo
    profiles {
        udp { }
    }
    rules {
        joko_rule
    }
    source 0.0.0.0/0
    source-address-translation {
        type automap
    }
    vs-index 2
}
root@(ve11a)(cfg-sync Changes Pending)(Active)(/Common)(tmos)# list ltm rule joko_rule
ltm rule joko_rule {
    when RULE_INIT {
  set static::seckey "secret"
}
when CLIENT_DATA {
  RADIUS::avp insert 8 "2.2.2.2" ip4

  binary scan [UDP::payload] H2H2x2H32H* rad_code rad_pid rad_auth rad_attrs
  set a "[binary format H*H*SH*H*a* $rad_code $rad_pid [UDP::payload length] 00000000000000000000000000000000 $rad_attrs $static::seckey]"
  UDP::payload replace 4 16 [md5 $a]
}
when SERVER_DATA {
  binary scan [UDP::payload] H2H2x18H* rad_code rad_pid rad_attrs
  set b "[binary format H*H*SH*H*a* $rad_code $rad_pid [UDP::payload length] $rad_auth $rad_attrs $static::seckey]"
  UDP::payload replace 4 16 [md5 $b]
}
}

# test

[root@client1 ~]# echo "Acct-Status-Type=1,NAS-IP-Address=1.1.1.1,Calling-Station-Id=1234567890" |radclient -c 1 172.28.20.111 acct secret
Received response ID 2, code 5, length = 20
0