Forum Discussion

Nico_the_other's avatar
Nico_the_other
Icon for Altocumulus rankAltocumulus
Jan 09, 2024
Solved

Access policy, LTM policy and iRules

Hello,

A short one for you  🙂

I understood LTM policy and iRules precedence : LTM policies are inspected BEFORE iRules (in Layer 7 context), but what's happens when you Virtual Server has also (in Access Policy) an Access Profile configured ?

  • You can view the "hudchain" precedence order by toggling the "tmm.verbose" DB variable:

    [admin@west:LICENSE EXPIRES IN 2 DAYS:ModuleNotLicensed::Acti*:Standalone] ~ # tmsh modify sys db tmm.verbose value enable
    [admin@west:LICENSE EXPIRES IN 2 DAYS:ModuleNotLicensed::Acti*:Standalone] ~ # tmsh list sys db tmm.verbose
    sys db tmm.verbose {
    value "enable"
    }

    then making a change to the virtual (this virtual has only HTTP and TCP profiles). Satellite is a special one used for buffering chunk-transfer-mode HTTP data, and you can ignore it:

    [admin@west:LICENSE EXPIRES IN 2 DAYS:ModuleNotLicensed::Acti*:Standalone] ~ # tail --lines=0 -f /var/log/tmm 
    <13> Jan 9 09:55:50 west notice (L:/Common/user107) hn :TCP -> SSL -> HTTP -> SATELLITE -> <TCP> <- SATELLITE <- HTTP <- TCP:

    An Access virtual with a VPN (connectivity) profile on it is much more complicated:

    <13> Jan 9 10:01:02 west notice (L:/Common/user107) hn :TCP -> SSL -> L7CHECK -> ISESSION -> HTTP -> INFLATE -> ACCESS -> ACCESS2 -> APM::RBA -> RAMCACHE -> APM::WEBSSO -> APM::SSO -> GZIP -> VPN -> SATELLITE -> <TCP> <- SATELLITE <- VPN <- APM::SSO <- APM::WEBSSO <- APM::RBA <- ACCESS <- ACCESS2 <- INFLATE <- HTTP <- L7CHECK <- TCP:

    The left-side arrow represents the path to the client. The right-side represents the path to the server, and each side of the flow is a separate TCP connection. In this way, BIG-IP is a "full L7 proxy", and you can see the processing-order here. iRule and LTM policy events for SSL or HTTP or TCP, etc, fire within their respective hudchain nodes. 

    There is a video available that discusses some of this architectural stuff:

    https://community.f5.com/t5/technical-articles/lightboard-lessons-big-ip-life-of-a-packet/ta-p/287794

     

     

    A few gotchas: Access has a special mechanism where it can "silence" iRules so that events such as HTTP_REQUEST are not fired for "access session maintenance" URLs like executing the access policy. I'm not sure off the top of my head if this also applies to LTM Policies, but it probably does. You can turn that silencing off using this technique:

    https://clouddocs.f5.com/cli/tmsh-reference/v14/modules/ltm/ltm_rule_command_ACCESS_restrict_irule_events.html

    A discussion on that is here:

    https://community.f5.com/t5/technical-forum/access-restrict-irule-events-disable/td-p/266395

    Another thing that might be helpful is that when you use iRule events (ACCESS_POLICY_AGENT_EVENT) inside of Per-Session Access Policies, the flow that the iRule is operating on is NOT that of the user (Client to TMM), but instead it's the flow of TMM to APMD. So you can't really operate on the IP, TCP, or HTTP data there. You CAN operate on the flow data using ACCESS_ACL_ALLOWED.

    Hope this helps.

     

     

3 Replies

  • You can view the "hudchain" precedence order by toggling the "tmm.verbose" DB variable:

    [admin@west:LICENSE EXPIRES IN 2 DAYS:ModuleNotLicensed::Acti*:Standalone] ~ # tmsh modify sys db tmm.verbose value enable
    [admin@west:LICENSE EXPIRES IN 2 DAYS:ModuleNotLicensed::Acti*:Standalone] ~ # tmsh list sys db tmm.verbose
    sys db tmm.verbose {
    value "enable"
    }

    then making a change to the virtual (this virtual has only HTTP and TCP profiles). Satellite is a special one used for buffering chunk-transfer-mode HTTP data, and you can ignore it:

    [admin@west:LICENSE EXPIRES IN 2 DAYS:ModuleNotLicensed::Acti*:Standalone] ~ # tail --lines=0 -f /var/log/tmm 
    <13> Jan 9 09:55:50 west notice (L:/Common/user107) hn :TCP -> SSL -> HTTP -> SATELLITE -> <TCP> <- SATELLITE <- HTTP <- TCP:

    An Access virtual with a VPN (connectivity) profile on it is much more complicated:

    <13> Jan 9 10:01:02 west notice (L:/Common/user107) hn :TCP -> SSL -> L7CHECK -> ISESSION -> HTTP -> INFLATE -> ACCESS -> ACCESS2 -> APM::RBA -> RAMCACHE -> APM::WEBSSO -> APM::SSO -> GZIP -> VPN -> SATELLITE -> <TCP> <- SATELLITE <- VPN <- APM::SSO <- APM::WEBSSO <- APM::RBA <- ACCESS <- ACCESS2 <- INFLATE <- HTTP <- L7CHECK <- TCP:

    The left-side arrow represents the path to the client. The right-side represents the path to the server, and each side of the flow is a separate TCP connection. In this way, BIG-IP is a "full L7 proxy", and you can see the processing-order here. iRule and LTM policy events for SSL or HTTP or TCP, etc, fire within their respective hudchain nodes. 

    There is a video available that discusses some of this architectural stuff:

    https://community.f5.com/t5/technical-articles/lightboard-lessons-big-ip-life-of-a-packet/ta-p/287794

     

     

    A few gotchas: Access has a special mechanism where it can "silence" iRules so that events such as HTTP_REQUEST are not fired for "access session maintenance" URLs like executing the access policy. I'm not sure off the top of my head if this also applies to LTM Policies, but it probably does. You can turn that silencing off using this technique:

    https://clouddocs.f5.com/cli/tmsh-reference/v14/modules/ltm/ltm_rule_command_ACCESS_restrict_irule_events.html

    A discussion on that is here:

    https://community.f5.com/t5/technical-forum/access-restrict-irule-events-disable/td-p/266395

    Another thing that might be helpful is that when you use iRule events (ACCESS_POLICY_AGENT_EVENT) inside of Per-Session Access Policies, the flow that the iRule is operating on is NOT that of the user (Client to TMM), but instead it's the flow of TMM to APMD. So you can't really operate on the IP, TCP, or HTTP data there. You CAN operate on the flow data using ACCESS_ACL_ALLOWED.

    Hope this helps.