userid to ip mapping - F5 APM

I have been working on the irule as we have been having this issue with Mac users. This is what we came up with that didn't constantly log against the F5. It does still check about every 10 seconds so we are going to be watching our production F5s to ensure we do not start overloading with roughly 5k users a day.

when CLIENT_ACCEPTED {
ACCESS::restrict_irule_events disable
set hsl1 [HSL::open -proto UDP -pool pool_hsl_palo-uid-1]
set hsl2 [HSL::open -proto UDP -pool pool_hsl_palo-uid-2]
}
when HTTP_REQUEST {
if { [HTTP::uri] starts_with "/vdesk/timeoutagent-i.php" } {
set vpnip [ACCESS::session data get "session.assigned.clientip"]
if { $vpnip != "" }{
set user [ACCESS::session data get "session.logon.last.username"]
set domain [ACCESS::session data get "session.logon.last.domain"]
#if pa-vpn table entry for ip does not equal the current user we need to update the firewall#
if { [table lookup -notouch "pa-vpn:$vpnip"] != $user } {
HSL::send $hsl1 "<190>F5_PA_UID_Event uid:$domain\\$user; vpnip:$vpnip;\n"
HSL::send $hsl2 "<190>F5_PA_UID_Event uid:$domain\\$user; vpnip:$vpnip;\n"
log local0. "periodic: F5_PA_UID_Event uid:$domain\\$user; vpnip:$vpnip;"
table set pa-vpn:$vpnip $user 600
}
}
}
}
when ACCESS_SESSION_CLOSED {
set hsl1 [HSL::open -proto UDP -pool pool_hsl_palo-uid-1]
set hsl2 [HSL::open -proto UDP -pool pool_hsl_palo-uid-2]
set vpnip [ACCESS::session data get "session.assigned.clientip"]
if { $vpnip != "" }{
set user [ACCESS::session data get "session.logon.last.username"]
set domain [ACCESS::session data get "session.logon.last.domain"]
HSL::send $hsl1 "<190>F5_PA_LOGOUT_Event uid:$domain\\$user; vpnip:$vpnip;\n"
HSL::send $hsl2 "<190>F5_PA_LOGOUT_Event uid:$domain\\$user; vpnip:$vpnip;\n"
log local0. "periodic: F5_PA_LOGOUT_Event uid:$domain\\$user; vpnip:$vpnip;"
table delete pa-vpn:$vpnip
table delete pa-vpn:$user
}
}

Mostly unrelated but if the IP and user are tracked on the BigIP, why do you need to track them on the PAN as well? Is this another case of worthless security teams needing to feel valuable? ;)

We are a very small networking team and sometimes coordinating access policy requirements across multiple platforms is tedious. Consolidating access policy to a central point will provide a clearer picture of what is and isn't allowed.

Mostly unrelated I find your comment worthless.

I wouldn't be overly concerned about performance with this iRule, once every 10 seconds is not a lot but it depends on what else your system is doing. However there are things you can do to make your code more efficient.

For example, it's more expensive to set variables using the iRule namespace to make your code more readable. It's more efficient to execute the iRule commands when you need them:

if { [HTTP::uri] starts_with "/vdesk/timeoutagent-i.php" } {
     set removed - added directly to 'if'
    log local0. "timeout beacon received"
    if { [ACCESS::session data get "session.assigned.clientip"] != "" }{
    .
    .
    .. etc

Have a look here if you're interested in optimization:

https://devcentral.f5.com/articles/irules-optimization-101-05-evaluating-irule-performance

You could also configure a flag so that logging only happens when the flag is set so to avoid needless logging and computer resource

Sorry to bring this thread up from the dead, but I've run into the exact same issue. Our iRule works perfectly for regular TLS connections, but I'm unable to apply the iRule to the DTLS virtual server due to the fact that I can't apply an HTTP profile to a UDP based server. I get the following error when trying to apply the iRule:

01071912:3: HTTP_REQUEST event in rule (/Common/VPN_UserID) requires an associated HTTP or FASTHTTP profile on the virtual-server (/Common/VPN-POC-DTLS).

To get around this, I tried using "ACCESS_POLICY_COMPLETED", but receive this:

01071912:3: ACCESS_POLICY_COMPLETED event in rule (/Common/VPN_UserID_DTLS) requires an associated ACCESS profile on the virtual-server (/Common/VPN-POC-DTLS).

Again, I'm unable to associate an access profile to the virtual server due to it being UDP.

Does anyone know if something has changed recently that would disallow this config or am I possibly missing something? We are running 13.1.1.3.

Nice irule as sending the data to a logging server seems the best solution. I am also considering to use the artcile below to statically assign IP addresses using "Framed-IP-Address attribute" and see if the AD can inform the firewalls about the IP address of the user https://support.f5.com/csp/article/K13024 .

If you managed to get the needed answers, please flag the question as answered.