Security

Reply
Contributor II

Administrator login to PAN using CPPM behind F5 load balancer

We already are load balancing 802.1X through our F5 load balancing infrastructure and everything is working great. Now, we wanted to use RADIUS for administrator login to our PAN firewalls and Panarama and send those messages through our load balancer to the nearest/fastest CPPM. We cannot use TACACS+ because it is not supported before PAN-OS version 8 for non-local admin login.

 

Everything works fine when PAN points directly to ClearPass, but not when pointing to the LTM VIP or GTM FQDN. So what was the problem?

Tim Haynie, ACMX #508, ACDX #384, ACCP, CWSP, CWAP, CWDP, CCNP R/S, CCNP Wireless, CCNA Security, CCDA
Contributor II

Re: Administrator login to PAN using CPPM behind F5

The issue came down to the iRule that was written when we first set up the LTM for 802.1X requests. In an 802.1X RADIUS message, we get an Attribute Value Pair (AV Pair, or AVP) for Calling-Station-ID (AVP 31). The iRule was written as though the Calling-Station-ID would always be present.

 

However, since we are not doing 802.1X, there was no Calling-Station-ID in the RADIUS message from the PAN since it is not relevant. This resulted in the iRule crapping out and the LTM dropping the packet. We descovered this by inspecting the /var/log/ltm log on the LTM, where we noticed errors relating to the "persist" statement, then went back to the Access Tracker in CPPM to confirm that Calling-Station-ID was not there at all in the PAN RADIUS request.

 

Thus, we needed to modify the stock TCL script provided in the Aruba document (http://www.arubanetworks.com/pdf/partners/CPPM_Load-Balancing_TechNote.pdf) to accomodate that sort of message.

 

Below is the modified TCL script:

 

when CLIENT_ACCEPTED {
    if { ([UDP::local_port] != 1812) && ([UDP::local_port] != 1813) } {
        #log local0. "packet on port [UDP::local_port] dropped"
        drop
    } else {
        if { not ( [RADIUS::avp 31 string] equals "") } { # Check to see if Calling Station ID (AVP 31) present. PAN does not use AVP 31 because it is not relevant.
            set CALLID [RADIUS::avp 31 string]
            persist uie $CALLID
            #log local0. "persisted $CALLID"
        }
        else { #Calling Station ID was not there; set CALLID to null
            set CALLID ""
            #log local0. "A non 802.1X RADIUS packet was received from [RADIUS::avp 4 ip4]"
                                                                             #AVP 4 is NAS IP Address
        }
    }
}

when CLIENT_DATA {
    if { [UDP::local_port] == 1813 } {
        set CALLID [RADIUS::avp 31 string]
        set IP [RADIUS::avp 8 ip4]
        if { $IP != "" } {
            table set $IP [LB::server addr] 900
            #log local0. "Radius maps $IP to [LB::server addr] for $CALLID"
        }
    }
}

when LB_SELECTED {
    #log local0. "Selected [LB::server addr] [LB::server port]"
}

when SERVER_DATA {
    if { $CALLID != "" } {
        persist add uie $CALLID
    }
    #log local0. "persist added for $CALLID to [LB::server addr]"
}

The only difference between this and the script provided by Aruba in the document mentioned above is that now we have added some logic to make sure that we actually got a Calling Station ID attribute. If it's not there, we ignore the persist statement and set the CALLID variable to a null string. We also check within the SERVER_DATA event to make sure CALLID is not null to avoid errors in the /var/log/ltm log.

Tim Haynie, ACMX #508, ACDX #384, ACCP, CWSP, CWAP, CWDP, CCNP R/S, CCNP Wireless, CCNA Security, CCDA
Contributor II

Re: Administrator login to PAN using CPPM behind F5 load balancer

The issue came down to the iRule that was written when we first set up the LTM for 802.1X requests. In an 802.1X RADIUS message, we get an Attribute Value Pair (AV Pair, or AVP) for Calling-Station-ID (AVP 31). The iRule was written as though the Calling-Station-ID would always be present.

 

However, since we are not doing 802.1X, there was no Calling-Station-ID in the RADIUS message from the PAN since it is not relevant. This resulted in the iRule crapping out and the LTM dropping the packet. We descovered this by inspecting the /var/log/ltm log on the LTM, where we noticed errors relating to the "persist" statement, then went back to the Access Tracker in CPPM to confirm that Calling-Station-ID was not there at all in the PAN RADIUS request.

 

Thus, we needed to modify the stock TCL script provided in the Aruba document (http://www.arubanetworks.com/pdf/partners/CPPM_Load-Balancing_TechNote.pdf) to accomodate that sort of message.

 

Below is the modified TCL script:

 

when CLIENT_ACCEPTED {
    if { ([UDP::local_port] != 1812) && ([UDP::local_port] != 1813) } {
        #log local0. "packet on port [UDP::local_port] dropped"
        drop
    } else {
        if { not ( [RADIUS::avp 31 string] equals "") } { # Check to see if Calling Station ID (AVP 31) present. PAN does not use AVP 31 because it is not relevant.
            set CALLID [RADIUS::avp 31 string]
            persist uie $CALLID
            #log local0. "persisted $CALLID"
        }
        else { #Calling Station ID was not there; set CALLID to null
            set CALLID ""
            #log local0. "A non 802.1X RADIUS packet was received from [RADIUS::avp 4 ip4]"
                                                                             #AVP 4 is NAS IP Address
        }
    }
}

when CLIENT_DATA {
    if { [UDP::local_port] == 1813 } {
        set CALLID [RADIUS::avp 31 string]
        set IP [RADIUS::avp 8 ip4]
        if { $IP != "" } {
            table set $IP [LB::server addr] 900
            #log local0. "Radius maps $IP to [LB::server addr] for $CALLID"
        }
    }
}

when LB_SELECTED {
    #log local0. "Selected [LB::server addr] [LB::server port]"
}

when SERVER_DATA {
    if { $CALLID != "" } {
        persist add uie $CALLID
    }
    #log local0. "persist added for $CALLID to [LB::server addr]"
}

The only difference between this and the script provided by Aruba in the document mentioned above is that now we have added some logic to make sure that we actually got a Calling Station ID attribute. If it's not there, we ignore the persist statement and set the CALLID variable to a null string. We also check within the SERVER_DATA event to make sure CALLID is not null to avoid errors in the /var/log/ltm log.

Tim Haynie, ACMX #508, ACDX #384, ACCP, CWSP, CWAP, CWDP, CCNP R/S, CCNP Wireless, CCNA Security, CCDA
Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: