Yes this makes sense. What's happening is that you're doing a federated logon with MS, then using an access policy that puts you into "reverse-proxy mode", the f5-w-xxxx thing is APM's rewriting reverse proxy (aka portal access) which has a kind of "cookie proxy" function, so the real cookies from the browser and the cookies set by the browser *during the rewrite session* are completely separate. It's weird and confusing.
This unique rewriting reverse proxy functionality in APM was originally designed to support legacy apps that tended to use java applets (it decompiled them and recompiled them on the fly, automatically wrapping all networking functions into special APM wrappers), flash content (this worked the same way as applets), and many servers with random ports, where some of them might be linked from just static IP addresess instead of proper names (remember those days?). The only way to make these apps work via a single DNS name (ourvpnportal.blah.com, or whatever) was to intercept and rewrite all of these links and hostnames, AJAX requests, and cookies to access APM instead of where they were originally intended. Modern web apps are nothing like this and usually only occupy a singe hostname on a single port, so there is not much need for the rewriting reverse proxy any more. We usually recommend avoiding it if possible because it causes headaches like you're trying to solve now.
If you want to proceed with the rewriting reverse proxy mode anyway, your best bet is to contact Support so they can analyze the traffic pattern exactly and recommend how to configure the rewriter to work in your specific situation so it does not rewrite the Microsoft/Azure auth links. If you want to read about how this works, the following sol should help:
https://my.f5.com/manage/s/article/K11722121