Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

APM what do virtual servers share?

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.

0
Rate this Question
Comments on this Question
Comment made 2 months ago by Simon Waters 398

Digging further with WireShark I see HTTP POST data is being stripped from the POST request presumably by browser or F5.

0

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

For the record this resolved itself, which is slightly worrying as it suggests it may be data related or something else not identified.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Is the error appears when

  • user access to App1
  • user is redirected to logon page
  • user authenticate to logon page
  • user is redirected to App1
  • user try to post data on App2 (unauthenticated)

If true, look at this code from Yann Desmarest

0
Comments on this Answer
Comment made 2 months ago by Simon Waters 398

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.

0
Comment made 2 months ago by Stanislas Piron 8592

what is the TMOS version? did you upgrade from v11 to v12 or v13 since 24th March?

0
Comment made 2 months ago by Simon Waters 398

From memory, 12.1.3, the 12.1.3.4 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).

0