Incoming VOIP calls disconnect after 30/31 seconds

[Mark_Edwards]

Hi all,

All of a sudden a customer is having issues with incoming VOIP calls (outgoing no issues).

Previously no issues and no changes on the firewall. 

You communicate for 30/31 seconds then the call are dropped.

Customer has an internal PABX with communicates with the VOIP provider's PABX.

If I change the SIP port on the rule that allows the external PABX to talk to the gateways external IP  (NAT to internal PABX) to use the pre-defined SIP port (with inspection) from a custom UDP 5060 port then the incoming calls are all good and don't disconnect.

However this breaks the audio on outgoing calls (both ways).

I have configured the rules/NATs as per the VOIP sk but that just makes it worse.

Current rules are like this:

Source                               Destination                     Service

Voip_provider_PABX --> Gateways_external_IP  udp_5060

                                     --> Internal_PABX_IP          udp_5060

Internal_PABX_IP  -->  Voip_provider_PABX         SIP_port

Internal_PABX_IP  -->  Voip_provider_RTP            udp range

NATs

Voip_provider_PABX --> Gateways_external_IP     udp_5060   translated destination = internal_PABX_IP 

Internal_PABX_IP  -->  Voip_provider_PABX           any port     translated source =  Gateways_external_IP 

Internal_PABX_IP  -->  Voip_provider_RTP           any port     translated source =  Gateways_external_IP 

Any ideas as seems to be a mis-configuration on the CP.

[AkosBakos]

Hi @Mark_Edwards 

The VOIP is always naughty thing 🙂

First the general steps according to the  VOIP ARTG guide:

Disable all special/advanced features and Software Blades and re-test:

• NAT
• SecureXL
• ClusterXL
• VPN
• etc.

"Previously no issues and no changes on the firewall. "

If not only the Firewall Blade is enabled, a good troubleshooting step can be to make a exception for this traffic on the Application Contron, URL Filtering blade, or in IPS etc.

I think there is no drop on SmartLog

Akos

[Gaurav_Pandya]

In addition to the AKOS's suggestion, you can test with creating new service for SIP & UDP_5060 and select "match for any" option in those services. Create a rule with these custom services.

[Mark_Edwards]

Hi, I did try that.

It fixes the incoming calls but breaks the outgoing - no audio. 

Have tried various SIP ports, etc to no avail. 

[AkosBakos]

Maybe involve TAC. There are a lot of unknown.

As I remember we had early NAT isssues in tha past. Sometimes some calls disconnected randomly. It was really tricky

The TAC helped us in the investigation, and they solved our problem.

Akos

[the_rock]

I can tell you every time I ever worked with customer that had voip issues, TAC gave us below:

https://support.checkpoint.com/results/sk/sk95369

Now, I dont expect you to go through the whole article (I dont think anyone ever has lol), BUT, here is one important thing I will say. In the old days of CP, most people would end up changing involved services to protocol none, rather than default one. So, say what you can do is clone sip, make sure poirt is 5060 and do below:

Hope that helps.

Andy

[Timothy_Hall]

Sounds like possibly some kind of delayed notification or timeout issue between the SecureXL connections table (fwaccel conns) and the INSPECT connections table (fw tab -t connections).  I'd suggest selectively disabling SecureXL for UDP/5060 (and any other related ports) to force all that traffic F2F and see what happens, see sk104468: How to exclude traffic from SecureXL.

[Mark_Edwards]

Hi Timothy,

I see that this is already configured as they had VOIP issues when the gateways were first implemented (few years ago).

I do have a TAC logged, maybe they will resolve it. 

[the_rock]

Did you try what I mentioned yesterday, with protocol none?

Andy

[Mark_Edwards · Accepted solution]

Hi,

Tried both but did not make a difference.

Resolved it by moving the VOIP rule higher up although couldn't see drop logs and the rule was been hit. 

Thanks everyone 

[Lesley]

From what I remember it was always recommend to move voip rules as high in the rulebase as possible to avoid performance issues and delay with voice. In recent versions i don’t think this should be needed anymore due performance optimization features. 

[the_rock]

Great job!