Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted

SIP over TLS non standard ports

Jump to solution

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:

2019-07-23_11h28_55.png

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.

1 Solution

Accepted Solutions
Highlighted

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.

View solution in original post

5 Replies
Highlighted

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.

View solution in original post

Highlighted
Participant

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

0 Kudos
Highlighted

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?

0 Kudos
Highlighted
Participant
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.
Highlighted
Explorer

It worked for me using sip_tls_not_inspected instead of sip_tls_authentication

0 Kudos