Forum Discussion
irbk
Cirrus
CirrusSSL 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...
irbkCirrus
CirrusSorry 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
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
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.
- Paulius
irbk It seems as though you have both SSL and non-SSL communication occurring over the same IP and port which definitely will cause issues when perform SSL termination on the F5. The reason this will cause issues is because the F5 expects SSL communication but receives traffic that isn't SSL.