visibleworld
asked on
FTP connection times out during file transfer over VPN tunnel.
We have a site-to-site VPN tunnel setup with a client, and we are experiencing a very unusual problem with FTP. I do not know what type of firewall is on the client's side, however we have a SonicWall PRO 4100.
VPN Config:
Phase I: Group5/AES-256/SHA1/
Phase II: ESP/AES-256/SHA1
It's worth noting that through that tunnel, we are being routed to 21 subnets across this client's network.
Problem Description:
We are allowed to FTP to all 21 subnets, and that works just fine. However, we have a problem with one particular machine. We can FTP to that machine from virtually anywhere on our internal network, but some machines fail to transfer files larger than few MBs. In addition, I can perfectly fine ftp to the remote server from a machine on (LET'S SAY) vlan200, and at the same time another machine on the same vlan will time out during the data transfer. We were able to eliminate few possibilities:
- It's not hardware/vendor specific (Dell/Lenovo)
- Not subnet specific
- We are not able to get the machines that time out to work
- We are not able to get the machines that DO WORK to reproduce the problem
FTP Server is:
IIS based - (Timeout is set to 120 seconds (tested with 900 seconds without luck), unlimited connections allowed)
FTP Clients tested:
Command Prompt Error:
C:\>ftp X.X.X.X
Connected to X.X.X.X
220 Microsoft FTP Service
User (X.X.X.X:(none)): username
331 Password required for username.
Password:
230 User username logged in.
ftp> bin
200 Type set to I.
ftp> mput filename
mput of62.exe? y
200 PORT command successful.
150 Opening BINARY mode data connection for of62.exe.
> Netout :Software caused connection abort
426 Connection closed; transfer aborted.
ftp: 65535 bytes sent in 206.66Seconds 0.32Kbytes/sec.
Filezilla Error:
We tried both passive and active modes and both fail during the file transfer with the same error:
Error: Connection timed out
Error: File transfer failed after transferring 262,144 bytes in 21 seconds
Note: Nodes that time out during file transfer over VPN tunnel, transfer files internally through FTP without any problems.
Any help appreciated.
VPN Config:
Phase I: Group5/AES-256/SHA1/
Phase II: ESP/AES-256/SHA1
It's worth noting that through that tunnel, we are being routed to 21 subnets across this client's network.
Problem Description:
We are allowed to FTP to all 21 subnets, and that works just fine. However, we have a problem with one particular machine. We can FTP to that machine from virtually anywhere on our internal network, but some machines fail to transfer files larger than few MBs. In addition, I can perfectly fine ftp to the remote server from a machine on (LET'S SAY) vlan200, and at the same time another machine on the same vlan will time out during the data transfer. We were able to eliminate few possibilities:
- It's not hardware/vendor specific (Dell/Lenovo)
- Not subnet specific
- We are not able to get the machines that time out to work
- We are not able to get the machines that DO WORK to reproduce the problem
FTP Server is:
IIS based - (Timeout is set to 120 seconds (tested with 900 seconds without luck), unlimited connections allowed)
FTP Clients tested:
Command Prompt Error:
C:\>ftp X.X.X.X
Connected to X.X.X.X
220 Microsoft FTP Service
User (X.X.X.X:(none)): username
331 Password required for username.
Password:
230 User username logged in.
ftp> bin
200 Type set to I.
ftp> mput filename
mput of62.exe? y
200 PORT command successful.
150 Opening BINARY mode data connection for of62.exe.
> Netout :Software caused connection abort
426 Connection closed; transfer aborted.
ftp: 65535 bytes sent in 206.66Seconds 0.32Kbytes/sec.
Filezilla Error:
We tried both passive and active modes and both fail during the file transfer with the same error:
Error: Connection timed out
Error: File transfer failed after transferring 262,144 bytes in 21 seconds
Note: Nodes that time out during file transfer over VPN tunnel, transfer files internally through FTP without any problems.
Any help appreciated.
beester
Is it the exact amount of seconds before it times out every time, or does it vary?
I think you have resloved one problem by setting the timeout to 900 seconds, the one sample transfer failed after 200 seconds so you defintitly are going to have file that take longer than 120 seconds.
What errors are there in the ftp servers log?
What errors are there in the ftp servers log?
ASKER
Beester,
Timeouts are close but not the same:
206.69 seconds, 206.66 seconds, 229.15 seconds - the last three transfers I've done.
giltjr:
System Log:
Event ID: 10
User username at host X.X.X.X has timed-out after 120 seconds of inactivity.
FTP LOG:
2010-03-29 13:03:15 X.X.X.X username MSFTPSVC1 TNNASAR1 X.X.X.X 21 [710]USER username - 331 0 0 0 0 FTP - - - -
2010-03-29 13:03:19 X.X.X.X username MSFTPSVC1 TNNASAR1 X.X.X.X 21 [710]PASS - - 230 0 0 0 0 FTP - - - -
2010-03-29 13:05:50 X.X.X.X username MSFTPSVC1 TNNASAR1 X.X.X.X 21 [710]created /of10.exe - 426 121 0 0 121328 FTP - - - -
2010-03-29 13:06:20 X.X.X.X username MSFTPSVC1 TNNASAR1 X.X.X.X 21 [710]closed - - 421 121 0 0 151328 FTP - - - -
Thank you.
Timeouts are close but not the same:
206.69 seconds, 206.66 seconds, 229.15 seconds - the last three transfers I've done.
giltjr:
System Log:
Event ID: 10
User username at host X.X.X.X has timed-out after 120 seconds of inactivity.
FTP LOG:
2010-03-29 13:03:15 X.X.X.X username MSFTPSVC1 TNNASAR1 X.X.X.X 21 [710]USER username - 331 0 0 0 0 FTP - - - -
2010-03-29 13:03:19 X.X.X.X username MSFTPSVC1 TNNASAR1 X.X.X.X 21 [710]PASS - - 230 0 0 0 0 FTP - - - -
2010-03-29 13:05:50 X.X.X.X username MSFTPSVC1 TNNASAR1 X.X.X.X 21 [710]created /of10.exe - 426 121 0 0 121328 FTP - - - -
2010-03-29 13:06:20 X.X.X.X username MSFTPSVC1 TNNASAR1 X.X.X.X 21 [710]closed - - 421 121 0 0 151328 FTP - - - -
Thank you.
O.K., something is closing the command/control connection (port 21) and it looks like after about 200 seconds. If you ftp servers timeout is 900 seconds then there could be a firewall someplace that is doing this.
ASKER
giltjr:
Why would it do it only for some machines and not for others?
Why would it do it only for some machines and not for others?
Um, good question. Does that computer have its own personal firewall that is different from others? You may want to chech and see under what conditions you ftp server will terminate a connection with a 421. That is the code your server issued inthe log above. Thia code can be for various reasons.
What's your phase 2 SA life set to?
ASKER
beester:
Phase II - Life Time is 3600 (seconds)
Phase II - Life Time is 3600 (seconds)
Can you try pinging the ftp server at the same time as you ftp to it, to see if you lose connection totally, or if it's just ftp?
ASKER
Ping is disallowed. Only (SNMP, FTP and RDP are allowed).
In addition:
I put TCPView on both Client and Server.
Client's state is Established->Close_Wait), Server Established-> Fin_wait1-> fin_wait2.
As soon as Fin_wait1 changes to Fin_Wait2 on the server, Client's state changes from Established to Close_wait.
Don't know if this proves anything other than the connections is establised between the client and the server.
In addition:
I put TCPView on both Client and Server.
Client's state is Established->Close_Wait), Server Established-> Fin_wait1-> fin_wait2.
As soon as Fin_wait1 changes to Fin_Wait2 on the server, Client's state changes from Established to Close_wait.
Don't know if this proves anything other than the connections is establised between the client and the server.
Um, interesting. fin_wait1 status is the status that client side is in when it (the client) issues close to the server. This indicates that client is sending close to the server.
Is this the command/control connection or the data transfer connection? If data transfer connection are you using active or passive?
Is this the command/control connection or the data transfer connection? If data transfer connection are you using active or passive?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.