topic Re: fwconn_init_links (INBOUND) failed in Spark Firewall (SMB)

fwconn_init_links (INBOUND) failed

biskit — Thu, 18 Apr 2019 19:22:33 GMT

Has anyone come across a problem with Skype (VoIP calls) working intermittently through a 1400?

Sometimes it works perfectly. Other times it doesn't. There's no apparent pattern to when it will or won't work.

The customer has a centrally managed cluster of 1470 appliances and to date we've upgraded the firewall from R77.20.60 to R77.20.86, disabled SecureXL as a test and disabled Protocol Inspection on port 5060 but none of these changes have resolved the issue. The issue manifests itself as follows;

When we call inbound, e.g. mobile phone to Skype DDI
• Skype rings
• you can answer the call
• there is 5-10 seconds of silence (neither party can hear each other)
• the call disconnects

When we call outbound, e.g. Skype to a mobile phone
• we hear the Skype internal ring tone for roughly 5 seconds.
• the call disconnects.
• error logged on Check Point (zdebug) fw_log_drop_ex: Packet proto=17 172.30.241.26:51306 -> xx.xx.xx.xx:3478 dropped by fw_handle_first_packet Reason: fwconn_key_init_links (INBOUND) failed;)

Error seen on the Active cluster member;
[Expert@rdg3corpfw01]# fw ctl zdebug drop | grep 172.30.241.26
;[cpu_1];[fw4_1];fw_log_drop_ex: Packet proto=17 172.30.241.26:51306 -> xx.xx.xx.xx:3478 dropped by fw_handle_first_packet Reason: fwconn_key_init_links (INBOUND) failed;

We see the drops every time it fails. When it works there's nothing in zdebug. There are no drops in Tracker that seem relevant either.

I note sk86984, but that refers to custom protocols, so I don't think that applies in this case?

Anyone got any thoughts?

Cheers,

Matt

Re: fwconn_init_links (INBOUND) failed

HeikoAnkenbrand — Thu, 18 Apr 2019 19:27:08 GMT

I had that problem, too. I have described it in this article, how you can solve it.
This is also valid for real gateways and not only for SMB appliances.

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

Re: fwconn_init_links (INBOUND) failed

HeikoAnkenbrand — Thu, 18 Apr 2019 19:29:18 GMT

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 appliance:

RTP rules:

Create a service for the UDP high ports and use it in an incoming Accept rule, which also has to allow the RTP ports.
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:

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

Example:

Re: fwconn_init_links (INBOUND) failed

biskit — Thu, 18 Apr 2019 19:42:07 GMT

@HeikoAnkenbrand thanks for your quick reply. I don't have access to their phones to test afterwards so I'll forward this on to the customer and ask them to implement the change and then test it 👍

Re: fwconn_init_links (INBOUND) failed

HeikoAnkenbrand — Thu, 18 Apr 2019 20:03:52 GMT

Write me if this worked.

Thanks

Heiko

Re: fwconn_init_links (INBOUND) failed

Juan_ — Wed, 09 Feb 2022 12:23:37 GMT

This worked for me Heiko.

Customer's cisco was initiating the RTP connection with the Known port 8208 as sPort (opposite to using it as dPort as it should I assume)
The Ckp was Natting-Patting IP and port, but then the RTP provider was returning the packet with 8208 again.

Since there are no valid symlinks for a return packet on 8208 we were getting "fwconn_init_links (INBOUND) failed"

Having applied the outbound Drop, the connection is always initaited from the provider, which initiates the connection correctly, matches static nat inbound, and works fine.

Juan