This article provides information if the vTM can be configured to return the public source IP of the end user instead of the vTM internal TIP.
Problem or Goal
When the Traffic Manager is behind the NAT device, the PASV response contains its own local IP, which the NAT device can't read within this packet for the information, because it's in application layer. The client gets the private IP of the TM, but does not know the route to that and the TM never receives that connection.
While TrafficScript could be used to overwrite the public IP, the Traffic Manager rewrites the packet with the local IP. Even changing the VS from FTP to use generic streaming/server protocol which will do what's in the TrafficScript will not solve the issue as it will not listen on the new ports and will reset the connection if the client tries.
The problem here can be seen by following example of the process:
Client establishes a connection on control port (21) to Traffic Manager.
TM establishes a new connection to the back-end over control port.
Client sends PASV command to TM
TM relays the PASV command to the back-end node.
Back-end node responds with its IP and new random port (data port i.e. last two numbers in response to PASV command: 23,12 = 23*256+12 = NEW PORT = 5900 )
TM (if protocol is FTP) sends its own IP and a new random port to the client (TM starts listening on this new data port)
The client establishes another connection on the new port to the TM - and the data is transferred on the new connection.
Cause
Solution
Currently, it's not possible to use passive FTP when the virtual Traffic Manager is behind a NAT Firewall device. This is not a problem for the Traffic Manager, but other devices as well. Pulse Secure recommends using SFTP as an alternative.
Another possible way to work around this is to use a firewall/NAT device that understands FTP protocol.
Please take a look at the following link for a more detailed explanation of the issues and possible workarounds:
