SIP Traffic is not working in R80.20

[JAYARAM_P_M1]

Hi Team,

Setup is VOIP phones connected to Switch, Switch is then connected to Firewall

VOIP Phones able to make call only when it is connected to VOIP Server over the internet.

1. Customer upgraded firewall from R77.30 to R80.20

2. In R77.30, the firewall rule base is like

---> Network_A Any Any Accept

We can say VOIP network as Network_A which is Hide NAT (behind gateway)

And in Applictaion rule base is

--> Network_A Internet [SIP Communicator, SDP over SIP, SIP messaging, SIP Protocol, Network Protocols Category] Accept

SIP traffic is working fine with R77.30 version.

3. But the same is not working in R80.20 and getting the below errors:

--> fw ctl zdebug shows the multicast IP 224.0.1.75:
@;78481;[cpu_1];[fw4_0];fw_log_drop_ex: Packet proto=17 :5060 -> 224.0.1.75:5060 dropped by fw_first_packet_outbound_init Reason: failed to get outbound interface;

--> tcpdump shows:

For example: Source IP is 10.10.10.10

arp who has <10.10.10.20 -- internal ip> address tell 10.10.10.10

--> But in Logs and Monitoring view, the SIP traffic is getting dropped with the message information: Missing OS Route

Kindly let me know how can we resolve this issue.

[Sarm_Chanatip]

Hi Jamaram,

Do you disable Anti-Spoof on an external interface?

Regards,
Sarm

[JAYARAM_P_M1]

Didn't tried to disable the anti spoofing but tried by connecting VOIP phone directly to firewall.

I will try to disable and will let you know.

[Sarm_Chanatip]

Ok, I'm assuming that your external interface is enabled already with detecting or preventing something like that.

I'm gonna share my case regarding sip traffic with a one-way audio issue that found in R80.20 last month and already resolved by installing special hotfix provided by Check Point RnD

1.Regarding the provided hotfix only addresses a portion of the problem (leaving the anti-spoofing behavior).
- Can you clarify me more about the first issue that we met? If I’m right Noam said that this it caused by sending duplicate from SDP protocol.

Answer: Based on Noam's explanation of the behavior, it was taking place due to how the SIP server was sending a duplicate SDP packet flow on an existing connection. Since the Check Point gateway is not set to accept a duplicate packet flow for an already established connection, it was not handled.
The hotfix that Noam created was to allow the acceptance of this duplicate SDP flow on an existing connection to accommodate the method that the SIP server was using.

2. Regarding using NAT with the VoIP setup, it is crucial to get those directions correct. As of now, when anti-spoofing is disabled we cannot make that determination and this bug would need to be fixed.

- This will be happened when we disable anti-spoofing on an external interface, right? Because after the session yesterday’s I tried to test a bit more and found this only happens particular on an external interface. And I would like you to describe more regarding the behavior of a call comes from an external to an internal, if possible.
And how checkpoint makes determination that which call directions coming from.

Answer: It is an issue when anti-spoofing is disabled on the involved interfaces - so yes, in your test of an external to internal call, the forst interface that would handle the call flow was the external interface and due to the bug, if anti-spoofing is disabled then the call will not function as expected.
The way a Check Point gateway should determine the direction of a call would be from what defined interface receives the packet first - either an internally or externally defined interface. Since the issue is caused by anti-spoofing being disabled and not an issue with the topology setting for the interface (where an external interface was incorrectly defined as internal)

PS. In my customer environment, we used static NAT for VoIP

Regards,
Sarm

[HeikoAnkenbrand]

I think it is the same issue as described in my article:

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

[Bryce_Myers]

We saw the same issue after upgrading our gateways to R80.20. In our case the traffic was also being dropped in R77.30 but it wasn't logged. Since we don't participate in PIM the firewall doesn't know where to route the multicast traffic.

It might be related to your protocol handlers for VOIP traffic - have you tried configuring Rules on the R80.20 gateway that will actually match the VOIP setup instead of the Any/Any Accept?