VoIP Issue and SMB Appliance (600/1000/1200/1400)

[HeikoAnkenbrand]

Issue description:

Many of our customers have reported the following issue in recent weeks. Telephone VoIP connections are terminated and can no longer be established.

Issue debug:

On the firewall you see a typical issue with the following message if you start: # fw ctl zdebug drop

Issue message: fwconn_key_init_links (INBOUND) failed

Solution:

There are two different Servers on the SIP/RTP provider's side that take part in the process of establishing the SIP/RTP call:

• Server for SIP (Management and control)
• Server for RTP (Media and Voice Data)

Make sure that the UDP high ports from the internal RTP VoIP telephone system to the provider RTP server on the RTP provider's side are dropped by the rule base on 600 / 1100 / 1200 / 1400 appliance:

RTP rules:

1. Create a service for the UDP high ports and use it in an incoming Accept rule, which also has to allow the RTP ports.
2. Create a drop rule to block outgoing connections from the Internal RTP server (VoIP telephone system) to the provider's RTP server on high UDP ports

SIP rule:

1. Create an allow rule for incoming and outgoing SIP traffic on UDP port 5060

Example:

A similar description can be found in SK104082.

Regards,

Heiko

[R89_99]

Here you can find the old comments to this article for the old version:

VoIP Issue and SMB Appliance (600/1000/1200/1400) [old] 

[Afri_Guel]

It is a nice solution!

But it works!

THX

Afri

[Hanko_Alderson]

Is it correct to drop the rtp packets to the provider?

It is voodoo

Regards

Hanko

[HeikoAnkenbrand]

Yes, it is VoIP Voodoo! 

It is correct! You need a drop rule!

Regards

Heiko

[Levin_Swizell]

We have the same problem in Switzerland. Couldn't use the 1400 appliance for VoIP and used the 3000 appliance.
Blocking outgoing RTP packets has been helpful for us.

THX
Levin

[joerg_weller]

This solution solves our issue.

Nice voodoo hack.

Regards

Joerg

[Ali_Yaymaci]

Check Point not VooDoo:-)

[Talma_Maharam]

Yes, it solves pur issues.

thx

[M_Musa]

Hi,

Heiko Ankenbrand Thanks for the tip much appreciated, after following the article we can get inbound call working with two way audio on a CP1430 appliance, however outbound audio does not work at all (appears the call is established), had quite a few CP tech's take a look but no real progress, does anyone have any ideas? Any help would be much appreciated.

MM

[Luke_Maaravi]

This hack works fine!

THX

[Kai_O_]

This solution  works fine.

THX

Kai

[Theo]

is this applicable to 2200 R80.30 also?

[G_W_Albrecht]

For GAiA i would suggest R80.30 VoIP Administration Guide and sk95369: ATRG: VoIP

[tvquyen]

is this applicable to Check Point 1490 Appliance Version: R77.20.31 (990170952) also?
Tks!

[00071491]

What is the UDP High Port range mentioned that we create the service for in the 600/1000/1200/1400 firewall?  Which port numbers should we be using?

We are having one-way audio issues with a Cisco CUCM environment immediately after upgrading our 5600 series cluster from R77.30 to R80.20 a couple of days ago.  We have an open support case with CheckPoint support on this matter so still working through the issue.  

Our scenario is that we don't traverse the PSTN traffic through our primary 5600 cluster; all Phone traffic is internal with the exception we have 4 small remote offices that we extend our network to.  The remote offices are 600 series models.  The only devices on the remote side are 1-2 PCs and a couple of Cisco 7900 series phones at each location.  

Because of the VPN, we see a lot of encrypt and decrypt messages in the smart logs.  When issuing the fw ctl zdebug drop command, we aren't seeing 'like fwconn_key_init_links (INBOUND)' messages or similar.

Is it likely this fix would apply to my scenario where the Call routing and call control are housed behind the 5600 cluster?  

[Ilmo_Anttonen]

What if the problem is OUTBOUND?

I have a centrally managed 1430 with two phones behind it. The whole network that the phones are on is hidden behind the appliance. The first phone to register functions normally but the second one does not perform NAT on SIP payload packets. The following message appears on fw ctl zdebug drop: 

dropped by fw_conn_post_inspect Reason: fwconn_key_init_links (OUTBOUND) failed;

The GW object in SmartConsole has the interfaces correctly defined, I have tried adding the GW in the destination column of the allow rule for the SIP traffic (some SK suggested this) and the SIP protocols are defined without specific protocol, accept replies and 'match for any'.

I cannot figure out a solution for this. It just suddenly stopped working after all being good for ages.
The appliance runs on R77.20.85 - Build 751

[Ilmo_Anttonen]

I have solved this now.

We had previously created custom udp/tcp ports for SIP to make things work with this specific VoIP provider. In these custom protocols we left the protocol undefined and just entered the port ranges. This was to avoid problems with inspection that we had experienced in the past. Suddenly this problem with the 2nd-phone-to-register-does-not-get-it's-payload-NATed-issue appeared anyway. Finding no way forward with the current protocols I decided to try to clone the default SIP UDP object and enter the port range there and then change the inspection settings according to below:

It was checkpoint support who gave me the idea. I had already told them that we don't inspect SIP because we don't use the standard protocol objects but when they suggeted this change despite the fact, I decided to change to the inspected object and try this and then rebooted the mgmt server and the appliance. So this was the solution.

Hope someone finds this before spending two days on the issue 😄

  

[tvquyen]

Can I configure call-in on checkpoint 1490 R77.20.31? currently blocking RTP with no sound.Tks!

[G_W_Albrecht]

I would ask TAC for help !

[marcherren]

I also had issues with VoIP (no Audio) on my 1530 FW, but once I set either:
URL Filtering only

or

On but without "Block security risk categories"

it works flawlessly!!

I thought "Block security risk categories" was based on URL filtering?

Marc

[G_W_Albrecht]

It is application (traffic) and URL filtering based ! VoIP is a very broad theme, see sk95369: ATRG: VoIP 8) I would contact TAC to resolve the issue - the alternative, defining an own set of categories, is rather time-consuming...

[CPRQ]

We have same issue, sip traffic works fine on R77 but now we moved traffic to R80.20 HF 141 it stopped working. Our internal edge servers with 10.10.x.x going out to (cloud) internet. So 10.10.x.x hide nat with public IP. so our Internal firewall has rule source:10.10.x.x dest: internet ports: sip 5060, 5061, udp-16384-32768. Source IP hide Nat 150.1.1.1 and our external firewall open rule from 150.1.1.1 to internet ports any. We are controlling rules on internal firewalls. Is  R80.20 hf141 is good version to support this? And do we need to change rule on internal firewall? External firewall has common rule so we don't need to change. Thanks

[G_W_Albrecht]

Which SMB GW do you speak of - either you can run R77.20.xx or R80.20.xx ? Or do you mean CP GAiA GWS, not Embeded GAiA ? Then this is the wrong discussion...

[CPRQ]

Checkpoint appliance 28000 using VSX

[CPRQ]

Checkpoint appliance 28000 using VSX running Gaia R80.20 HF 141.

[CPRQ]

Is this common issue sip-tls traffic stop working when move traffic from R77 to R80? Same rule set worked in R77 but not on R80. if yes how to fix it? Thanks

[CPRQ]

Issue resolved. Checkpoint provided 2 pre-configured services ports for sip_tls tcp-5061. One sip_tls_authentication and other sip_tls_not_inspected, We changed to sip_tls_not_inspected; it allows SIP over TLS to pass without inspection and it resolve the issue. Also need to open the media udp-high ports manually.