Technical Forum
Ask questions. Discover Answers.
cancel
Showing results for 
Search instead for 
Did you mean: 

Load balancing the ISE services Radius and HTTPS

sudeep_patil_35
Nimbostratus
Nimbostratus

I'm trying to load balance the Cisco ISE services Radius and HTTPS service using the F5 LTM. To setup the irule i'm following the procedure given on the Cisco portal

 

https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/200317-F5-LTM-loadbalan...

 

For Guest portal authentication it is required to match Radius Authentication with HTTP session and ensure that they all land on the same Server.

 

In this guide they have given the irule for the Radius and HTTPS services but when i apply the Radius irule, F5 drops all the connections. It receives the connection but it doesn't forward the connection to pool members.

 

iRule code for Radius VS:

 

     adding persistence based on Calling-Station-ID
    when LB_SELECTED {
        log local0. "session table entry added: "
        session add uie "persist:[RADIUS::avp 31]" [LB::server addr]
    }

     lookup and adding persistence based on Framed-IP-Addr
    when CLIENT_ACCEPTED {
       log local0. "session table lookup result for calling station ID of [RADIUS::avp 31]: [session lookup uie "persist:[RADIUS::avp 31]"]"
        if {[session lookup uie "persist:[RADIUS::avp 31]"] ne ""} {
           log local0. "lookup match: [session lookup uie "persist:[RADIUS::avp 31]"]"
           node [session lookup uie "persist:[RADIUS::avp 31]"]
           log local0. "session table entry added: "
           session add uie "persist:[RADIUS::avp 8]" [session lookup uie "persist:[RADIUS::avp 31]"]  
       }
    }

iRule code for HTTP VS:

 

lookup based on client_addr expecting to match entry created based on Framed-IP-Addr
when HTTP_REQUEST {  
   log local0. "session table lookup result for web client of [IP::client_addr]: [session lookup uie "persist:[IP::client_addr]"]"
   if {[session lookup uie "persist:[IP::client_addr]"] ne ""} {  
      node [session lookup uie "persist:[IP::client_addr]"]  
   }  
} 

In the /var/log/ltm i can see the below errors

 

Aug 29 08:47:13 LB-01 info tmm[16932]: Rule /Common/RADIUS_VS : session table lookup result for calling station ID of b4-6b-fc-db
-13-1b:
Aug 29 08:47:13 LB-01 err tmm[16932]: 01220001:3: TCL error: /Common/RADIUS_VS  - More data required (line 1) (line 1) invoked from within "RADIUS::avp 31"

I have checked in the Radius server logs that Calling-Station-ID value is showing up in Radius server logs, not sure why iRule is giving error and dropping the traffic.

 

I'm newbie i'm still learning the iRule. Any help appreciated.

 

10 REPLIES 10

vasil_genov1
Nimbostratus
Nimbostratus

I am struggling with the same issue, if some one has a valid solution, it will be much appreciated.

Did anyone ever get this working?

Anonymous25
Nimbostratus
Nimbostratus

I am also running into this issue. Something has to have changed since that article was written. Additionally, the direct copy and paste of that iRule is as follows:

 

# adding persistence based on Calling-Station-ID when LB_SELECTED { log local0. "session table entry added: <persist:[RADIUS::avp 31] node [LB::server addr]>" session add uie "persist:[RADIUS::avp 31]" [LB::server addr] }   # lookup and adding persistence based on Framed-IP-Addr when CLIENT_ACCEPTED { log local0. "session table lookup result for calling station ID of [RADIUS::avp 31]: [session lookup uie "persist:[RADIUS::avp 31]"]" if {[session lookup uie "persist:[RADIUS::avp 31]"] ne ""} { log local0. "lookup match: [session lookup uie "persist:[RADIUS::avp 31]"]" node [session lookup uie "persist:[RADIUS::avp 31]"] log local0. "session table entry added: <persist:[RADIUS::avp 8] [session lookup uie "persist:[RADIUS::avp 31]"]>" session add uie "persist:[RADIUS::avp 8]" [session lookup uie "persist:[RADIUS::avp 31]"] } }

 

I believe the RADIUS commands are no longer allowed in the CLIENT_ACCEPTED events.

 

We solved the issue by doing priority groups to ensure that everything went to the same server.

​Can you share with us the TMSH output that fixed this Andrew Husking?

ltm pool iseportal { load-balancing-mode least-connections-node members { node1:8443 { address 1.1.1.1 } node2:8443 { address 2.2.2.2 priority-group 10 } } min-active-members 1 }

Here you go.

 

How does this solve the issue of carrying persistence from Radius auth/acct via MAC to the HTTPS redirect using IP?

 

Another way the phrase this is how did using priority groups solve the issue of persistence to make sure the client gets to the correct node to continue the session?

Because the nodes are in an active/standby configuration all traffic hit's the same PSN (unless during a failover scenario).

 

May not be ideal for all implementations but for us this hasn't caused any issues

Ah, that make more sense. We have a 5 node deployment (1 PAN, 1 MNT, 3 PSNs). We need to be able to load balance across the three PSNs on a static FQDN and keep persistence for those sessions. That is what this iRule is supposed to assist with (on LTM version 11.6).

 

As far as using Radius in Client_Accepted, this does still work. I have tested other iRules that use this format and they generate persistence records. Obviously, they have not been able to carry the persistence record from RADIUS client MAC address to HTTPS Client IP address to persist the sessions.

 

Thanks for providing your solution to the problem though!

Hi, I'm about to try to activate a similar configuration as well.

We're passing from Citrix Netscaler to F5 LTM and I'm using radius profile with persistence attribute 31, just like I had configured in netscaler.

Has anyone tested this before? Does it work as expected?

 

I have to mention we tried to go-live once already but VS seemed to receive no traffic from switches. The switches passed from seeing radius server from "DEAD" to "ACTIVE", but still all I could see on the loadbalancer with a tcpdump instance listening on udp port 1812 was F5 monitor traffic.

I've suspected the firewall *might* not have updated ARP entry for VS IP (we used the same addresses) so ethernet packets were crafted with bad destination mac, and this will be the first thing I'll check next time we try, but I was also wondering if anything on BIGIP configuration might be misfunctioning.