Where VPN Protection Ends on the Way to an FTP Server

A VPN protects a path, and a path has an end. When the tunnel terminates at a company gateway, the file transfer continues from there under whatever protection its own protocol provides. That distinction decides whether a transfer is protected end to end or only as far as the gateway. The Connected indicator says nothing about either.

Two Placements, Two Remaining Paths

Take a laptop that joins a company VPN and then opens an FTP session to a separate internal server. The tunnel stops at the gateway, and the segment from the gateway to that server sits outside it.

Plain FTP does not acquire encryption because its packets arrived through a tunnel. On that remaining segment the commands, the credentials and the file contents travel exactly as the protocol defines them, which is in the clear. Whether that matters depends on the topology and on what else guards the segment, and calling the address private does not answer the question. The same reasoning applies in reverse when the server lives in a cloud network the gateway reaches over another hop.

Put the VPN endpoint and the FTP service on one machine and there is no onward segment to worry about. That is a different placement rather than proof that the host's processes, files and credentials are safe.

Plain FTP, FTPS and SFTP Are Three Decisions

Plain FTP encrypts nothing, including the password. FTPS adds TLS to FTP, so the control channel and, when negotiated, the data channel are protected. SFTP is a different protocol carried inside SSH, and it is not another spelling of FTPS.

The server has to support the choice, because a client cannot conjure a listener that is not there. Selecting SFTP does not convert an FTP-only service into an SSH endpoint, and renaming a bookmark or changing a port proves nothing about what was negotiated. Confirm the protocol from the server's side as well as the client's. A padlock in a file manager is a claim about the session, not about the listener behind it.

Read the last column when the transfer matters, because that is where an unexpected identity change shows up.

The Data Connection Is a Second Connection

FTP opens a control connection and then separate data connections for listings and transfers. A protected login says nothing about those later connections unless the deployment requires protection for them too.

With FTPS, the client asks for a protected data channel through a specific command, and a server policy can refuse the clear alternative. Verify that the policy requires it rather than assuming the client default is enough. Passive mode adds a second wrinkle, because the server advertises an address and port for the data connection. A firewall or NAT device that rewrites or blocks that advertisement produces a session which authenticates and then hangs on the first listing.

curl -vk ftps://files.corp.example/ --user alice --ftp-ssl-control
openssl s_client -connect files.corp.example:21 -starttls ftp
ss -tnp | grep -E ':21|:990'

The second command shows what the server presents on the control channel before any file is touched. The third shows whether a data connection was ever established, which is the difference between an authentication failure and a passive-mode failure.

Identity Checks Survive the Tunnel

An FTPS client validates a TLS server identity, and an SFTP client validates an SSH host key. Both checks belong to the file-transfer protocol, and neither is performed by the VPN.

That separation matters when something in the middle wants to inspect the session. Disabling TLS so a network appliance can read the commands changes the protection model rather than completing it, and the same is true of accepting an unexplained host key because the tunnel came up. Keep the intended trust configuration and obtain the correct material from the operator. A tunnel that authenticates says nothing about the server at the far end of it.

Private-key and certificate material for these protocols is a third secret again, separate from the VPN credential.

Record What You Actually Verified

Pick a harmless file you are authorised to move, and note four facts about the attempt: which protocol ran, which peer identity was checked, which path was intended, and whether the transfer finished.

lftp -u alice -e "set ftp:ssl-protect-data true; ls; bye" ftps://files.corp.example
sftp -v [email protected]

A directory listing, a tunnel login and a finished transfer are three separate observations, and only the last one says the path works for files. If the design relies on the VPN alone for confidentiality on the remaining hop, write that down as the decision it is. An acceptance note naming the hop and its trust assumption is worth more than a screenshot of a connected client.