Forum Discussion
Access policy, LTM policy and iRules
- Jan 09, 2024
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:
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:
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.
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:
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:
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.
brilliant !
Thnak you for your time 🙂
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com