Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
beneaton
Contributor
Jump to solution

Intermittent VOIP One Way Audio

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

2 Solutions

Accepted Solutions
HeikoAnkenbrand
Champion Champion
Champion

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.


➜ CCSM Elite, CCME, CCTE

View solution in original post

Ross_Wood
Participant

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)”

Ross_Wood_0-1688605084819.png

 

View solution in original post

18 Replies
beneaton
Contributor
- 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
0 Kudos
PhoneBoy
Admin
Admin
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.
0 Kudos
beneaton
Contributor
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
0 Kudos
HeikoAnkenbrand
Champion Champion
Champion

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.


➜ CCSM Elite, CCME, CCTE
Chris_Hrachowy
Participant

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

Thank you

0 Kudos
Noam_Warhaftig
Employee
Employee

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.

0 Kudos
Daniel_Taney
Advisor

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

R80 CCSA / CCSE
0 Kudos
Daniel_Taney
Advisor

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.

R80 CCSA / CCSE
0 Kudos
Noam_Warhaftig
Employee
Employee

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.

0 Kudos
anstelios
Collaborator

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??

0 Kudos
Ross_Wood
Participant

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

 

 

0 Kudos
anstelios
Collaborator

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!

0 Kudos
Chris_Atkinson
Employee Employee
Employee

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

CCSM R77/R80/ELITE
0 Kudos
anstelios
Collaborator

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..  

0 Kudos
Chris_Atkinson
Employee Employee
Employee

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

CCSM R77/R80/ELITE
0 Kudos
Ross_Wood
Participant

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.

0 Kudos
Ross_Wood
Participant

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)”

Ross_Wood_0-1688605084819.png

 

Manuel_Rodgers
Explorer

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.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events