Creating a proper RADIUS Accounting-Response packet in iRules
Creating a proper RADIUS Accounting-Response packet in iRules If you do a lot of work with RADIUS messages being sent to your BIGIP so that you can get some information from another network node in the system, you are going to need to respond back to that node in a correct and proper way, so that you don’t mess it up, or otherwise fill up its error log with ‘improper response’ messages. I was working on just that kind of iRule, and got it working. Here’s the code: 1: 2: RADIUS Acct-Resp packet 3: 4: input variables: 5: $rId -> RADIUS Request ID field 6: $rAuth -> RADIUS Request Authorization field 7: $static::SHARED_SECRET -> RADIUS Shared secret of the 2 nodes. 8: 9: UDP::drop ; kill the incoming packet, don’t need it. 10: set RADcode 5 ; RADIUS Accounting-Response Type code. 11: set md5hash [ format "05%02x00%02x" $rId 20 ] 12: set md5hash $md5hash$rAuth$static::SHARED_SECRET 13: set hash [ binary format H* $md5hash ] 14: set respAuth [md5 $hash] 15: set payldhdr [ binary format ccS $RADcode $rId 20 ] 16: set payload $payldhdr$respAuth 17: UDP::respond $payload So the RADIUS Accounting-Response packet has, at a minimum, four fields: RADIUS Type code(1 byte), ID number(1 byte), Packet Length(2 byte Integer), and the Authenticator(16 bytes). Getting the response authenticator correct is really the only tricky part. Line 5: The RADIUS Request ID field comes from the incoming packet. You can retrieve this value previously in the iRule using a line of code like this: set rId [RADIUS::id]. Of course, this value can also be pulled out at the same time some other important fields are decoded using the sample code for line 6 below. Line 6: The RADIUS Request Authorization field in the incoming packet is an MD5 hash of most if the incoming packet. To get this value, you will need to do a binary scan of the UDP packet: set payload [UDP::payload] binary scan $payload ccSH32a* rType rId rLen rAuth rPkt In this example, we also pull out the Type Code (rType) and the packet ID (rId), the length of the overall packet, the Authorization field that we are looking for, and the rest of the packet, which should be all the AVP fields. Line 9: We don’t need (and usually don’t want) the RADIUS Request packet from going on from the BIGIP, so we just drop the packet to prevent this. Line 10: 0x05 is the RADIUS Type Code for an Account-Response packet. Line 11: Here’s where we start working on our response authenticator. We are going to setup a hexstring (which is hex characters displayed as a string; IE> “05140016” is four bytes 0x05, 0x14, 0x00, 0x16), pack all of our values into it, convert it to real binary hex, do the MD5 hash on the result, and use the MD5 checksum result in the response packet. This line sets Type Code, id, and Length (hard coded to 20 bytes). Line 12: Using the hexstring from the last line, it adds the Original request Authenticator, and the shared secret (which should already be in hexstring format) to it. We now have our complete hexstring that needs to be run through the MD5 checksum function. Line 13: This line simply converts the hexstring to a binary hex value. Line 14: We get our valid Authenticator for the response. Line 15: Now we create the actual response packet. This line sets the first three fields: Type Code, id, and Length. Line 16: We add the header and the response Authenticator and we have our RADIUS Accounting-Response packet. Line 17: Send the response back. The RADIUS Accounting-Response protocol is documented in RFC-2866, Section 4.2.How to decode the five different data types in a RADIUS packet
How to decode the five different data types in a RADIUS packet When a handset device on a cellular carrier turns on, usually a RADIUS packet is generated and sent out to a number of different network nodes to let them know that the handset device is on and about to access services of the wireless network. In some of those networks, F5 BIGIP devices also receive this RADIUS packet so that they too can get ready to handle network traffic from the handset device. Some times the BIGIP will query some sort of AAA or Policy servers to see if the handset device is allowed to connect to nodes beyond the BIGIP, and needs some of the information contained in the RADIUS packet in order to do the query. Here’s how to pull that information out within iRules. RADIUS packets have five official data types: Integer, Text, String, IPAddress, and Time. These are defined in the RADIUS standards (RFC-2865, RFC-2866, among others). “String” can be something of a misnomer, as it can contain binary data. “Text” is used for textual, printable, strings (I.E. UTF-8 encoded characters). Of these five types, only Text can be used without modification or checks. Here’s how to decode the other four: Integer -- One would think that you could use Integer types without modification, but there is one subtle gotcha. RADIUS integers are “unsigned”, meaning they are always positive. iRules integers are signed – the left-most bit is used as a flag to denote positive and negative numbers. If the left-most bit is set, then the number is negative. So in some cases, the numbers coming from RADIUS may show up as negative, rather than positive, numbers. You just need to make sure this left-most bit is unset: set acctAuthen [RADIUS::avp 45 "integer"] set acctAuthen [expr { $acctAuthen && 0xff }] if { $static::DEBUG eq 1 && $acctAuthen != "" } { puts "Acct-Authentic: $acctAuthen" } String -- Since iRules can handle non-UTF-8 bytes in its string type, there is no issue using what you get from the RADIUS packet without modification. The problem comes if you want to print out or otherwise log the contents of the String when its holding binary data. This can be done using a simple binary scan command: set acctSessId [RADIUS::avp 44 "string"] binary scan $acctSessId H* acctSessId if { $static::DEBUG eq 1 && $acctSessId != "" } { puts "Acct-Session-Id: $acctSessId" } In /var/log/tmm: … local/bigipfw notice Acct-Session-Id: ff082000 IPAddress -- Or “address” as its referenced in the spec. This is almost always an IPv4 address. When you retrieve this avp, you get a four-byte string, with the four octets of an IPv4 address. It’s pretty simple to decode: set a1 [RADIUS::avp 8 "ipaddr"] ; network byte order binary scan $a1 cccc a b c d set a [expr { $a & 0xff }] ; make unsigned values set b [expr { $b & 0xff }] set c [expr { $c & 0xff }] set d [expr { $c & 0xff }] set frmdIPAddr "$a.$b.$c.$d" if { $static::DEBUG eq 1 & $frmdIPAddr != "" } { puts "Framed-IP-Address: $frmdIPAddr" } Time -- These values are stored as a four-byte “epoch” value (this is, the number of seconds since July 1, 1970… which I believe was the next closest start of the month at the time the programmer who wrote the procedure, wrote it). Give that iRules is derived from the TCL programming language, we are lucky in that TCL has built in functions to manipulate this value and print out a date/time format that we can use: set eventTimestamp [RADIUS::avp 55 "integer"] set timest [clock format $eventTimestamp -format {%a %b %d %Y %H:%M:%S}] if { $static::DEBUG eq 1 && $timest != "" } { puts "Event-Timestamp: $timest" } More information about the RADIUS:: iRules commands can be found .
F5 LTM AS A FORWARD PROXY/TMG REPLACEMENT FOR HTTP/HTTPS FOR MOBILE USERS
How can the F5 be used as a Forward Proxy for mobile users to the internet. My initial setup included the mobile users sending requests to F5,which sends requests to Traffic Servers,and Traffic servers have another leg which sends requests to the internet. The traffic servers however are capping (capacity),and so,there is a requirement for the F5 to be used as a FORWARD PROXY for mobile users. Kindly list the steps to follow, e.g, 1,create standard virtual server, 2, use the irule HTTP Forward Proxy - v3.2 e.t.c Thanks
F5 SAML SP for a portion of a website
Let's say I have the following setup: a website called test.example.com an access policy called test_apol with SAML Auth If I assign the test_apol access policy to test.example.com VIP, the entire test.example.com becomes Service Provider (SP) and is protected by SAML Auth. Can I, and if yes then how, place only a portion of the website, i.e. a selected list of HTTP Paths/URIs behind SAML Auth, instead of the entire website? I.e. if test.example.com/private then SAML Auth, otherwise no restrictions. Just from top of my head, I was thinking about placing an iRule Event in front of SAML Auth; and inside iRule do the filtering of which HTTP Paths/URIs I want to send to SAML for authentication, and which ones just straight to the back-end servers without any authentication: However, I don't know whether this is the best approach to address my problem, or there is a better more elegant solution. Any ideas, suggestions, recommendations to address this are much appreciated.Configuring Active Directory authentication
Hello , Need some help Setting up F5 SSO Solution , in this scenario F5 to act as an Identity Provider. Following the SSO document https://support.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-saml-config-guide-11-3-0/3.html Stuck at the point Configuring an access policy to provide authentication from the local IdP Willing to use Active Directory Authentication Configuring an access policy to provide authentication from the local IdPConfigure an access policy so that this BIG-IP systems (as an IdP) can provide authentication for SAML service providers. On the Main tab, click Access Policy > Access Profiles. The Access Profiles List screen opens. In the Access Policy column, click the Edit link for the access profile you want to configure to launch the visual policy editor. The visual policy editor opens the access policy in a separate screen. Click the (+) sign anywhere in the access policy to add a new action item. An Add Item screen opens, listing Predefined Actions that are grouped by General Purpose, Authentication, and so on. I do not see an EDIT option here at the Access Profiles , attached is the screen capture Just wondering what i missed here... Any help is greatly appreciated..!!!
Least Sessions balancing and Server restart
Hi, I am running F5 BigIp with 11.2.00 HF2. I am playing with the Diameter iApp and Least Sessions balancing policy. I have 3 servers in my setup and the following scenario: 1. 3 servers running and traffic balancer among these servers 2. 1 of the servers goes down and the new traffic is re-balanced to other servers (universal persistence in place) 3. After a while the server comes back, and Diameter monitor sets it up as the 'Available" one. What I am expecting in this situation is, that new sessions will be routed to this new server, which was restored, but this is not a case. I check the Round Robin and it in general, it was quite fine. I saw some time ago the information, that actually due to different bugs, for Diameter only teh Round Robin policy is really working. Is this still a case? Did you have similar experiences with F5 and Diameter traffic balancing? Rgds, DeeNHello!
My name is John Allen, and I am a Solutions Engineer here at F5 focusing on Telecom and what we call Service Providers (as in, they provide a service like Internet, TV, Messaging, Phone, etc.). I have worked in this area for the last 15 years or so, both for Mobile Operators like AT&T Mobility, and for the Mobile Operator's messaging vendors like Openwave, Nokia-Siemens Networks, Acision, and others. I am also an experienced programmer, and I am currently having fun with the new Ruby Gem for iControls! If you have questions about how F5 products and services work in a Telecom or "Service Provider" environment, please feel free to ask here. F5 is spending a lot of time and effort to hire people like me to help you be successful with your Telecom and Service Provider environments! John
