cancel
Showing results for 
Search instead for 
Did you mean: 

userid to ip mapping - F5 APM

Terry_77423
Altostratus
Altostratus

I have been wrestling with how I can share user to ip mappings for VPN connections with internal security devices(namely palo alto firewalls). I found a few great suggestions on here regarding leveraging an irule to accomplish this, and while they appeared to work, adding DTLS broke most of the examples provided.

 

reference: https://devcentral.f5.com/questions/userid-to-leasepool-ip-mapping

 

So I spent some time attempting to figure out how I could accomplish this with DTLS enabled and this is what I came up with:

 

when CLIENT_ACCEPTED { ACCESS::restrict_irule_events disable set hsl [HSL::open -proto UDP -pool hsl_pa-uid_pool] } when HTTP_REQUEST { if { [HTTP::uri] starts_with "/vdesk/timeoutagent-i.php" } { set vpnip [ACCESS::session data get "session.assigned.clientip"] log local0. "timeout beacon received" if { $vpnip != "" }{ set user [ACCESS::session data get "session.logon.last.username"] 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 $hsl "<190>F5_PA_UID_Event uid:$user vpnip:$vpnip\n" log local0. "periodic: F5_PA_UID_Event uid:$user vpnip:$vpnip" table set "pa-vpn:$vpnip" "$user" "indef" 600 } } } } when ACCESS_SESSION_CLOSED { set hsl [HSL::open -proto UDP -pool hsl_pa-uid_pool] set vpnip [ACCESS::session data get "session.assigned.clientip"] if { $vpnip != "" }{ set user [ACCESS::session data get "session.logon.last.username"] HSL::send $hsl "<190>F5_PA_LOGOUT_Event uid:$user vpnip:$vpnip\n" log local0. "periodic: F5_PA_LOGOUT_Event uid:$user vpnip:$vpnip" } }

My only concern with this implementation is performance impact. The /vdesk/timeoutagent-i.php happens every 10 seconds or so, which means the set vpnip [ACCESS::session data get "session.assigned.clientip"] and [table lookup -notouch "pa-vpn:$vpnip"] will also occur.

 

Is my concern warranted? Is there possibly a better implementation out there? Any possible alleys that I might have missed?

 

7 REPLIES 7

ekaleido
Nimbostratus
Nimbostratus

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? 😉

 

Terrence
Nimbostratus
Nimbostratus

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.

 

Lee_Sutcliffe
Nacreous
Nacreous

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

 

Ryan_M_362715
Altocumulus
Altocumulus

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.

 

Edit... disregard. The iRule has to stay on the TCP/443 virtual server. My issue was that DTLS does not use the "/myvpn?sess=" URL. Changed to "/vdesk/timeoutagent-i.php" as mentioned by Terry and we are good to go.

 

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 .

jtlampe
MVP
MVP

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
}
}