- Products
- Network Security
Next Generation FirewallNext-generation firewall for SMB, Enterprise, and Government
Security ServicesComprehensive security for your network security solution
Network Security ManagerModern Security Management for today’s security landscape
- Advanced Threat Protection
Capture ATPMulti-engine advanced threat detection
Capture Security applianceAdvanced Threat Protection for modern threat landscape
- Access Security
Cloud Edge Secure AccessDeploy Zero-Trust Security in minutes
Secure Mobile AccessRemote, best-in-class, secure access
Wireless Access PointsEasy to manage, fast and secure Wi-FI
SwitchesHigh-speed network switching for business connectivity
- Email Security
Email SecurityProtect against today’s advanced email threats
- Cloud Security
Cloud App SecurityVisibility and security for Cloud Apps
Cloud Firewall (NSv)Next-generation firewall capabilities in the cloud
- Endpoint Security
Capture ClientStop advanced threats and rollback the damage caused by malware
Content Filtering ClientControl access to unwanted and unsecure web content
- Product Widgets
- Product Menu Right Image
- Network Security
- Solutions
- Solutions Widgets
- Solutions Image Widgets
- Solutions Widgets
- Partners
- Partner Widgets
- Partners Image Widgets
- Partner Widgets
- Support
- Support Widget
- Support Image Widgets
- Support Widget
- Products
- Network Security
- Next Generation FirewallNext-generation firewall for SMB, Enterprise, and Government
- Security ServicesComprehensive security for your network security solution
- Network Security ManagerModern Security Management for today’s security landscape
- Advanced Threat Protection
- Capture ATPMulti-engine advanced threat detection
- Capture Security applianceAdvanced Threat Protection for modern threat landscape
- Access Security
- Cloud Edge Secure AccessDeploy Zero-Trust Security in minutes
- Secure Mobile AccessRemote, best-in-class, secure access
- Wireless Access PointsEasy to manage, fast and secure Wi-FI
- SwitchesHigh-speed network switching for business connectivity
- Email Security
- Email SecurityProtect against today’s advanced email threats
- Cloud Security
- Cloud App SecurityVisibility and security for Cloud Apps
- Cloud Firewall (NSv)Next-generation firewall capabilities in the cloud
- Endpoint Security
- Capture ClientStop advanced threats and rollback the damage caused by malware
- Content Filtering ClientControl access to unwanted and unsecure web content
- Product Widgets
- Product Menu Right Image
- Network Security
- Solutions
- Solutions Widgets
- Solutions Image Widgets
- Solutions Widgets
- Partners
- Partner Widgets
- Partners Image Widgets
- Partner Widgets
- Support
- Support Widget
- Support Image Widgets
- Support Widget
Some or all VoIP (SIP) invites are being dropped due to "242 Packet dropped - failed processing"
03/26/2020 
1,045 People found this article helpful
49,931 Views
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.
Related Articles
- All associated wildcard FQDN IP addresses do not display in the web browser
- How to Re-Install The Junk Store
- SonicWall NSv Series FAQ
Categories
- Firewalls > TZ Series
- Firewalls > SonicWall SuperMassive E10000 Series
- Firewalls > SonicWall SuperMassive 9000 Series
- Firewalls > SonicWall NSA Series
YES
NO