Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

My firewall (Sonicwall NSA 2400) has begun dropping the SSH response from my remote linux server. When I initiate an SSH session from my internal IP it times out, and when I look at the firewall log, I see the following:

TCP connection dropped
source (remote Linux server IP), port 1200, interface X1
destination: (my internal IP), port 65050, interface X0
notes: TCP Port: 65050

Subsequent attempts fail, always with a different internal destination port. What am I missing here? I haven't added any rules to the Sonicwall's firewall, but the Linux server's SSHD (Ubuntu 10.10) has recently been updated.


A packet dump reveals that the packet's being dropped due to an invalid TCP flag.

IP Type: TCP(0x6), Src=[source ip], Dst=[]
TCP Packet Header
TCP Flags = [RST,], Src=[1200], Dst=[51150], Checksum=0x76d7
Application Header
Not Known
DROPPED, Drop Code: 22, Module Id: 26, (Ref.Id: _3694_uyHtJcpfngKrRmv) 1:1)


0017c519 be3d0090 1a422c89 08004500 002c0000 00001606 *.....=...B,...E..,......*
82a34e10 18c10a0a 0a0b04b0 c7ce6c45 9d910000 00005004 *..N...........lE......P.*
000076d7 00007366 7463                                *..v...sftc              *

Does this mean that the Sonicwall's just being unusually fussy, or that something's misconfigured on the remote server? I can connect to it from a different remote LAN without any problem.

share|improve this question
1200 is not SSH's port. If you changed, I really recommend you to move it back to its default, and avoid changing it without understanding the consequences. Also, 65050 is one of the last ephemeral ports available, it is very uncommon to see it in examples. –  Juliano Mar 9 '11 at 13:54
1200 (in this case) has been an alternate SSH port on this Linux server for years. What I'm wondering is why the response is being directed to a random port (in this case, 65050, but it varies each time, as I said) and being dropped. –  urschrei Mar 9 '11 at 14:01

1 Answer 1

up vote 1 down vote accepted

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

share|improve this answer
Thanks! Have updated my answer with additional information. –  urschrei Mar 9 '11 at 14:58
Hmm...odd. Looks like the dropped packet has the RST flag set. That's an attempt by your server to kill the connection. That's probably the flag the Sonicwall is griping about. Is it possible the authentication has broken, or something else has gone awry due to the SSH upgrade? Maybe try some more troubleshooting to narrow the problem. Does it happen with certificates or passwords? Different client machines? Same machine, but connected to a different network? –  Christopher Karel Mar 9 '11 at 15:32
It's key-only authentication, and it works fine for the same user on a different machine on a different remote network, and it's fine for this machine when it's on the same LAN as the server. –  urschrei Mar 9 '11 at 15:37
Hmm...then it does look like this is largely due to the firewall. Assuming you don't have a iptables, or some other firewall, on the target, that might be blocking attempts from just that network? That would certainly explain the RST, and might have been caused by a package update/install at the same time that you touched SSH. –  Christopher Karel Mar 9 '11 at 19:37
I'll have a look around on the Ubuntu box, but I'm 99% sure that it's nothing there. I suppose I could run a packet dump on it while attempting to connect from the offending remote network, which will at least definitely isolate the problem to either the Sonicwall or the Ubuntu server. –  urschrei Mar 9 '11 at 19:47

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.