This topic provides configuration guidelines for sites that deploy a Web Application Firewall (WAF) in front of MOVEit Transfer. The main purpose of a WAF is to block malformed HTTP requests before they ever require handling by MOVEit Transfer.

WAFs provide another layer of assurance that web traffic such as REST API and WebUI requests arrive as expected. HTTP requests that are well-formed and align with the current WAF configuration policies are let through and malformed or unexpected traffic is blocked.

Tip: If you are using MOVEit Transfer for the first time or you are unsure which ports MOVEit Transfer currently uses or expects traffic on, you can check the MOVEit Transfer Config Utility. You can also validate these settings using port scanner tools like nmap.

Configuring a WAF to work with MOVEit Transfer

MOVEit Transfer administrators should work with their networking team and WAF vendor representatives to properly adjust WAF settings for their particular traffic patterns and protocols. WAFs from different vendors will require different settings for MOVEit Transfer. Below are items that commonly need to be addressed on a per-protocol basis.

HTTPS

When configuring your third-party WAF for HTTPS, consider the following:

  • The WAF Needs the full MOVEit Transfer certificate

    The full (public and private) MOVEit Transfer server certificate will need to be provided to the WAF to allow for decryption of the HTTPS/TLS request data.

  • HTTP Methods the WAF Must Include.

    GET, POST, HEAD, OPTIONS, PUT, PATCH, and DELETE HTTP methods must all be allowed for MOVEit Transfer.

  • HTTP POST Method Settings.

    Some WAFs have limitations on the total size of a POST message or built-in timeouts that can affect large file uploads. These settings most commonly affect file uploads that use the MOVEitISAPI endpoint in MOVEit. (For example, MOVEit Automation, MOVEit EZ or custom applications written with the MOVEit Transfer .NET API or Java API modules.)
    • POST settings need to be configured to accommodate the largest file size that might be uploaded over HTTPS.
    • Large file uploads through the UI that use the MOVEit RESTful APIs should also be tested.

SFTP

WAFs do not inspect SSH traffic on the SFTP protocol. Some recommended options for SFTP traffic are:

  • Option 1: Configure traffic on port 22 to pass through the WAF without inspection.

  • Option 2: If pass-through is not allowed by the WAF vendor then an additional URL will need to be provided specifically for SFTP traffic.

    • For example, If your company’s MOVEit Transfer URL is files.example.com then you might choose sftp.example.com as a URL dedicated to SFTP access.

  • Option 3: Use a load balancer before the WAF to send SFTP traffic to the MOVEit Transfer nodes and send only HTTPS traffic to the WAF.

  • Option 4: Disable SFTP if it is not used by your organization and disable port 22.

FTPS

WAFs do not inspect traffic on ports 21 or 990 for the FTPS protocol. Some recommended options for FTPS traffic are:

  • Option 1: Configure traffic on port 21 or 990 to pass through the WAF.

    • If using FTPs passive mode the high-range ports defined in the MOVEit Transfer Config utility will also need to be allowed to pass through the WAF. The default high range ports for MOVEit Transfer are 3000 to 3100. This setting must be verified by checking the FTP Passive Range ports in the MOVEit Transfer Config Utility.

  • Option 2: If pass-through is not allowed by the WAF vendor, then an additional URL will need to be provided specifically for FTPS traffic.

    • For example, if your company’s MOVEit Transfer URL is files.example.com, then you might choose ftp.example.com as a URL dedicated to SFTP access.

  • Option 3: Use a load balancer before the WAF to send FTPS traffic to the MOVEit Transfer nodes and send only HTTPS traffic to the WAF.

  • Option 4: Disable FTPS if it is not used by your organization and disable ports 21 and 990

Common Issues with WAF Implementation

  • Large file upload failures with MOVEit Automation, MOVEit EZ, or custom applications using MOVEit Transfer API or Java API

    • This issue tends to be vendor-dependent. Some vendors have POST size limits or timeouts that need to be reconfigured and other vendors modify the MOVEit POST request headers in a way that MOVEit Transfer does not support.

    • This issue will most likely affect file uploads that use the MOVEitISAPI for file upload. It should be possible to see if the upload is using MOVEitISAPI by viewing either the WAF logs or the IIS logs for the request that is failing.

    • Potential Resolutions:

      • Modify POST size maximums and timeouts based on largest file size and longest upload time expected.

      • Some WAF implementations modify the HTTP header transfer-encoding: chunked which is required by MOVEit Transfer MOVEitISAPI interface. Generally this needs to be verified with the WAF vendor and may require the WAF vendor to provide a workaround or alternative configuration of the WAF.

  • Performance

    • Introducing a WAF into the path of traffic will always add some degree of latency and has the potential to have a measurable effect on the overall performance of MOVEit Transfer. This is because the WAF must decrypt, inspect, re-encrypt, and forward the data passing through it. If performance is negatively affected, work with you WAF vendor to tune the behavior of the WAF.