Assistance Required: Issue with UDP Port 5060 Packet Drop

[#1]

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,

 

 

[#2]

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,

 

 

[#3]

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,

 

 

[yourshamim]

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

[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

[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!

[AkosBakos]

🖕True Story!

[the_rock]

Fixed LOTS of issues that way back in R77 lol

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

[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

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

[PhoneBoy]

How precisely are you capturing packets?

[the_rock]

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

Andy

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

[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]

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

[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

[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 "

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

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

 

[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

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

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

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

 

[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 😞

[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 

[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

[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]

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.

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

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