Disable NAT on SIP payload - breaks ICE

[David_Herselman]

How do we disable NAT on SIP and SDP payloads, when using NAT? The ATRG: VoIP documentation states the following:

We're running Asterisk with ICE (Interactive Connectivity Establishment), which essentially provides multiple candidates in INVITE or SDP negotiation messages, where each is an IP and port combination. It discovers the public candidates by connecting to STUN servers on the public internet.

Why would we not want the security gateway to NAT the payload?

We intend on using Bria Stretto as a mobile SIP application. The app works perfectly in all environments, when in the foreground and subsequently registered directly to our office SIP server. The problem we're having is when the app is in the background, becoming completely inactive. Public SIP servers operated by CounterPath essentially register in place of the mobile and send a wake-up push notification when they receive a call. The push appears to provide the app with a copy of the original invite, so it should receive both the higher priority ICE host candidates as well as the lower priority server reflexive (natted IP and port) candidates.

The problem with the Check Point overwriting the SIP and SDP payload is that a mobile device connected to either private cellular APN or corporate WiFi will exclusively be provided with the public IP and results in one way audio. Everything works perfectly when the mobile is using LTE or natted through a home WiFi network.

What we're after:

We would simply like the Check Point to continue applying a NAT policy to the headers but leave the SIP and SDP payloads alone. This is typically accomplished by simply turning off SIP ALG processing.

Sample packet leaving SIP server towards CounterPath's public push servers:

Sample packet after NAT processing by Check Point:

We have not had success in following the following recommendations. Both of these however appear to apply to cases where threat prevention policies were blocking packets, not the Check Point simply natting packets like any other UDP packet and leaving the payload alone:

• How to disable SIP ALG inspection in a specific rule in Checkpoint? Also Could this be done globally... 
• Tried disabling SIP inspection

fw ctl set int voip_multik_enable_forwarding 0
echo voip_multik_enable_forwarding=0 >> $FWDIR/boot/modules/fwkern.conf

The following is an excellent summation of the ICE protocol:

Interactive Connectivity Establishment: – IETF Journal 

[HeikoAnkenbrand · Accepted solution]

I hope I understand your problem!

If the following setting "fw ctl set int voip_multik_enable_forwarding 0" does not work, you still have the following option.

If you want to disable NAT in SIP content, you can also set the protocol type in  SIP service TCP to "none". This should also disable the SPI inspection. Therefore no PSL should be used in the F2F path or no PXL should be used in the medium path. This means that the passive streaming library is no longer used. So no SIP packet is manipulated anymore. You can find out more about PSL/PXL here R80.x Security Gateway Architecture (Logical Packet Flow)or here https://community.checkpoint.com/docs/DOC-3073-r80x-security-gateway-architecture-content-inspection.

The problem is that the negotiated RTP ports are no longer written to the state table. So you have to allow all RTP UDP high ports in a rule.

[David_Herselman]

Many thanks for your suggestion, your explanation does make sense but it's unfortunately not working.

We're running MDS so the global 'sip-tcp' object can not be edited or disabled. We have already created a replacement sip_tcp object and configured it not to reference a protocol. The security gateway has additionally been set to disable voip_multik_enable_forwarding. These steps were detailed in How to disable SIP ALG inspection in a specific rule in Checkpoint? Also Could this be done globally....

Herewith snippets showing the custom service object for SIP TCP:

Herewith snippets showing the custom service object for SIP UDP:

Searching for 'where used' on the default global objects shows no reference to these in the policies:

[David_Herselman]

Hrm... Restarted the security gateway and it's now working. Packet capture after the Check Point NAT shows it behaving as we want it to:

[Timothy_Hall]

Some kernel variables cannot be changed on the fly with fw ctl set int and have the expected effect; adding them to fwkern.conf and rebooting the gateway is necessary.  The relevant SKs don't say it is required for the voip_multik_enable_forwarding variable, but it sounds like this is the case based on your experience.

--
"IPS Immersion Training" Self-paced Video Class
Now Available at http://www.maxpowerfirewalls.com

[David_Herselman]

Hi Timothy,

Are you aware of a document which details the effects of the voip_multik_enable_forwarding variable and others? Searching Google and Check Point Support Centre for 'voip_multik_enable_forwarding' only yields referencing to flipping the switch on this magic variable, not a proper explanation of exactly what it does or disables.

Check Point Support Centre:

How to disable 'fw early SIP nat' chain / SIP inspection

MultiCore Support for SSL in R77.20 and above

[Timothy_Hall]

If I'm reading the SKs correctly, and the fact that the variable contains "multik" (which is another word for CoreXL), I'd say if this variable is set to 1 (the default) it allows VoIP traffic including the SIP handler to be processed by several Firewall Workers (kernel instances) instead of all VoIP traffic being handled by instance 0 (typically the highest numbered CPU).  In gateway releases prior to R80.10, most VoIP and IPSec VPN traffic could only be processed by the lowest-numbered Firewall Worker, as these inspection features were not completely compatible with CoreXL.  Some portions of VoIP handling may still not be completely compatible with being spread around multiple worker cores by CoreXL, and I assume setting this variable to 0 moves all VoIP processing back onto a single worker core.

--
"IPS Immersion Training" Self-paced Video Class
Now Available at http://www.maxpowerfirewalls.com

[AntonMakarychev]

We have the same problem. One exception - the traffic goes through VPN tunnel. I changed SIP services to custom one.

No we have internal IP inside SIP packet but source still External IP of the gateway.

What should I do to change this situation? I need the packet to be with internal IP of the phone server as it goes through VPN site-to-site tunnel.

[LostBoY]

Did you find a solution to this prob ?  if yes how did you rectified it