Intermittent VOIP One Way Audio

[beneaton]

Hi,

I am seeing an issue with intermittent one-way audio / transmission on VOIP calls.
Happens every 1 in 6 or 7 calls I'd say.

If the issue happens mid-way through the call, logs show as normal/accept/matched to rule 47, etc.
The immediate call after that more often than now has OWT from the start - that shows in the logs as an accept, but with the protocol error:

" Firewall - Protocol violation detected with protocol:(RTP), matched protocol sig_id:(1), violation sig_id:(9), (500) "

The rule it matches with is just 
Source Network Grp - Destination Network Grp - Any - UDP_4000-60000 and UDP-16000-16511 - Accept - Log

Any help appreciated, on whether the above is related/the cause or where to start troubleshooting - Difficult to start with as there is no actual 'drop'.

Thanks,

Ben

[beneaton]

- If the OWT happens mid-call, logs are accept/no protocol violation alert
- If a call is made straight after a call like above, OWT is present from the start, logs are accept WITH protocol violation alert
- Using NAT
- Panasonic NSxxx
- Gamma SP

[PhoneBoy]

Please provide some basic details about your environment like software/JHF version, whether NAT is involved, what rules you're using to aceept traffic, etc.

[beneaton]

Hi,

Check Point Cluster - R80.10
NAT is involved, yes.
The Rule accepting the traffic is
'a network/sipgrp' - ' another network/sip grp' - Any - UDP_4000-60000 and UDP_16000-16511 - Accept - Log
The log with the accept/alert has source port 16001, and destination service UDP/6167

No drops seen at all on Firewall

[HeikoAnkenbrand · Accepted solution]

Hi @beneaton,

Issue description:

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.

Take a look at this Articel. I had the same problem and could fix it with the following settings.

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

PS: This does not only affect SMB appliances.

[Chris_Hrachowy]

We had the same problem and could solve it with @HeikoAnkenbrandˋs solution.

Thank you

[Noam_Warhaftig]

Hi,

I'm Noam from CP-R&D, owner of VoIP development.

I read your question and answers and I would like to jump in.

Security-wise it's not recommended to open a dedicated rule for high-ports, the SIP handler should open the ports dynamically be demand.

We inspect SIP control packets and decide what ip/port should be opened for every call.

From the look on your problem it seems to be related to NAT not being done properly on the payload, that's usually the root cause for one-way audio.

More than that, if RTP matches the rulebase instead of being open dynamically, it won't be NATted correctly.

If you would like to debug the configuration please contact me directly - noamwa@checkpoint.com

Thanks.

[Daniel_Taney]

If you all don't mind, I'd like to piggyback on this thread because it seems to be very pertinent to an issue we are having with our remote users right now. 

I have a case open with TAC and they also pointed me to sk65072. I had a few followup questions; which they haven't responded to yet. I know they are so insanely swamped right now, I figured maybe someone in this thread might be able to clarify them and free up some precious TAC cycles...

1.) Not to sound too dumb here, but when it says remove that list of SIC protocols from the rule base, it literally means just remove their usage in the Access Policy through which the affected traffic is flowing? 

2.) My next question feels equally as dumb, once I remove them from the Rulebase, how is the traffic going to be allowed? Is that where fw ctl set int voip_multik_enable_forwarding 0 comes into play?

I realize both of these questions sound super-basic, but I guess I never got a good foundation on how Check Point handles SIP and possibly how it differs from how most other traffic is dealt with?

I really appreciate any clarity you all may be able to provide!

-Dan

[Daniel_Taney]

TAC responded and clarified a number of my confusions.

1.) The idea is to replace the referenced SIP services with custom ones. So, yes, they need to be removed, but you need to put custom ones in their place. (Makes total sense).

2.) The thing I wasn't picking up on was that the presence of ANY of those SIP services in the entire rule base affects the way SIP traffic is handled. It doesn't just pertain to the one access rule your traffic is matching on. This was where I was getting stuck because I had replaced services in the rules the traffic should be matching to, but it was still dropping. 

This happens because the presence of those "built-in" SIP services referenced in the SK in the rule base actually inserts fw early SIP NAT (sipnat) into the in-chain of the Gateway. Once that is in the chain, all SIP traffic is getting intercepted by it, regardless of how your services in the rule base are defined. 

Understanding all this now, I can confirm that once I replaced all instances of the built-in SIP services from this particular rulebase + installed policy the fw early SIP NAT (sipnat) vanished from the fw chain!

3.) So, I guess my only unresolved question is whether the voip_multik_enable_forwarding variable still needs to be set to 0. At the moment, the GW still has this variable set to 1.

[Noam_Warhaftig]

Hi Dan,

I understand that you try to disable SIP handlers but as I tried to say, it's not recommended.

If you have a problem with one-way audio, the best path is to debug it and understand what's wrong with the configuration (most cases it's a simple change).

If you use NAT you have to use the SIP handler as you need to NAT the SIP payload (SDP) as well as the IP headers.

Regarding voip_multik_enable_forwarding, this param defines if we direct all SIP connections to the global instance (CoreXL), so if you don't use the SIP handler you can disable it (set to 0) and let all instances deal with SIP for better performance.

To summarize, I suggest to open a ticket with TAC and try to solve the issue without disabling SIP handlers.

Cheers,

Noam.

[anstelios]

We are facing a similar issue with sporadic one way audio when remote access users' softphones communicate with internal IP phones and we see  "Firewall - Protocol violation detected with protocol:(RTP), matched protocol sig_id:(1), violation sig_id:(9), (500)" on the logs when the issue occurs.

We use custom tcp-5060 service for SIP(no inspection) and manual high-port rules.
We DONT use NAT, remote access (office mode) network is NOT NATed when they access internal VOIP network.

@Noam_Warhaftig 
Any ideas??

[Ross_Wood]

Anstelios did you get anywhere with this issue? We are having the same issues as you with the exact same setup.

[anstelios]

No!

Actually I believe this issue hasn't got the attention it needs from Checkpoint.

I have seen this issue in 3 different customer environments over the last few months and the problem is with SecureXL and encrypted voice(RTP) traffic that results in random one-way audio.

Just follow sk104468 and exclude the traffic with table.def entries and it will work just fine!

[Chris_Atkinson]

@anstelios @Ross_Wood Did you both open cases with TAC for this issue?

[anstelios]

Of course we have/had cases open, but going into heavy and lengthy debug plans is not something most of the customers are willing to do, especially when there is an easy solution to the problem with table.def exclusions.

Having said that, I believe this is a very common scenario (one-way audio due to acceleration of encrypted voice RTP traffic) and CP should be able to identify and fix the issue without needing heavy and lengthy debugs from every environment that faces it..  

[Chris_Atkinson]

sk179651 addressed several scenarios but there are some edge cases as I understand.

[Ross_Wood]

Yes I have opened a TAC case and the engineer has given me a hotfix for the issue. I will be installing it tomorrow morning to see if this fixes the issue.

[Ross_Wood · Accepted solution]

The patch provided from TAC didn't resolve my issue. But what did fix my issue was enabling the below:

The “Enable Back Connection (from gateway to client)”

[Manuel_Rodgers]

Hi @anstelios - We are having very similar issue with same setup. Did you ever determine a fix for this? We have tried many different solutions from TAC with no success.

[Antimatt3r]

Hello,

I'm having a very similar issue on Quantum Spark 1570 Appliance after updating the firmware to R81.10.10 (996002845).

All of the sudden the VOIP calls are intermitent (we cannot hear the caller speaking) on Yealink IP Phones, using an off-premise SIP Provider Service from 3cx.

I have attached pictures with the VoiP settings configuration from the web console, with the services and with the configuration from the 3cx console.

Can anyone please confirm if it is set up correctly?

Is it correct to use the FQDN of the 3CX as the Sip-provider? And to put the Network Connection in the Use on-premise phones without SIP server (PBX) settings?