SCP stalling
-
I have an issue where SCP is stalling while trying to transfer any size file. SSH works perfectly between the two servers. One server (A) is behind a pfsense firewall 2.2-RELEASE(amd64) and the other server (B) is directly connected to the internet. I am trying to scp from A to B.
I am able to scp files onto both servers without issue as long as scp does not go through pfsense i.e. I can scp between servers on the local side of the firewall and I can scp between servers which are directly connected to the internet. I am unable to scp from servers on the local LAN to servers directly connected to the internet.
I am sure its a simple setting somewhere on pfsense I need to change I just cannot seem to be able to find it.
EDIT: Adding some more information that may help.
It seems that NAT is also not working on this pfsense install. I can see the traffic come through pfsense, hit the server, the server responds but the traffic does not arrive at the originating machine.
-
Well NAT must be working to some extent if SSH is working and SCP works initially.
Are you running Snort or Securicata? Check the logs.Check the system logs at that time. Check the firewall logs.
What size files are we talking about here? How long does it take to download them?
Steve
-
I have done some further testing:
rsync over ssh fails faster than scp.
Well NAT must be working to some extent if SSH is working and SCP works initially.
I am not using NAT for scp or rsync, its just another thing wrong with this firewall, so I thought I would add that information if it would help.
To reiterate my issue:
Server A: IP 192.168.10.24 (private) –> pfsense --> Server B: IP Public.
scp and rsync fail to transfer any file. Smallest I have tested is 20kb.
-
I am not using NAT for scp or rsync
To reiterate my issue:
Server A: IP 192.168.10.24 (private) –> pfsense --> Server B: IP Public.You sure like hell are using NAT on the client side.
-
You sure like hell are using NAT on the client side.
Yes I am wrong on that one.
I am still having issues with this, any further ideas?
-
Are you running Snort or Securicata? That's my first suspect in 'traffic just stopped' cases like this.
So your comment on NATd traffic not being passed was not specific to SSH then?
Try capturing that and see what changes when it stops.Steve
-
NAT can cause problems or the ISP its self may be unreliable.
Or some "security" package.
-
Are you running Snort or Securicata? That's my first suspect in 'traffic just stopped' cases like this.
So your comment on NATd traffic not being passed was not specific to SSH then?
Try capturing that and see what changes when it stops.Steve
I was very tired when I posted my question initially. It wasn't NAT that was having issues, it was port forwarding - Sorry!
The only packages I am running on this firewall are open-vm-tools and open-vpn-client-export.
-
NAT can cause problems or the ISP its self may be unreliable.
Or some "security" package.
This firewall is directly connected to our WAN link in a datacenter, so I don't think it would be their gear, though it could be. In saying this, I am able to SCP between servers directly connected to our WAN link at the same datacenter without issue.
-
It seems this issue is solved - I will confirm through testing today and come back and confirm its solved/notsolved. Our WAN link requires an MTU of 1422 and the centos6 box had an MTU setting on its interface of 1500. The MTU of 1422 was already set on the WAN link but I was unaware this change had already been made.
I tested the largest MTU the WAN link supported without fragmentation using this guide:
http://gregalbrecht.com/2008/06/10/detecting-mtu/I changed the MTU on the centos6 box using this guide:
http://www.cyberciti.biz/faq/centos-rhel-redhat-fedora-debian-linux-mtu-size/ -
Ah, well spotted. Unusually narrow WAN pipe.
Steve
