In this article:
- Twingate Component: Resource (connection via Client)
- Platform: Any
- FTP Protocol
Overview
When attempting to access a FTP resource via PASV mode, the connection times out or fails.
Symptoms
- FTP Server set as a Twingate resource with FQDN only (no IP)
- When connecting, initial authentication can be completed, but any further transfer times out.
- Error messages such as the below are seen:
TLS/SSL connection refused, turning off session resuming and retrying.
425: Failed to establish connection.
Resolution
Due to the way FTP passive mode works - you must add the IP of the FTP resource to your Twingate network, or disable passive mode.
Further Explanation:
On the Twingate side, when you have ftp.hostname.com defined as a resource, when the system goes to look that up, Twingate gets involved, and we "hijack" the answer to the request and return one of our CGNAT IPs that relays the traffic to the actual host, instead of returning the actual IP of the resource, which is 1.2.3.4.
When you connect to the FTP, you're using the ftp.hostname.com hostname, so Twingate is involved in the process as above.
When your enter PASV mode, the FTP Server says "OK, we'll go passive. I'm going to expect you to tell me what to do on the following IP/ports" with a message like this:227: Entering Passive Mode (1,2,3,4,24,123)
(Despite the commas, this does correlate to 1.2.3.4 as an IP address).
Then the FTP client goes "OK, I'm going to send you a command on that IP!" and now, because Twingate isn't "paying attention" to that IP itself, rather just the hostname it resolves from, it ignores the traffic and the request goes out directly to 1.2.3.4, which is likely unreachable from the client device, which is why Twingate is involved in the first place.
Naturally, this will fail, and lead to the situation noted above.
Adding the IP as a Twingate resource means that when the PASV connection is attempted, Twingate still gets involved and we ensure the traffic is routed through the connector as we expect.