We have a SFTP server which was working fine until we added another ISP. The connection to the SFTP server is not going through the new ISP, I confirmed it with tracert. No change was made on the server either. But since then, some users' SFTP or SSH connections time out/hang if the executed command has a larger return. Here's the scenario:

  1. I can continue to ping and the ping will always return even when SSH/SFTP times out
  2. I can connect to the server, it asks for authentication and lets me log in.
  3. If the ls command for my root directory is returning a small number of files or folders, then it shows the listing of files and folders
  4. If the ls command for my root directory is larger than let's say 5 or 6 files or folders, then it hangs/times out.
  5. While trying this, I tried running a ping to the server, and it's returning all the time.
  6. This doesn't happen to everyone, but it seems to happen to users who are in another city..

  7. I tried different SFTP clients (FileZilla and WinSCP). Both have the same issue.

I ran WireShark on my PC (which is outside of our network and outside of the city), when SFTP/SSH times out, I see retransmission and part of segment not captured errors coming up, which leads me to believe there might be some packet loss somewhere between the hops.

Expert Info (Note/Sequence): Retransmission (suspected)
Previous segment not captured (common at capture start)

Is SFTP/SSH that sensitive to packet loss? Wouldn't SSH/SFTP retransmit/reacknowledge to avoid these packet loss errors? Is there something on the server settings I can tweak in order to make this work?

  • 2
    Sounds like path MTU issues. Are you dropping all ICMP or something? – Michael Hampton Aug 10 '13 at 1:54

I believe the commenter hit the nail on the head, this is a classic example of an MTU issue (and path MTU not properly detecting the smaller MTU necessary for that particular path that is failing). You should check that the intermediary devices in the path that is failing are properly allowing MTU path discovery packets through, and that there aren't any intermediary routers with unnecessarily small MTUs. You can probably narrow it down by sending large icmp packets up to the size of MTU to each hop along the way to discover where it is failing (although this doesn't always work).

| improve this answer | |
  • 1
    Thanks Michael and Jed. Just found out that some of the IP ranges are routing through the new ISP (from our company), even though the request is coming through our old ISP. For those IPs routed through the new ISP, I couldn't send a ping (from the external IP) with the size of 1500 (default MTU) to the server. Forcing the route to go through out old ISP seems to be fixing the issue. – user2480011 Aug 12 '13 at 16:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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