Forum Discussion

bohm_192937's avatar
bohm_192937
Icon for Nimbostratus rankNimbostratus
Nov 11, 2016

Cookie session persistence but webform post fails

Hello, Running a VIP on tcp/80 to balance 4 Linux webservers with cookie persistence (session based) enabled on the VIP. Around 15% of the webforms result in a 403 error on submit. CMS support suspect F5 persistence, but what is a good method to debug on the F5? Any tips much appreciated.

 

Main Package Product BIG-IP Version 11.5.4 Build 2.0.291 Edition Hotfix HF2 Date Thu Jul 21 16:10:24 PDT 2016

 

Cheers, Andre

 

application delivery
cookies
LTM
persistence

6 Replies

Sort By
  • ekaleido_26616's avatar
    ekaleido_26616
    Icon for Cirrocumulus rankCirrocumulus
    Nov 11, 2016

    A 403 is distinctly different than a 401 in that it is the server saying, simply, it won't service the request. It is not indicating there was failed authentication, as a 401 would do. And for it only fail 15% of the time would not lead me to believe the issue is persistence on the F5.

     

    Take a packet capture on the F5 of a specific session, this will give you a better idea what is going on, and give you the ammo you need to fire back at the app folks.

     

    • bohm_192937's avatar
      bohm_192937
      Icon for Nimbostratus rankNimbostratus
      Nov 11, 2016

      Thanks, but this will take some time because we are not able to reproduce it but see it happening in the logs and hear people complain sometimes. But I'll give it a shot.

       

      Well in the apache logs I see some 403 POST errors while the client remains on the same server according to the apache logs, but also 403 POST errors where a session flips from 1 server to an other. This is something I'm not able to explain regarding cookie session persistence. What is the criteria F5 uses to determine a http session?

       

    • ekaleido_26616's avatar
      ekaleido_26616
      Icon for Cirrocumulus rankCirrocumulus
      Nov 11, 2016

      Session cookies could potentially cause a problem depending on timeout values and user response times, maybe. You'd also want to verify via capture that the cookies you'e setting are being sent with the POST. It's not super common, I guess, but I've seen weird apps strip cookies out when the method changes.

       

  • ekaleido's avatar
    ekaleido
    Icon for Cirrus rankCirrus
    Nov 11, 2016

    A 403 is distinctly different than a 401 in that it is the server saying, simply, it won't service the request. It is not indicating there was failed authentication, as a 401 would do. And for it only fail 15% of the time would not lead me to believe the issue is persistence on the F5.

     

    Take a packet capture on the F5 of a specific session, this will give you a better idea what is going on, and give you the ammo you need to fire back at the app folks.

     

    • bohm_192937's avatar
      bohm_192937
      Icon for Nimbostratus rankNimbostratus
      Nov 11, 2016

      Thanks, but this will take some time because we are not able to reproduce it but see it happening in the logs and hear people complain sometimes. But I'll give it a shot.

       

      Well in the apache logs I see some 403 POST errors while the client remains on the same server according to the apache logs, but also 403 POST errors where a session flips from 1 server to an other. This is something I'm not able to explain regarding cookie session persistence. What is the criteria F5 uses to determine a http session?

       

    • ekaleido's avatar
      ekaleido
      Icon for Cirrus rankCirrus
      Nov 11, 2016

      Session cookies could potentially cause a problem depending on timeout values and user response times, maybe. You'd also want to verify via capture that the cookies you'e setting are being sent with the POST. It's not super common, I guess, but I've seen weird apps strip cookies out when the method changes.