SIP over TLS non standard ports

[NorthernNetGuy]

Starting a couple days ago I've been having problems with some of our video conferencing applications.

We use RP1cloud as our VC service. Normally we would see traffic on tcp5061 head out accepted. Now i'm seeing traffic dropped with the gateway as the target on non SIP ports alongside the normal traffic.

See non standard ports here. The drops are destined to our external IP, and accepts are to the VC cloud service:

The drop logs show the following

In order to allow the inspection of encrypted SIP over TLS connections, please add the 'sip_tls_with_server_certificate' service to the relevant rule,
make sure that the 'sip_tls_authentication' service is removed from the rule and configure TLS on the corresponding SIP Server object

I found the following SK related to this VoIP Configuration message, however i'm unsure if it's viable for this situation:

https://supportcenter.checkpoint.com/supportcenter/portal?action=portlets.SearchResultMainAction&eve... 

No changes have been made on the firewall between when it was and wasn't working.

Anyone have thoughts on the behaviour change? I'm unsure why I'm seeing the odd TCP ports being listed in the SIP_tls_authentication service.

[NorthernNetGuy · Accepted solution]

Pretty easy fix. I just used the predefined 'sip_tls_not_inspected' instead of 'sip_tls_authentication' and it began working.

Not sure why it suddenly stopped working unless our vendor changed to TLS encrypted SIP.

I'm guessing the odd TCP port range is just how the firewall logs the dropped traffic.

[Linus_Espach]

This didnt work for me. We have the same problem here, but even if I put services to "ANY" the connection is not allowed.

Do you have a further idea?

Best regards

[NorthernNetGuy]

Hi Linus,

Any doesn't actually match for any service, only servies that are marked as being able to be matched by any.

If I remember correctly neither of the SIP protocols are matched by any, so you would need to specify them or modify them to be matched by any.

I'd recommend making a rule specifying your sip traffic. If you are seeing your SIP traffic in your logs, is it being accepted or blocked?

[Linus_Espach]

Hi David,

according to the documentation, the match for any should only take place, when there are more then one service, that matches the connection:

"Match for Any: Indicates whether this service is used when 'Any' is set as the rule's service and there are several service objects with the same source port and protocol."


I have also tried to use "sips_tcp_tls_noprotocol" and "sips_tcp" but without success. The log shows drops, with stating "Encrypted VoIP signaling over TCP is not allowed" and "In order to allow the inspection of encrypted SIP over TLS connections, please add the 'sip_tls_with_server_certificate' service to the relevant rule,
make sure that the 'sip_tls_authentication' service is removed from the rule and configure TLS on the corresponding SIP Server object" but there is no such service-object.

[crengifo]

Hi Linus,

I am having the same issue. My rule uses the following services: TCP3100-33499; gsip_tls_not_inspected; gsip_any-tcp. Seeing the logs, I found that several ports are being dropped using the gsip_tls_authentication (TCP/33227) object and so on.

Any idea how to fix it?

Thanks.

[jorgefarinha]

It worked for me using sip_tls_not_inspected instead of sip_tls_authentication