Forum Discussion

daboochmeister's avatar
Mar 02, 2015

APM swallowing JSESSIONID cookie; workaround possible by copying cookie to return stream?

Hi, all - we have a layer 7 VIP secured with an APM policy. The VIP proxies to a Tomcat server, which returns a JSESSIONID cookie after user logon. Sporadically, the F5 does not return the JSESSIONID to the client; it will be working fine for a a few days, then it will kick into a mode where users logon but don't have a Tomcat session tracked to their logon, because they simply don't have a JSESSIONID cookie anymore to send with their next request.

 

This is similar to what was noted by Davo T, here: https://devcentral.f5.com/questions/apm-sso-config-using-kerberos-to-weblogic-backend-not-supplying-session-id-cookie-on-post-authentication-requests

 

I'm working this as a case with F5 - but while it's being worked, is there a reliable way to script an explicit copying of the JSESSIONID cookie from the returned stream from the real server, before APM gets its hands on it, then insert it into the reply after APM is done processing? What events would I reference in an iRule to accomplish that? I'm not super familiar with the APM-related event lifecycle, and how it expresses itself in iRules.

 

In case it matters, the policy in question does the following: - presents a login page, obtains userid, RSA PIN/Code - RADIUS auths against an RSA server - checks a RADIUS filter-id attribute value - checks the URL against an ACL

 

Thank you!

 

  • Sorry, I should have mentioned this is with APM 11.5.1, on a Big-IP 4200v in an active/standby HA config.

     

  • I don't think I can offer an answer to your first question, but regarding how the APM event flow happens, you can check out this article which has a flow chart depicting the APM event execution. That may help in figuring out a way to handle an iRule within that process.

     

  • Putting a close to this whole question - I did successfully implement the code to copy the JSESSIONID header from the incoming response to the outgoing response, in both directions - and it didn't fix the issue. It turns out there was another device between the F5 and the real servers - and that device was occasionally caching in an incorrect way. Once that caching behavior was fixed on that proxy, the issue disappeared.

     

    But it was an interesting effort, looking for it, and I certainly learned more about the event lifecycle - so there is that!