Known Issues and Limitations with Active and Passive FTP when using VMware SD-WAN

Products

• VMware SD-WAN by VeloCloud

Issue/Introduction

This article discusses the Known Issues and Limitations with using either Active or Passive FTP with the VMware SD-WAN service.

Environment

VMware SD-WAN by VeloCloud

Resolution

There are known limitations when an FTP application is used and these limitations depend on which type of FTP is being used (Active or Passive). This article covers both the limitations for each FTP type and the workarounds.

Active FTP

   Active FTP

The first point that should be made is that VMware SD-WAN does not support Active FTP via NAT. This is not a bug, but a conscious decision made from Day 1 due to the security implications of Active FTP. There is a workaround if the customer is willing to accept the security risks that we will describe below.

The issues with Active FTP arise from the fact that after the control session is opened by the client, the server needs to open a second data connection using a different source and destination port. The security risks and limitations associated with Active FTP are a result of allowing this second flow to be initiated from the server.

Active FTP scenarios in a standard customer network:

1. Active FTP works properly for VMware SD-WAN Edge-to-Edge traffic because both sides are allowed to freely create new flows to each other and there is no NAT in between.
    
2. If the FTP server is located on the LAN-side of the Edge, and the client is in the cloud, then the initial control plane flow will need to be explicitly permitted. This may be done with a 1:1 NAT rule translating the server's public IP to its private IP. Since the secondary flow will be initiated by the server on the LAN side, the flow would not have any restrictions.

Note: There is a limitation to this method. 1:1 NAT rules that configure the allowed ports as 20-21 will not work. The reason is that a port 20-21 filter rule affects inbound traffic, but not outbound traffic. As a result, incoming traffic will be allowed per the rule but FTP traffic would use a random port for returning. Since there is no outbound rule for ports 20-21, there is no return path for the FTP flow, and the connection fails. As a result, a user should never configure a 1:1 NAT rule with allowed ports 20-21.

1. If the FTP server is on the public internet (and the client is on the LAN behind the Edge) the secondary data session will not be permitted. This is by design and there are currently no plans to support Active FTP for this setup. However, there are two workarounds which both carry security risks:
   1. The typical method is to configure a 1:1 NAT rule which allows all inbound traffic from the FTP Server’s Public IP. This will allow the inbound data connections from the server unilaterally regardless of the random port chosen.
   2. Another option is to disable NAT on the Edge and use an external NAT device which supports Active FTP.

Active FTP may fail when the FTP server is on a public network and the client is on a private network.

1. Windows FTP Client (FTP not working)

The Windows FTP client does not have the capability to pass the public IP address in the FTP header when the client is behind a NAT device and will instead send the private IP address. The FTP server uses this private IP address and port number for initiating the data channel. As the IP address is a private IP address, the data connection from the server will fail.

2. FileZilla FTP client (FTP Working)

The FileZilla FTP client has special settings to use a public IP address when the FTP client is behind a NAT device like a VMware SD-WAN Edge.

Passive FTP

The main difference between Passive and Active FTP is that with Passive FTP both the control and data sessions are initiated by the client. Therefore, if the Passive FTP server is located in the public internet and the client is on the LAN behind an Edge, the session will work. 

However a configuration where the Passive FTP server is on the LAN-side of the Edge while the client is located in the public internet is not supported. To support this would require dynamically creating temporary 1:1 NAT rules for the ports chosen and then aging them out when the session ends. As a result we made the decision not to support this configuration.

This limitation is documented in all available Release Notes as the open issue: 08654, Passive FTP and TFTP will not work via 1:1 NAT. 

As with Active FTP, there's no problem with supporting Passive FTP between two different VMware SD-WAN sites as each would communicate via VCMP tunnels and thus no need for NAT.