Forum Discussion

Urosh's avatar
Urosh
Icon for Altostratus rankAltostratus
Jun 23, 2023

ASM not passing client cookies to the node servers

Hello everyone

We're having issues when enabling ASM on the virtual server serving the Cisco Meeting Server WebRTC application. Te problem is that the users are unable to join meetings as soon as we enable ASM on the VS. we have tried to attach the ASM policy with everything possible disabled and in transparent mode, but the issue still remains. 

What we have notice when comparing traffic with ASM enabled and disabled is in case when ASM is enabled, that the cookies sent from client are not passed to the server.

Below is diff betwen the client side request (left) and the servers side (right) when ASM is enabled.

Therefore, we suspect something must be related to the cookies.

Does anyone have any idea what could cause this? the BIG-IP version is v15.1.8.1 (Build 0.0.3).

Thanks for any help!

application delivery
security
  • Urosh's avatar
    Urosh
    Jun 26, 2023

    The problem was resolved by enabling the websocket profile on the VS.

    Thank you all for your help and suggestions. 

    • Urosh's avatar
      Urosh
      Icon for Altostratus rankAltostratus
      Jun 26, 2023

      I noticed, that I didn't have websocket profile enabled on the virtual server. As soon as I enabled that, it started working, even with ASM policy.

  • Mohamed_Ahmed_Kansoh's avatar
    Mohamed_Ahmed_Kansoh
    Icon for MVP rankMVP
    Jun 23, 2023

    Hi Urosh , 
    while your issue is strange to me , I started to check if there is " ASM system variable attribute " contols Domain cookies as you said you switched the policy to transparent but this is hasn't solve your issue. 

    I have another explanation you may hit on it :  
    I opened F5 Bug Tracker to see all bugs related to TMOS V 15.1.8.1 and explored all bugs related to Cookies with ASM module provisoned , and I found below Bug , it outlines Bigip AWAF may truncate your Cookies because it has spaces in cookie name. 

    This is the Bug and has workaround , may solve your issue : 

    https://cdn.f5.com/product/bugtracker/ID1095041.html

    Try it , your issue is interesting 

  • Urosh's avatar
    Urosh
    Icon for Altostratus rankAltostratus
    Jun 26, 2023

    The problem was resolved by enabling the websocket profile on the VS.

    Thank you all for your help and suggestions. 

    • Mohamed_Ahmed_Kansoh's avatar
      Mohamed_Ahmed_Kansoh
      Icon for MVP rankMVP
      Jun 26, 2023

      Please Urosh . 

      Mark your last reply of "The problem was resolved by enabling the websocket profile on the VS " 
      as an accepter solution , to help others who hit in this issue to find the workaround quickly. 

      Thanks again for sharing...

  • CA_Valli's avatar
    CA_Valli
    Icon for MVP rankMVP
    Jun 23, 2023

    Hello,
    I think you might be reading this information wrong. By design, the F5 WAF engine injects a new cookie in the client-side connection, and uses it to correlate client events within a session and to check data integrity.

    So, the behavior you're seeing in the capture is correct. The full server-response that you're receiving is being forwarded as-is to the client (well, it does strip the nginx information), and the WAF uses the set-cookie attribute to create a hash for this session.

    Consequent client requests to the WAF will include this hashed cookie, and since the server doesn't require to see it, it's not being forwarded. 

    I'm not seeing missing informations from the logs you attached. Let me know if this is clear enough! 
    KB reference for ASM cookies: https://my.f5.com/manage/s/article/K6850