Forum Discussion
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:
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.
- Lucas_ThompsonEmployee
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.
- Nico_the_otherAltocumulus
brilliant !
Thnak you for your time 🙂 - JRahmAdmin
A master class response there...thank you Lucas_Thompson!!
- srirNimbostratus
Experts,
Below is my setup.
Oauth provider -mapped to- Oauth Server
Oauth server > mapped to -- APM policy
APM policy > mapped to -- Virtual server
Virtual server > mapped to pool
All components looking good. When i tirgger the SSO enabled URL it never loads APM policy..
any inputs appreciated
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