Forum Discussion

Cirrus

Oct 04, 2023

Solved

SSL protocol mismatch

Ok, I ended up way down a rabbit hole earlier this week. That whole line of thought seemed to be a red herring. BigIP LTM trying to load balance to MS Navision servers which don't use standard 80 o...

Paulius
Oct 05, 2023
irbk That is correct. Unless you have some way of the F5 being able to look for a value in the client request that would define if it was intended to be SSL or not you would have to split SSL and non-SSL into two different VS listening on different ports on the F5 side that is client facing.

Paulius

MVP

Oct 05, 2023

irbk I'm surprised that the L4 VS configuration works since you have an HTTP profile configured on a VS that doesn't perform SSL termination or SSL bridging. For the one where you are performing SSL bridging you might try running the following tcpdump to see if can find anything odd in wireshark. You can track the connection through SNAT by filtering on the client IP source port because the F5 tends to utilize the same ephemeral port when it forms its connection from itself to the pool member that it's balancing to. This will save file "ssl_tshoot.pcap" in directory /shared/tmp/ once you stop the tcpdump.

tcpdump -nni 0.0:nnp host <vs_IP> -w /shared/tmp/ssl_tshoot.pcap

irbk

Cirrus

Oct 05, 2023

Actually, I just did that and replied to Amine above. With the SSL Profile (Client) and SSL Profile (Server) setup, doing a TCPdump capturing only the VS IP, I see 9 packets, none of which are a SSL/TLS negotation. So it's like they aren't even trying the TLS communication or the communication is dying when they try to start the negotation.

As you can see above, no TLS communication is attempted and this is all communication between the client and VS. The VS doesn't seem to initiate any contact with the pool member.

If I just have the SSL passthrough (IE "Performance (Layer4)") the connection succeeds and I cearly see the TLS negotation taking place.