I’m using 3CX Session Border Controller (SBC) 15.0.56341 to connect to a 3CX v15 SP4 server running on Server 2012 R2 in the cloud. Usually it works fine. A couple days ago, though, even after re-starting the SBC, I was getting the error “Invalid signature received: 0x10317”.
Troubleshooting
On the device where the SBC is installed, I changed the configuration file
C:\ProgramData\3CXSBC\3cxsbc.conf
to do detailed logging (“Level=VERBOSE”) and restarted the SBC service. The log, stored in C:\ProgramData\3CXSBC\Logs\, led me to suspect an TLS error of some kind:
NOTICE | 20170220-141039.581 | 3CXTunnel | TUNL | 1928 | security.cpp:1310 | Secure tunnel: got SSA with mode = 1 DEBUG | 20170220-141039.612 | 3CXTunnel | TUNL | 1928 | security.cpp:475 | Name: /C=CY/ST=Nicosia/L=Engomi/O=3CX Ltd/CN=3CX CA/[email protected]; Issuer: /C=CY/ST=Nicosia/L=Engomi/O=3CX Ltd/CN=3CX CA/[email protected]; depth = 1, err = 0 DEBUG | 20170220-141039.612 | 3CXTunnel | TUNL | 1928 | security.cpp:475 | Name: /C=CY/ST=Nicosia/O=3CX Ltd/OU=3CXPhoneSystem/CN=3CX Tunnel Server/[email protected]; Issuer: /C=CY/ST=Nicosia/L=Engomi/O=3CX Ltd/CN=3CX CA/[email protected]; depth = 0, err = 0 NOTICE | 20170220-141039.706 | 3CXTunnel | TUNL | 1928 | TunnelTcp.cpp:566 | Secure tunnel is established ERR | 20170220-141039.706 | 3CXTunnel | TUNL | 1928 | security.cpp:1240 | Invalid signature received: 0x10317 ERR | 20170220-141039.706 | 3CXTunnel | TUNL | 1928 | TunnelTcp.cpp:560 | Socket error (22): while reading packet from tunnel at while reading packet from tunnel (TunnelTcp::process) ERR | 20170220-141039.706 | 3CXTunnel | TUNL | 1928 | TunnelTcp.cpp:295 | Bridge [3CXSBC15.0.56341] failure 'Invalid signature received' on TCP connection: while reading packet from tunnel
On the cloud-based 3CX server, I restarted all 3CX services including the 3CX Tunnel, but the issue persisted. I reviewed the 3CXTunnel log for the same period. The logs are stored in C:\ProgramData\3CX\Instance1\Data\Logs. Again, it seems to point to a TLS error:
14:10:39.346|0000058c| Info|TLSTransp.cpp(342): Performing TLS handshake on socket 308@TLS(HS) 14:10:39.474|0000058c|Debug|TLSTransp.cpp(61): Name: /C=CY/ST=Nicosia/L=Engomi/O=3CX Ltd/CN=3CX CA/[email protected]; Issuer: /C=CY/ST=Nicosia/L=Engomi/O=3CX Ltd/CN=3CX CA/[email protected]; depth = 1, err = 19 14:10:39.474|0000058c|Debug|TLSTransp.cpp(61): Name: /C=CY/ST=Nicosia/L=Engomi/O=3CX Ltd/CN=3CX CA/[email protected]; Issuer: /C=CY/ST=Nicosia/L=Engomi/O=3CX Ltd/CN=3CX CA/[email protected]; depth = 1, err = 19 14:10:39.474|0000058c|Debug|TLSTransp.cpp(61): Name: /C=CY/ST=Nicosia/O=3CX Ltd/OU=3CXPhoneSystem/CN=3CX Tunnel Client/[email protected]; Issuer: /C=CY/ST=Nicosia/L=Engomi/O=3CX Ltd/CN=3CX CA/[email protected]; depth = 0, err = 19 14:10:39.480|0000058c| Info|TLSTransp.cpp(378): TLS connection is accepted on socket 308@TLS(HS) 14:10:39.480|0000058c| Info|TLSTransp.cpp(383): TLS connection has finished handshake on socket 308@TLS(Up) 14:10:39.480|00000590|Debug|Multiplexer.cpp(818): 113 <-[public IP of SBC machine]:62308:308: sent APDU(24) 14:10:39.480|00000590| Info|Multiplexer.cpp(823): 113 <-[public IP of SBC machine]:62308:308: Start sending of keep alive packets 14:10:39.515|0000058c|Error|TLSTransp.cpp(421): TLS connection read has returned socket error: 10054
MSDN documentation has this to say about socket error 10054:
Connection reset by peer. An existing connection was forcibly closed by the remote host. This normally results if the peer application on the remote host is suddenly stopped, the host is rebooted, the host or remote network interface is disabled, or the remote host uses a hard close (see setsockopt for more information on the SO_LINGER option on the remote socket). This error may also result if a connection was broken due to keep-alive activity detecting a failure while one or more operations are in progress. Operations that were in progress fail with WSAENETRESET. Subsequent operations fail with WSAECONNRESET.
Resolution
This 3CX server is shut down at night. When it came up the next morning, the issue was gone; the SBC was working fine. So apparently a reboot of the 3CX server (not the SBC server) cleared it.
For good measure, I followed the advice of 3CX support and updated the SBC to version 15.0.61335.
I wanted to check the TLS certificate referenced in the logs to make sure it was not expired but apparently that is hard-coded into the tunnel logic and cannot be examined separately.
Conclusion
It is unnerving to find that the SBC suddenly stops working and that the cause cannot be determined. Hopefully restarting the 3CX server (not the SBC server) will solve it if it happens again.