Forum

Results 1 to 6 of 6
  1. #1
    Join Date
    May 2007
    Location
    Eastern NC
    Posts
    1,794

    Server on lan is messing up file transfers with computers outside lan

    When remote users use TS3 client on computer at a remote site to connect to my TS3 server behind a router and transfer a file from a channel they are getting error: Transfer "random test file.txt" reports: (could not open file transfer connection). I tested and confirmed this problem using a remote computer I can access. Looking at the network traffic log on the server the request is never getting to the server so I re-validated that the port forwarding is set as needed to allow the request to get to the correct computer. More review of the client log I see it is using the wrong IP, it is attempting to connect to the server's LAN IP instead of the WAN IP.
    Code:
    3/28/2014 2:49 PM	FileTransfer	Error	Failed to open filetransfer tcp connection to 192.168.5.5:30033
    192.168.5.5 should be some WAN IP like 98.24.234.185 (not my IP, just a hypothetical).

    The remote site should have no knowledge of the server's LAN IP and this must have been passed to the client from the server when the client requested transfer. But with remote site attempting to use LAN IP it is no surprise that the connection is failing.

    I use to host this server on VPS running CentOS and don't recall this problem then, server is now running on Windows. When I right click on the server icon in the tasktray the WAN IP there is the correct WAN IP. There are TS3 clients connected from the LAN and from off site. Just seems like TS3 is not looking at remote clients IP correctly to determine if the LAN or WAN IP should be used to request the files. All of the onsite TS3 clients can transfers files just fine, as expected since the server is providing the LAN IP.

    For now I've instructed those users to make sure they have their VPN client connected to the network before attempting to download the file from the TS3 server.

    Server is Windows 64 Version 3.0.10.3 (01.01.2014 11:28:39) (AAL)
    Client is Windows 64 Version 3.0.14 (3/12/2014 07:49)

    IPs and filenames in this post have been changed to protect the identities of those involved.

  2. #2
    Join Date
    April 2011
    Location
    Germany
    Posts
    1,266
    My first guess you use a ini file and have specified 192.168.5.5 to be the filetransfer ip... if that is true try filetransfer ip 0.0.0.0

  3. #3
    Join Date
    May 2007
    Location
    Eastern NC
    Posts
    1,794
    Quote Originally Posted by Barungar View Post
    My first guess you use a ini file and have specified 192.168.5.5 to be the filetransfer ip... if that is true try filetransfer ip 0.0.0.0
    That maybe right, with the Linux VPS there was only 1 network adapter, on this server there are 2 and I did have to set which adapter to listen on because I was connecting on one IP but the server was replying to the clients from another and that was causing warning messages in the client logs. It still seems odd that the server would return a LAN IP to a client not using a LAN IP, even when the server is correctly reporting the WAN IP.

  4. #4
    Join Date
    April 2011
    Location
    Germany
    Posts
    1,266
    I think the issue might be that setting a filetransfer ip via ini file is that powerful that all detection algorithms are neglected. If your server would have two public IPs the situation wouldn't occur. Because you'd set one of those in the ini and the server would anounce that to the client requesting a file transfer... but in your situation the server also anounces the set IP but it will not work because it is a private IP.

  5. #5
    Join Date
    May 2007
    Location
    Eastern NC
    Posts
    1,794
    Yeah, I think if the IP bound by the server is a private IP it and the IP of the client is not a private IP the WAN IP should be provided by the server. Or the client should be smart enough that if it receives a private IP and the IP it resolved was not a private IP to use the IP voice is connected one.

    But setting the filetransfer back to 0.0.0.0 works for now. I have not rechecked the traffic logs to see which IP the server is actually sending the file on though and I don't have the warnings in the client logs on the lan connected computers like I saw with 0.0.0.0 in the voice before when the server replied on the other network than the request came in on.

  6. #6
    Join Date
    April 2011
    Location
    Germany
    Posts
    1,266
    Quote Originally Posted by Screech View Post
    But setting the filetransfer back to 0.0.0.0 works for now. I have not rechecked the traffic logs to see which IP the server is actually sending the file on though and I don't have the warnings in the client logs on the lan connected computers like I saw with 0.0.0.0 in the voice before when the server replied on the other network than the request came in on.
    Voice is a whole different thing... here setting a definite IP is very recommended on a host with multiple IPs because the UDP traffic handling is quite strange if more then one IP is available. That is because UDP isn't connetction based. As for server query and filetransfer which are both connection-based (TCP) there shouldn't be any issue if they are bound to all interfaces.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. FIle Transfers and Avatars on Linux Server.
    By Digital420 in forum Linux / FreeBSD
    Replies: 0
    Last Post: August 3rd, 2013, 08:46 PM
  2. File Transfers....
    By mech1999 in forum Windows
    Replies: 2
    Last Post: May 14th, 2011, 04:55 AM
  3. Using a webhost for file transfers
    By shoeib in forum Windows
    Replies: 10
    Last Post: October 27th, 2010, 05:26 PM
  4. file transfers
    By DUMBAZZ in forum General Questions
    Replies: 2
    Last Post: December 25th, 2009, 05:32 PM
  5. File Transfers
    By Xing101 in forum Permission System
    Replies: 9
    Last Post: December 21st, 2009, 04:45 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •