sorry, I'm not an expert using F5 but I got a question for you.
I'm using an iRule Proxy configured on a BIG-IP 13.1.1.
Suddenly...and I don't know why, this proxy is still working but an antivirus agent provided me an error about handshake activation.
"2022-04-26 14:11:28.000000 [+0100]: [Error/1] | SSL_connect:failed in SSLv3 read server hello A | http\SSLContext.cpp:266:DsaCore::CSSLContext::SSLContextInfoCallback | 17F4:1B94:ActivateThread
2022-04-26 14:11:28.000000 [+0100]: [Error/1] | CHTTPServer::HandshakeSSL(192.168.201.37:8081) - BIO_do_handshake() failed - peer closed connection. | http\HTTPServer.cpp:272:DsaCore::CHTTPServer::HandshakeSSL | 17F4:1B94:ActivateThread"
Have you got any experience on a similar issue?
What could I check?
it looks like its a failure in the handshake. SSLv3 is quite old this wouldn't be the web server or client using this has been updated to not use SSL but upto TLS1.2 or TLS1.3??
Other than that, i'm stuck to!
Thank you mate.
Yes, it is possible but...I cannot reconfigure my antivirus agent.
The only solution for me is let to disable SSL inspection or https decryption or allow the agent to use SSLv3.
Do you know how to do it?
It's not McAfee is it??? I recongise the Port number! (but others may use it as well - just a guess!)
So where is this flow error coming from? AV to Virtual server? Or f5 to pool member?
Where is 192.168.201.37:8081?? I'm guessing this is a f5 to pool member flow?
So to remove the encryption you just need to remove the client and server SSL profiles from the virtual server.
But there must be a way to check this, maybe even take a pcap of the flow and have a better look,
Possible f5 support could look at the config and that pcap for you with more understanding of what those errors mean.
Your in Local Traffic > Virtual Servers > [VIRTUAL SERVER] > Secuirty.
SSL Certs are set at
Local Traffic > Virtual Servers > [VIRTUAL SERVER]
SSL Profile (Client) and SSL Profile (Server)
And these policies are set in Local Traffic > Profiles > SSL > Client or Server as needed.
Client is incoming so from web client to f5 and server is f5 to web server,
From the looks of your in i'm guessing this is linked to the f5 to server comms so the SSL Server profile is being used.
So possibly something in the server ssl profile is stopping you?
You are in the range of looking at what updates have happened on the TrendMicro platform, and a f5 support call to try to deep dive into it.
Hum interesting!!! - you don't actually have SSL turned on!!!
The fields are blank! therefore its going striaght in and straight out.
So, you might have already mentioned this. Where are those logs from???
Is it the f5, the client or the server??? (TrendMicro side)
The log I sent you is from the client where TrendMicro agent is installed.
If I remove proxy from the configuration, the agent can be activate.
If I put the proxy in the configuration I receive the handshake error.
If I put the proxy in my browser settings, I can navigate withous any problem.
Is there any way to trace what BIG-IP proxy is doing for my client?
It's sounding more and more like a trend micro issue not liking the f5 in the middle.
But you can use tcpdump to see the flows. So things like
tcpdump -nni 0.0:nnnp 'host 192.168.201.37 ' -s0 -vvv
tcpdump -nni 0.0:nnnp 'port 8081' -s0 -vvv
Add -w /var/tmp/<filename>.pcap to the dump to capture the output and then you can review it in wireshark.
This should allow you to see the flows, the port 8081 one might look the best at the moment so you can see in and out. Or if you know the client IP add that with a or so 'host 192.168.201.37 or host 10.10.10.1' for example that should then let you see in and out.
No i can't see anything major either!
I would either talk to f5 support, or trendmicro support to look at there logs.
I can see connections, and http 200 so connections are happening. So where the error is and why has to be application side, or at least the information for why may be there!
AV is TrendMicro 🙂
I got some servers that are using BigIp proxy in order to contact a central console located in the cloud and not managed by me.
192.168.201.37:8081 is the proxy address set in an iRule in Big IP
how can I do the checks you suggested me?
one more time...thank you for you time and you help.
I solved the issue disabling and re-enabling the proxy virtual server.
The problem is that these solution worked for 1 week to now...and now I've done the same workaround.
Do you know what can be happened?
Maybe there is a kind of cache to clear?