Solved Inbound TLS Call Question

[jwmilleril]

We have a SIP trunk with an unsupported vendor using TLS. The vendor provided us with the root certificate which we uploaded and all outbound calls are fine. For inbound calls, it was working for serveral weeks then all of a sudden the 3CX server started rejecting the inbound TLS handshake requests (strangely enough it was a midnight Eastern time when the calls started failing...hmmm). A packet capture shows the Client Hello being sent to 3CX, which immediatly sends a RST, ACK without any sort of errors we can find. The offered ciphers seem fine. I know this implies an expired certificate, possibly, but we have another TLS SIP trunk with another vendor and it's working fine.

The question is what certificate is being used for INBOUND calls? Is it the same for all TLS trunks? Is it the one found in Security-Secure SIP settings or is it the one we place in C:\Program Files\3CX Phone System\Bin\nginx\conf\instance1?

Thanks!

 

[jwmilleril]

I resolved this issue. I had a similar issue for outbound calling where my firewall was aging out the TLS Session before it could be reset from either the client or the server. To fix, I created a custom application in the firewall to identify port 5061 traffic and gave it the source and desitation IP's. I then set the TCP Timeout to 3660 seconds (the standard is 3600s) which ensured that the connection would be reset by either the client or the server but never aged out in the firewall, which left things a mess. I had applied this only to the Outbound traffic. By applying also to the inbound traffic, the problem disappeared. It was not a certificate issue but rather the inbound connection was never reset and the 3CX server didn't know it.