Security

Hi Everyone,

I've configured our F5 using the F5 rules provided in the Aruba Load Balancing Technote. We are doing Wired NAC on Cisco IOS devices.

However we noticed that our switches mark the RADIUS servers as down after we added the 'automate-tester' command to the RADIUS servers. We want this command to validate the servers are up in a fail open scenario, as otherwise the RADIUS server flap every 5 minutes.

However after we added this we noticed the switch would mark the RADIUS servers as down. During troubleshooting in F5 we did some pcaps and found that when the 'cisco-user' test authentication arrived at F5, it dropped the request and did not proceed.

What we found was that the iRule appears to look for RADIUS AVP 31, calling-station-ID. However the automated-tester generate a RADIUS request without attribute 31. This appears to cause F5 to drop this packet instead. We updated the iRule in the lab to AVP 1, username, and after this the packets flow through.

I guess my question is, is there any issue with using the username as the persistence value instead of the calling station ID? I see the same username is in the authen and accounting packets. The only thing i can think of is that MAB and DOT1X requests would no longer get linked together.

Has anyone else come across this or similar problems?

Asside from this, it seems like the F5 is sending the authen and acconting packets to difference ClearPass nodes, but that is a sepearte problem we are following up with F5. However this automate-tester just didn't work at all with the Aruba provided iRule.

In most cases, the load balancer makes sure that services are always available and you don't need to worry on the client (NAD) side. If the connection between your switches and the load balancer might fail, it may make sense to check from the client side.

Personally, I would not move from the client mac (Calling-Station-ID) persistence, also as it should link the radius auth and accounting packets together. Please let us know what F5 found out on why that persistence doesn't work in your case.

As an alternative, you may either extend the iRule to check if the username is 'cisco-user' and select a different pool from there, or change from universal (iRule) to source IP persistence with a match across udp-1812 and udp-1813, which should work fine if you either have enough capacity to handle unequal load distribution on your ClearPass node, or if you have enough network access devices and don't need to support high volume of roaming between the NADs.

Unfortunately, my F5 knowledge has faded over time, so I can't assist with modifying the iRule.