Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
yourshamim
Participant

Assistance Required: Issue with UDP Port 5060 Packet Drop

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,

debug_dropped_Logs.PNG

dropped logs.PNG

0 Kudos
26 Replies
AkosBakos
Mentor Mentor
Mentor

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

----------------
\m/_(>_<)_\m/
0 Kudos
yourshamim
Participant

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

0 Kudos
the_rock
Legend
Legend

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

 

Screenshot_2.png

0 Kudos
AkosBakos
Mentor Mentor
Mentor

🖕True Story!

----------------
\m/_(>_<)_\m/
the_rock
Legend
Legend

Fixed LOTS of issues that way back in R77 lol

0 Kudos
PhoneBoy
Admin
Admin

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

0 Kudos
the_rock
Legend
Legend

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

0 Kudos
PhoneBoy
Admin
Admin

How precisely are you capturing packets?

0 Kudos
the_rock
Legend
Legend

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

Andy

0 Kudos
yourshamim
Participant

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

the_rock
Legend
Legend

Please let us know the outcome.

0 Kudos
the_rock
Legend
Legend

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

0 Kudos
Eric_Smith
Participant

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
0 Kudos
the_rock
Legend
Legend

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 "

0 Kudos
Eric_Smith
Participant

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?

 

0 Kudos
yourshamim
Participant

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.

virt-Defrag_error.PNG

0 Kudos
the_rock
Legend
Legend

Hey,

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

Andy

0 Kudos
yourshamim
Participant

I allowed service any at this moment for testing purposes.

0 Kudos
the_rock
Legend
Legend

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

0 Kudos
yourshamim
Participant

There is no IPS blade enabled on this FW.

Just to let you know, This is VSX. 

 

 

 

 

the_rock
Legend
Legend

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

0 Kudos
PhoneBoy
Admin
Admin

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

the_rock
Legend
Legend

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

👍

Andy

0 Kudos
yourshamim
Participant

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

0 Kudos
yourshamim
Participant

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

0 Kudos
PhoneBoy
Admin
Admin

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.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events