Problem

When using Cisco Firepower Management Center (FMC) as a firewall between a B2Bi (Master Agent) and a Secure Relay (Router Agent) there may be unexpected disconnects during the SSL handshake when establishing initial connection. When B2Bi attempts SSL connection and sends a ‘Client Hello’ to the XSR, debug/trace logs on the XSR side may indicate that that a ‘Client Hello’ was sent rather than a ‘Server Hello’. This becomes apparent when looking at network traffic as the following will appear (where both entities send a ‘Client Hello’):

PACKET NO. | TIME | DST IP | SRC IP | PROTOCOL | INFO
101 10/31/25 01:01 10.129.129.1 192.1.1.4 TLSv1.2 Client Hello
102 10/31/25 01:01 192.1.1.4 10.129.129.1 TLSv1.3 Client Hello

Additionally, the B2Bi (MA) logs will show that an unexpected disconnect occurred during handshake:

2025-10-01 13:08:33,045 - ERROR [XsrAgent] (RouterAgentContext) - [DMZ:6810] Communicator raised and exception during HANDSHAKE
com.axway.niocore.communicator.CommunicatorException: Unexpected disconnection during handshake

In the Secure Relay (RA) logs when TRACE level debug is enabled the client received a ‘Client Hello’ when a ‘Server Hello’ was requested:

25-09-30 08:46:34,627 DEBUG main Communicator : [MA /B2Bi:27718]: Terminating connection
javax.net.ssl.SSLProtocolException: Unexpected handshake message: client_hello
25-09-30 08:46:34,627 DEBUG main Communicator : [MA /B2Bi:27718]: Terminating connection
java.nio.channels.ClosedChannelException: null
25-09-30 08:46:34,815 DEBUG main Communicator : [MA /B2Bi:61150]: Terminating connection
com.axway.niocore.communicator.CommunicatorException: Error during unwrap: Unrecognized SSL message, plaintext connection?
…
Caused by: javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?

Resolution

Disable the ‘TLS Server Identity Discovery’ setting on the CISCO firewall.

With this feature, if a TLS 1.3 Client Hello is detected from a client, it will then initiate a side connection to the server using TLS 1.2 to retrieve the unencrypted server certificate. Once the server's identity is obtained, specifically the Common Name or Subject Alternative Name, the firewall can apply access control, application, or URL filtering policies based on that information. Neither B2Bi nor XSR supports the interrogation of the certificate or TLS protocol as such and will cause a disconnection during the handshake.