I have three Access Profiles on an F5 HA pair.
All three did work on the 24th March.
All are multi-domain.
HTTP POST requests are failing to the second virtual server of the two in multi-domain preventing manual login requests with the web service behind that virtual server. Multi-domain just prevents access to the service, but authorised users need further credentials.
These troubled virtual servers share:
HTTP-Profile - looks good.
SSL Profile Client - looks good, shared with working services.
Rewrite profile - looks good, changing/disabling has no effect.
HTML profile - looks like default.
Connectivity profile - looks irrelevant, also appears to be same as default.
HTTP/2 profile - shared with working services.
It is possible other things have changed in the environment, there was a PHP 7.0 to PHP 7.1 upgrade about the time of the last successful use POST request to make it through these services.
I can login to the service behind the F5 successfully, it looks like GET requests succeed, but POST requests fail through the F5.
Any ideas on what might be shared, or what might be globally preventing this.
I think I've ruled out iRules, and a bunch of other changes (PHP version changes included).
Afraid I was on leave, so I am picking up pieces, trying to work out what was changed precisely to break these POST requests.
Digging further with WireShark I see HTTP POST data is being stripped from the POST request presumably by browser or F5.
For the record this resolved itself, which is slightly worrying as it suggests it may be data related or something else not identified.
Is the error appears when
If true, look at this code from Yann Desmarest
Thanks for the suggestion, I saw a bunch of SAML related issues around the same topic.
We aren't touching SAML here, and it worked before "something" changed, still not pinned down (I know a lot of stuff it isn't with varying degrees of certainty).
It does feel like low level HTTP issue, I wondered if the content length is rewritten correctly, or chunking, since the TCP stream from Wireshark has all I expect apart from the POST data. Although I notice that Wireshark didn't parse the stream fully either (is all the multiplexing and HTTP/2 stuff confusing Wireshark?).
I didn't come away from your example feeling I understood when this data is being dropped.
We apply a SSO config to the other virtual server, in the multi-domain authentication. So when they arrive here their APM session is good (so they can fetch the login page), and this is a POST within existing APM session.
I figure it is either recent Redhat updates (I've mostly ruled out), or a single configuration change, or a deep bug.
what is the TMOS version? did you upgrade from v11 to v12 or v13 since 24th March?
From memory, 12.1.3, the 18.104.22.168 upgrade failed and this is distracting me from getting back to sorting that.
It’s the latest supported on the hardware less the one that didn’t work.
Going to break the multidomain on a test version and see if it is anything to do with multidomain. Been comparing it to the disaster recovery service (which works fine) and failing to find any differences of note.
Changed iRule ordering, found some minor profile differences, but none looked likely and none fixed it.
If the multidomain doesn’t fix it I’ll have to pull the config back to the lab, means a lot of password changes (sigh).