Some or all VoIP (SIP) invites are being dropped due to "242 Packet dropped - failed processing"

03/26/2020 1042 18528

DESCRIPTION:

After upgrading to 5.8 firmware or higher from 5.6 (or 5.7), or after replacing a Gen4 on SonicOS 4.x or Gen 5 device on 5.6 or lower firmware with a Gen6 device, VOIP invites can only be made from some locations. 

Example:  Cell phones can still call in to phones behind the firewall, but soft-phones or hard-phones using VOIP within the organization cannot call one another. 

In this example, the PBX is hosted upstream. 
 

The HTML export of a packet capture (or viewed on the firewall) will reveal that SonicWall is dropping the SIP invite with Drop code 242, which corresponds in the drop code matrix to  "Packet dropped - Failed processing".  This drop code number may change in future versions higher than 5.8.1.14, but the reason for dropping packet will stay the same in the drop code matrix.

The following steps delineate how to find the invite packet in the capture, illustrate why this traffic is dropped, and provide the resolution. 

RESOLUTION:

Step 1:  Opening this capture in Wireshark will allow you to find your VOIP call
  
 
Step 2:  Analysis of the call flow reveals that the invites are sent, but there are no responses.  Selecting the invite packet will highlight the packet number in Wireshark
 

Step 3: Selecting this line in the Graph Analysis directs us to packet 771

Reason:  In this example, review of the capture shows us that 770 is a UDP fragment of packet 771.  772 and 773 also correspond to a fragmented UDP packet that was sent to the SonicWall from a remote location at a packet size larger than 1514 bytes on the wire, and therefore had to be fragmented. 

Although some routers might pass this traffic, the SonicWall is a security appliance, and will drop this traffic.  This is reflected in the HTML export of the capture, or when viewed before export directly on the firewall.
 

Fragmented UDP traffic, especially SIP traffic, is a clear violation of RFC protocol, which SonicOS Enhanced firmware 5.8 and above very strictly adhere to in these circumstances. RFC 3261 is the RFC standard for SIP traffic, and states the following: 

18.1.1 Sending Requests  The client side of the transport layer is responsible for sending the request and receiving responses. The user of the transport layer passes the client transport the request, an IP address, port, transport, and possibly TTL for multicast destinations.  If a request is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU is unknown, the request MUST be sent using an RFC 2914 [43] congestion controlled transport protocol, such as TCP.  

To read more, see http://www.ietf.org/rfc/rfc3261.txt 

SonicOS enhanced firmware 5.6, which is no longer supported, was less RFC compliant on this, but 5.8 has enhanced security by becoming more strict.   RFC 4693 goes into additional detail regarding security concerns of unnecessary packet fragmentation. 

How to Test:

When a call comes in that is less than the MTU and does not need fragmentation, (for instance: from a Cell phone rather than from the VOIP phone within the organization) the invite is forwarded to the phone on its registered socket as expected. 

Comparison of a call with an invalid packet size (left) and a valid packet size (right) show that there are additional headers added onto the SIP datagram that are not necessary, bloating the packet:
 

Removal of unnecessary information on the originating devices or SIP servers will bring the SIP invite packet to a smaller size, and therefore within the size of the MTU path, allowing the packet through.   In this case, the X-nt-alter-id value can be removed, and bring the packet to a size lower than the MTU path.

Another method of working around this while fitting into RFC compliance as cited above would be to use SIP over TCP instead of SIP over UDP if fragmentation is required.  Many vendors do not use this, however, as UDP audio or video streams do not need to rely on verification that a packet arrived, whereas TCP does.