Hello Jonatan,
I remember a while ago when ISAM 9.0.7 was released, there was a (new) default setting that introduced somewhat similar behavior when a (persistent connectionà request followed a prior logout request (pmkslogout, but also EAI type of logouts) (using the same persistent connection port).
I don't have a lot of experience with the networking aspect/handling of persistent connections on more recent versions of the ISVA product, so not aware of potential other gotcha's related to connection handling. (the
9.0.7 case is described here , might be worth trying
strict-ssl-sessions = false regardles whether or not your prior requests are logout requests).
Are there configurable options on the front VIP (provided this is on a non-prod environment), to see if you can find what makes WebSEAL trip over the connection (re-use)?
- disable persistent connections (disable the keep-alive)
- using a different SSL/TLS version (e.g TLS 1.2 vs TLS 1.3)
I understand it doesn't really give you an answer to your question, but might help to narrow down where things fail.
Usually when it's a combination of persistent connections/TLS problems, tracing the right components can also help to narrow down behavior to workable findings that can be further investigated.
From your analysis of the 2 GET requests, followed by a (failing POST) request, I think you've already done the folliwing.
But in any case, my go-to approach here would be a combination of:
- TCP traces on the appliance : which can be filtered with tcp.flags.reset==1 to see where (unexpected) connection closures take place, and importantly will also show the matching client IP address and port (the ephemeral port from the BigIP)
- using that ephemeral port, you can correlate this to requests in a pdweb.snoop trace (which shows port/ip addresses) : can sometimes be useful in rather busy environments, if you need to match certain requests (from a request.log resulting in GSK_ * type errors in the msg__webseald. log)
- Use indicators of errors (GSK_* type errors) in msg__webseald.log to search a GSKIT trace
- GSKIT traces (steps) produce a binary output file, typically investigated by an L3 Support team (ISVA or GSKIT L3 Support) via appropriate tooling. However you can run a linux strings command against the output files, to print out anything readable.
I appreciate this does not solve your problem, but it might help to narrow down things further.
Best regards,
Hans
------------------------------
HANS VANDEWEGHE
------------------------------
Original Message:
Sent: Thu November 03, 2022 02:05 AM
From: Jonatan Wålegård
Subject: WebSeal closing TCP connection
Hi,
I already have a ticket with the support but as they have little to no experience with ISVA, severe issues with the English language and a nonexistent ability to troubleshoot properly, I'm desperate to try my luck here.
We have an application that is calling one of our webseals with three requests on top of each other, two GET's followed by a POST.
The two GET's gets through just fine, but the POST call is being closed by webseal and I can't figure out why.
If we add a 3-second delay before the POST call it works as expected (probably because a new TCP connection has been established here).
We have a BigIP VIP in front of the webseals (this is where we can see that the connection is being closed).
Here are our current settings:
client-connect-timeout = 120
persistent-con-timeout = 20
intra-connection-timeout = 60
connection-request-limit = 100
Any idea why ISVA/webseal chooses to close the TCP connection?
------------------------------
Jonatan Wålegård
------------------------------