2

I have a new server in a private subnet in an AWS VPC. I have a NAT instance in the public subnet of my VPC, and can connect out to remote servers fine. However, when I try to scp files, things seem to hang. 

ryan@sever-in-vpc:~ $ scp -vvvv myfile www1.domain.com:
...
debug2: exec request accepted on channel 0
Sending file modes: C0664 42625 myfile
debug2: channel 0: rcvd ext data 25
myfile                                                  100%   42KB  41.6KB/s   00:00
Sink: C0664 42625 myfile
debug2: channel 0: written 25 to efd 6
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1

The "..." includes host key checking, authentication succeeding, I can give more if necessary. On the remote side, I now have "myfile" in my home directory on the remote server with a size of 0 bytes. The "debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1" message repeats seemingly until I kill the scp command. (I've left it running as long as five minutes... "myfile" is only 42625 bytes.)

It seems to me like the sending side thinks it's sent all the bytes, but the receiving side hasn't written them to disk.

Looks similar to the problem this guy was having, but no solution for him either. Any thoughts for things I can look into?

Community
  • 1
Ryan Olson
  • 171
  • 2
  • 6
  • 1
    Looks suspiciously like an MTU issue. What is the nature of your internet connection? Have you tested this from another internet connection from a different provider? – EEAA Apr 06 '15 at 18:07
  • Both the source and destination servers are in AWS, the source in a private subnet in a VPC, the destination is in EC2 Classic. That's the combination where the transfer hangs, scp within the private subnet or from the private subnet to the public subnet works fine. I suspect our NAT instance, but am not sure how to further troubleshoot. – Ryan Olson Apr 06 '15 at 18:17
  • Perhaps a packet capture to see the last communication sent/received might be helpful. Ideally best if you can get the capture on both sides so that you can verify sent/received on both sides. – BeepBeep Apr 06 '15 at 20:31

1 Answers1

2

Turns out, this was related to the way I had VPC set up in AWS.

MTU auto-discovery should work, but depends on return ICMP traffic. It turns out that though we were allowing ICMP into our private subnet via AWS Security Groups, we were not allowing ICMP in our VPC network ACL. Opened that up and the MTU-based problem went away.

So be sure to check your VPC ACLs in addition to your Security Groups.

jpaugh
  • 231
  • 5
  • 15
Ryan Olson
  • 171
  • 2
  • 6