SIP-TLS Server Handshake Failure/SIP-TLS Handshake Negotiation Start Failure warnings/errors on Monitor Tab of SBC Edge

Access Control List (ACL), Direct Routing, Direct Routing, Enterprise Voice, Ribbon, SBC, SBC 1000, SBC 2000, SBC Edge, SWe Lite / August 24, 2023

If you are using Ribbon SBC Edge (SBC 1000 / SBC 2000 / SBC SWe Lite) that is integrated with Teams Direct Routing, you noticed on your SBC Edge repeated warnings/errors under the Alarm View on the Monitor tab like the following:

SIP-TLS Server Handshake Failure

SIP-TLS Handshake Negotiation Start Failure

You might have different causes of the alarm (the cause is inside the description of the alarm)

Graphical user interface, text, application Description automatically generated

Graphical user interface, text, application Description automatically generated

Reason for these Warnings and Errors:

The reason for these warnings and errors is that there are many machines on the net that keeps scanning SIP servers on well know SIP ports trying to hack them to make calls.

To avoid these machines from scanning your SBC, you need to limit SIP communication only with Microsoft Teams server (SIP Proxy) which consists of these two ranges (52.112.0.0/14 and 52.120.0.0/14) as explained in the link:

https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan-media-bypass

Under the section “SIP Signaling: Ports”

The following is from the above link

Graphical user interface, text, application, email Description automatically generated

Using Firewall

If your SBC is behind a firewall, you can simply configure the firewall to limit SIP communication to only (52.112.0.0/14 and 52.120.0.0/14)

Using SBC Edge Access Control List (ACL)

Another method is to utilize applying Access Control List (ACL) on the “Logical Interface” of SBC that is connected to the internet.

You can create your own ACL or you can utilize the existing ACL created by running “Easy Config Wizard” and selecting Teams as a scenario

Notes About Using Access Control List (ACL):

  • You need to allow HTTPS allowed on the interface to control the SBC if you have the same interface for both managing the SBC and for SIP and Media communication
  • If you configured allowing HTTPS incorrectly in the ACL, you will lose access to the Web Interface of the SBC
  • It is better to have an additional interface enabled with the correct IP and connected to the network. This would help in case you have applied an ACL that is incorrectly not allowing HTTPS. This way, you will not end up with your SBC Web Interface inaccessible
  • In the case of SBC 2000, the Admin Port is usually configured by default and has the default IP of 192.168.128.2.
  • Do a backup of your SBC before applying changes