- Products
- Learn
- Local User Groups
- Partners
-
More
Celebrate the New Year
With CheckMates!
Value of Security
Vendor Self-Awareness
Join Us for CPX 360
23-24 February 2021
Important certificate update to CloudGuard Controller, CME,
and Azure HA Security Gateways
How to Remediate Endpoint & VPN
Issues (in versions E81.10 or earlier)
Mobile Security
Buyer's Guide Out Now
Important! R80 and R80.10
End Of Support around the corner (May 2021)
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:
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:
SIP rule:
Example:
A similar description can be found in SK104082.
Regards,
Here you can find the old comments to this article for the old version:
It is a nice solution!
But it works!
THX
Afri
Is it correct to drop the rtp packets to the provider?
It is voodoo
Regards
Hanko
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
This solution solves our issue.
Nice voodoo hack.
Regards
Joerg
Check Point not VooDoo:-)
Yes, it solves pur issues.
thx
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
This hack works fine!
THX
This solution works fine.
THX
Kai
For GAiA i would suggest R80.30 VoIP Administration Guide and sk95369: ATRG: VoIP
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?
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
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 😄
I would ask TAC for help !
It is application (traffic) and URL filtering based ! VoIP is a very broad theme, see sk95369: ATRG: VoIP 😎 I would contact TAC to resolve the issue - the alternative, defining an own set of categories, is rather time-consuming...
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
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...
Checkpoint appliance 28000 using VSX
Checkpoint appliance 28000 using VSX running Gaia R80.20 HF 141.
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
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.
About CheckMates
Learn Check Point
Advanced Learning
WELCOME TO THE FUTURE OF CYBER SECURITY