Assistance Required: Issue with UDP Port 5060 Packet Drop

[yourshamim]

Dear Checkpoint Experts,

I am encountering a unique issue while connecting to one of the voice servers on UDP port 5060. The behavior observed in the logs is inconsistent:

• The zdebug logs indicate the reason for the packet drop as "fw_record_data_conn_module."
• However, the Tracker shows the reason as "SIP Re-invite exceeds the limit."

I have attached a screenshot below for your reference.

Could you please guide me on how to resolve this issue? Your assistance would be greatly appreciated.

Best regards,

 

 

[AkosBakos]

Hi,

Have you checked this sk already? 

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

---------------------

Solution

Use this formula to tune the parameter that controls the interval at which re-INVITE messages (sip_expire):

Session-Expires * sip_expire / 100 < Min-SE

Where:

• Session-Expires = SIP session expiration lifetime, as agreed by the SIP hosts
• sip_expire = Interval at which the Check Point Firewall will expire a re-INVITE from the call queue
• Min-SE = Interval at which the SIP hosts will send re-INVITE messages to refresh the SIP session

To determine the "Session-Expires" value in the SIP header, capture the SIP INVITE request and response:

Expert# cppcap -c 0 -f 'port 5060 and ((udp[20:4] = 0x52454749) or (udp[20:4] = 0x494e5649))' -o /var/log/sip-invite.pcap

Open the capture in Wireshark and filter for INVITE requests that contain a Min-SE value and INVITE responses that contain a Session-Expires value:

Filter= (sip.Request-Line ~ "INVITE" && sip.Min-SE) || (sip.Status-Code == 200 && sip.Session-Expires)

Review the data pane of the filtered packets for the value in the relevant fields:

Min-SE value from INVITE request:

Session Initiation Protocol (INVITE) → Message Header → Min-SE

Session-Expires value from INVITE response:

Session Initiation Protocol (200) → Message Header → Av-Global-Session-ID → Session-Expires

For example, if analysis of the SIP handshake determines that Session-Expires=120 and Min-SE=60, sane values for sip_expire can be determined by solving for x in this inequality:

120 * x / 100 < 60
120 * x < 60 * 100
120 * x < 6000
x < 6000 / 120
x < 50

Therefore, a sane value for the sip_expire kernel parameter in this example would be 45.

To check the current values of the kernel parameters on the Check Point Firewall:

Expert# fw ctl get int sip_max_reinvite
Expert# fw ctl get int sip_expire

Should modification of these kernel parameters prove necessary, refer to sk26202, or the Quantum Security Gateway Administration Guide for your version.

If, after tuning the sip_expire parameter according to the configuration of your SIP implementation, you still observe intermittent drops of this nature, consider also tuning up the sip_max_reinvite parameter to allow for calls to be held longer.

Akos

[yourshamim]

I tried, but no packets were captured in the pcap file (zero packets). Traffic is continuously coming on port 5060.

[the_rock]

I know in the old days of CP, people would use below method, though back then, it would say NONE (that exact word), now its bit different, but sort of same principle.

Andy

[AkosBakos]

🖕True Story!

[the_rock]

Fixed LOTS of issues that way back in R77 lol

[PhoneBoy]

sip-tcp already has the protocol signature disabled (at least in R82).

[the_rock]

Does not seem to be the case in R81.20 (sip-tcp-proto), but in R82, I checked demo and its exact same thing.

Andy

[PhoneBoy]

How precisely are you capturing packets?

[the_rock]

Hey @yourshamim , were you able to make any progress?

Andy

[yourshamim]

Not yet. I have raised a TAC case, and the TAC engineer is currently looking into it.

[the_rock]

Please let us know the outcome.

[the_rock]

Hey @yourshamim ...just wondering, are you able to try what was suggested with protocol none in the service and see if it makes any difference?

Andy

[Eric_Smith]

I ran the cppcap as indicated and am getting a failure for syntax. Ran it on a lab box same error. Is an interface required for the cppcap command?  

cppcap -i eth1 -c 0 -f 'port 5060 and ((udp[20:4] = 0x52454749) or (udp[20:4] = 0x494e5649))' -o /var/log/sip-invite.pcap

[the_rock]

Just use example from the site my colleague made while ago.

Andy

https://tcpdump101.com/#

Something like below, but you can do your own filters.

cppcap -o test.pcap -i eth1 -f " host 1.1.1.1 "

[Eric_Smith]

cppcap -i any -c 0 -f 'port 5060 and ((udp[20:4] = 0x52454749) or (udp[20:4] = 0x494e5649))' -o /var/log/sip-invite.pcap

This looks like it worked, does the SK need to be updated to reflect the -i any? 

[yourshamim]

Hi guys,

On the user's side, they restarted the server during troubleshooting. FW is getting a Virt Defrag Timeout error in the tracker and Zdebug. The tracker is receiving traffic on UDP port 0.  

surprisingly TCPdump capture showing UDP port 5060.  we have another round of troubleshooting call today with CP TAC and Avaya team.

 

[the_rock]

Hey,

How is sip-tcp service configured atm? What does protocol option show?

Andy

[yourshamim]

I allowed service any at this moment for testing purposes.

[the_rock]

Just an idea...did you try disable IPS blade as a test?

[yourshamim]

There is no IPS blade enabled on this FW.

Just to let you know, This is VSX. 

 

[the_rock]

Got it. In that case, Im out of ideas, sorry 😞

[PhoneBoy]

You can allow traffic on port 0, FYI.
See: https://support.checkpoint.com/results/sk/sk27109 

[the_rock]

Never seen that sk before, thanks for sending it @PhoneBoy 

👍

Andy

[yourshamim]

Thanks, @PhoneBoy . I will change the value and share the status update.

[yourshamim]

I changed the value to 1 through the set command but not Luck. same drop reason " Virt Defrag Timeout" and service UDP/0.

[PhoneBoy]

The fact you're hitting this error means you are receiving fragmented packets.
Prior to inspection, we "virtually reassemble" the packet in memory. 
If we don't receive all the fragments for the packet in time, we generate a timeout message.

You can adjust the virtual defragmentation timeout setting.
While this is configured in the Threat Prevention settings, it's a Firewall setting, as is everything else in the Inspection Setting.
See: https://support.checkpoint.com/results/sk/sk65074 

Ideally, though, you should figure out why you are receiving fragmented packets in the first place.
That is specific to the application/network and may indicate an MTU issue somewhere in the network path.