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 or 443 ports. Instead, the client communicates on port 7246 using TLSv1.2. If I have my Virtual Server Type set to "Performance (Layer 4)" I can get a connection to the Navision servers without issue. However I want to get SSL Bridging set up because I think we can get better performance with SSL Bridging than just the SSL passthrough (which I believe is basically what the "Performance (Layer 4)" is). When I try to set the type to "standard" (without puting in a client or server ssl profile) the Navision client gives me a "could not create a connection to the server". I've imported our wildcard cert and if I set the Wildcard cert for the SSL Profile (Client) and set the SSL Profile (Server) to "serverssl" I then get a "can't connect because of a protocol mismatch".

Checking
tmm --clientciphers DEFAULT | grep "TLS1.2"
returns a bunch of TLS1.2 protocols and the Wildcard profile is set to "Ciphers Default". Checking the LTM log, I just get kind of a generic error
Oct 4 15:45:20 BigIP01.domain.com warning tmm1[3124]: 01260009:4: <client IP>:43130 -> <BigIP VS IP>:7246: Connection error: ssl_passthru:5935: alert(40) not SSL
Now, according to wireshark, I'm seeing both TLS and non TLS traffic to port 7246 so I'm not sure if the above error is a "real" error or if the issue is because both kinds of traffic are going to the same port. Logging on my SSL certificate is set to "debug" for all events. I'm not sure where to go next.

ltm profile client-ssl Wildcard23-24 {
ciphers DEFAULT
}

ltm profile server-ssl serverssl {
ciphers DEFAULT
}

pool Nav_Pool_7246
profiles {
LC-http { }
LC-oneconnect { }
LC-tcp-lan { }
Wildcard23-24 {
context clientside
}
serverssl {
context serverside
}
}
serverssl-use-sni disabled
source 0.0.0.0/0
source-address-translation {
pool Nav
type snat
}
translate-address enabled
translate-port enabled
vs-index 4
}

application delivery

LTM

ssl

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.

13 Replies

Amine_Kadimi
MVP
Oct 04, 2023
To confirm the issue is with the TLS cipher negociation between the client and the VS, you should get a ssldump. Overview of packet tracing with the ssldump utility (f5.com)

The client hello part of the dump will show you what cipehrs are supported by the client, you can then cross check them with the 'DEFAULT' ciphers
- irbk
  Cirrus
  Oct 05, 2023
  This is interesting, 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.
  If I just have the SSL passthrough (IE "Performance (Layer4)") the connection succeeds and I cearly see the TLS negotation taking place.
  - Amine_Kadimi
    MVP
    Oct 05, 2023
    It's not easy to tell from a tcpdump output that there is any ssl negotiation happening unless you export it to wireshark. I would definitely see what ssldump output looks like
Paulius
MVP
Oct 04, 2023
irbk Some of this doesn't make sense because having a virtual server (VS) configured to listen on 443, no SSL profiles on the VS, and the pool members with port 7246 should result in a passthrough of SSL communication direclty to the pool members. Can you provide the configuration of the VS that is the standard VS without any SSL profiles?
irbk
Cirrus
Oct 05, 2023
Sorry Paulius I guess I didn't post the VS configuration. Thought I did. The VS isn't configured to listen on 443. It's configured to listen on 7246. The pool members are also configured for 7246. A wireshark of communication between the client and server with no F5 in place is what told me there is TLSv1.2 going on between the two devices on that port.
In this configuration, the client will connect without issue, because it's just doing the SSL forwarding:
ltm virtual Nav_7246 {
creation-time 2023-09-26:16:00:07
destination <VS IP>:7246
ip-protocol tcp
last-modified-time 2023-10-04:16:58:23
mask 255.255.255.255
persist {
source_addr {
default yes
}
}
pool Nav_Pool_7246
profiles {
LC-http { }
fastL4 { }
}
serverssl-use-sni disabled
source 0.0.0.0/0
source-address-translation {
pool Nav
type snat
}
translate-address enabled
translate-port enabled
vs-index 4
}
ltm pool Nav_Pool_7246 {
load-balancing-mode predictive-member
members {
Nav01:7246 {
address <Nav01 IP>
session monitor-enabled
state up
}
Nav02:7246 {
address <Nav02 IP>
session monitor-enabled
state down
}
}
monitor tcp
}
When I try with this VS configuration (same pool as above) is when I get the protocol errors
ltm virtual Nav_7246 {
creation-time 2023-09-26:16:00:07
destination <VS IP>:7246
ip-protocol tcp
last-modified-time 2023-10-05:08:35:17
mask 255.255.255.255
persist {
source_addr {
default yes
}
}
pool Nav_Pool_7246
profiles {
LC-http { }
LC-oneconnect { }
LC-tcp-lan { }
Wildcard23-24 {
context clientside
}
serverssl {
context serverside
}
}
serverssl-use-sni disabled
source 0.0.0.0/0
source-address-translation {
pool Nav
type snat
}
translate-address enabled
translate-port enabled
vs-index 4
}
- 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.
Marrie_Jenner
Nimbostratus
May 09, 2024
An SSL protocol mismatch error typically occurs when there's an inconsistency between the SSL/TLS protocols supported by the client and the server. This can happen for various reasons:
Outdated SSL/TLS versions: The client or server might be using outdated versions of SSL/TLS that are not compatible with each other. For example, if the server only supports TLS 1.2 and the client is trying to connect using SSL 3.0, a protocol mismatch error will occur.
Configuration issues: Sometimes, the SSL/TLS configuration on either the client or the server side is incorrect, leading to a mismatch in supported protocols.
Firewall or proxy interference: Firewalls or proxies can sometimes interfere with SSL/TLS connections, causing protocol mismatches if they don't handle the protocols properly.
Solution for this :
Update SSL/TLS certificates
Check the SSL/TLS configuration settings
Disable outdated protocols
Inspect network devices
Still if you are facing any error kindly take help from technical support team.

Forum Discussion

SSL protocol mismatch

13 Replies

Recent Discussions

Social Media Marketing

Content Marketing

Failed to add new DNS machine to the existing DNS sync-group

Email Notification Sent For The Configuration Change

F5 Malicious Source IP Address Alert

Related Content

Cipher suite mismatch advertisement/warning

Capture SSL Profile Protocol Stats - Bash

Remote Desktop Protocol (RDP) using an SSL VPN

AFM Protocol Inspection rules for CVE-2022-3602 (aka SpookySSL)

Protecting the F5 BIG-IP AFM system with AFM Protocol Inspection System Checks