Firewall has begun dropping SSH response
Ahh, the joys of figuring out why the bloody Sonicwall drops packets. Welcome to owning an NSA appliance.
First off, point at that drop message in the Sonicwall's admin page. You should see a pop up message, and included in that will be a 'message ID'. You can cross reference that value with the Drop Codes listed here (for firmware version 5.6.0.x). If you're using an older firmware, here's version 5.5.0.x or version 4.2.0.x. The codes are pretty vague, but it might help you get on the right path.
Alternately, you can do a packet dump, and the drop code and module ID will be listed in the packet capture interface when you look at the dropped packet.
--Christopher Karel
Is a problem in how Linux manage the MTU negotiation (tcp_mtu_probing). Most linux boxes comes with a mode where Linux doesn't negociate in an alternative way to the standard (which by other side is insecure, and thats why Sonicwall doesn't accept it). You can fix in your linux box by doing this:
echo 2 > /proc/sys/net/ipv4/tcp_mtu_probing
So the problem is Sonicwall refuses to negociate MTU size by using the "first" and most standard method because is insecure, and Linux refuses to negotiate MTU size by using the "alternative" method, which is more secure but less efficient.
Result, you're fucked. This only happens in situations where the firewall cannot fragment by itself the package due a cyphered payload which needs to be recomposed in the source, not in transit. That's why seems to be a lot of issues with SSL, SSH and other crypted connections.
With OpenSSH you can "hack" the way it negotiate the need of resizing the payload, by touching some options in the openSSH client options, but you may found the problem by using other application, so it's better to fix the problem by altering how the kernel manage this situations, if not, you can fix SSH but later found problems with SSL or OpenVPN.
More information, from Sonicwall: https://support.software.dell.com/kb/sw3798 The SonicWALL does not honor or pass to the LAN MTU Path Discovery messages because there is no way to authenticate them and they can be used as a form of attack. For example, someone can initiate a denial of service attack against an unprotected server by simply sending a Path MTU Discovery packet to it that directs the server to limit packet size to 5 bytes instead of the normal 1500 bytes. This will slow the server down to a crawl because it has to process the same amount of data into many more packets, creating much overhead.