Radius acct/auth monitor issue

Your mileage may vary with this approach, but in the spirit of "anything is possible with iRules", here's something that I cooked up to allow you to add the Proxy-State attribute to the Access-Request message with an iRule. The first thing you need to do is to create a new (internal) virtual server listening on your Radius Auth port (1645?) and assign it the Radius server pool. Also make sure it is using the UDP protocol and a SNAT profile (automap will work). Create a new Radius server pool that points to this virtual server and apply your standard Radius monitor here. So the new pool (with Radius monitor) will point to a virtual server, which will load balance the real Radius servers. In this virtual server you'll add the following iRule:

 

 

when CLIENT_ACCEPTED {
      convert the UDP payload to a HEX string
     binary scan [UDP::payload] H* payload

      create the additional payload (211e + 28 bytes of Proxy-State value)
      21 = type (33)
      1e = length (30 total bytes)
     set addpayload "211e0102030405060708090A0B0C0D0E0F101112131415161718191A1B"
 
      concatenate the two HEX strings
     set newpayload $payload$addpayload

      replace the Access-Request packet length value to match new (longer) length
      add 30 bytes to original value
     scan [string range $newpayload 4 7] %x old_length
     set new_length [format %04X [expr $old_length + 30]]
     set newpayload [string replace $newpayload 4 7 $new_length]

      format the HEX string for binary insertion
     set replacepayload [binary format H* $newpayload]

      replace the entire original payload contents
      unlike TCP, UDP has no "collect" or "release"
     UDP::payload replace 0 [UDP::payload length] " "
     UDP::payload replace 0 0 $replacepayload
}

 

 

The idea is that the standard Radius monitor traffic assigned to the (external) pool will pass through the (internal) virtual server where this iRule can modify its values in transit. This code was developed against a VERY simple Radius environment and the following references, so again your mileage may vary (ie. some tweaking may be required).

 

http://freeradius.org/rfc/rfc2865.htmlProxy-State

 

http://portmasters.com/tech/docs/radius/proxy.html

 

Your mileage may vary with this approach, but in the spirit of "anything is possible with iRules", here's something that I cooked up to allow you to add the Proxy-State attribute to the Access-Request message with an iRule. The first thing you need to do is to create a new (internal) virtual server listening on your Radius Auth port (1645?) and assign it the Radius server pool. Also make sure it is using the UDP protocol and a SNAT profile (automap will work). Create a new Radius server pool that points to this virtual server and apply your standard Radius monitor here. So the new pool (with Radius monitor) will point to a virtual server, which will load balance the real Radius servers. In this virtual server you'll add the following iRule:

 

 

when CLIENT_ACCEPTED {
      convert the UDP payload to a HEX string
     binary scan [UDP::payload] H* payload

      create the additional payload (211e + 28 bytes of Proxy-State value)
      21 = type (33)
      1e = length (30 total bytes)
     set addpayload "211e0102030405060708090A0B0C0D0E0F101112131415161718191A1B"
 
      concatenate the two HEX strings
     set newpayload $payload$addpayload

      replace the Access-Request packet length value to match new (longer) length
      add 30 bytes to original value
     scan [string range $newpayload 4 7] %x old_length
     set new_length [format %04X [expr $old_length + 30]]
     set newpayload [string replace $newpayload 4 7 $new_length]

      format the HEX string for binary insertion
     set replacepayload [binary format H* $newpayload]

      replace the entire original payload contents
      unlike TCP, UDP has no "collect" or "release"
     UDP::payload replace 0 [UDP::payload length] " "
     UDP::payload replace 0 0 $replacepayload
}

 

 

The idea is that the standard Radius monitor traffic assigned to the (external) pool will pass through the (internal) virtual server where this iRule can modify its values in transit. This code was developed against a VERY simple Radius environment and the following references, so again your mileage may vary (ie. some tweaking may be required).

 

http://freeradius.org/rfc/rfc2865.htmlProxy-State

 

http://portmasters.com/tech/docs/radius/proxy.html

 

just wondering if health monitor packet is static. if so, is udp monitor with static send and receive string usable?

The Radius Access-Request message from the health monitor is not static, but fairly predictable. In fact the Packet Identifier and Authenticator values will always change. The content length is the 3rd and 4th bytes, and the new payload is simply added to the end of the existing (dynamic) payload (with content length adjusted for additional data).

Thanks a lot Kevin.

 

Meanwhile I've workaround with and external monitor perl script, that send a converted UDP payload to both the real radius server.

 

But your suggestion is very interesting. I will discuss with my dev team.

 

 

ciao!

 

Fra

Please share your Perl script!!