This page documents possible problems with the interaction of SafeTP and firewalls, and known workarounds.
A firewall is a machine sitting between the Internet and a network of local machines. A firewall's duty is to filter traffic. Typically, a firewall is configured to either permit or block incoming TCP connections, when they are initially established, based on the IP address of the originating machine and the port to which it is trying to connect. Outgoing connections are typically unrestricted.
Some firewalls attempt to understand the content of the data on the connections it allows. By doing so, the firewall may discover that it should allow connections it otherwise would not, or may try to disallow protocol converstations it doesn't understand.
Further, many firewalls also do Network Address Translation (NAT). This proves to be the stickiest issue in making SafeTP work with firewalls.
Ordinary FTP has a potential problem with firewalls. An FTP data transfer can be either "active" or "passive". Active transfers are initiated by the server; passive transfers are initiated by the client. If we assume the client is behind a firewall, but the server is not, then an active transfer is likely to fail (because the firewall will deny the server's incoming connection) whereas a passive transfer is likely to succeed (because outgoing connections are unrestricted). For this reason, web browsers always use passive transfers. However, dedicated FTP clients usually default to active transfers. Therefore, it is often necessary to configure dedicated FTP clients to use passive transfers when behind a firewall.
An important exception to the above is when the firewall is parsing the FTP control channel. If it is, it will see enough information to allow the server's incoming data connection during an active transfer, eliminating the need to use passive transfers.
SafeTP changes things in only one way (from the perspective of the firewall): the control channel is now encrypted. However, this has a number of repercussions.
If the SafeTP client is behind a firewall, the simplest solution is to use passive mode transfers, and the firewall must be configured to permit arbitrary outgoing connections with data it doesn't understand (usually not a problem).
If active transfers work using ordinary FTP because the firewall is parsing the control channel, they will probably stop working when SafeTP is used, because SafeTP renders the control channel unintelligible to all but the client and server (after all, that's the point of SafeTP). Starting in version 1.9, the SafeTP windows client includes a "client-side firewall friendliness" feature that makes it far more likely that active transfers will operate correctly in the presence of client-side firewalls. This feature can be enabled in the advanced settings dialog in the SafeTP Manager - note that it is most likely to help if the server is sftpd version 1.46 or newer.
If the firewall is parsing the control channel and refuses to allow conversations it does not understand, then SafeTP will not work at all. In this case, the firewall will need to be reconfigured to not parse the control channel.
The firewall must know how to deal with incoming data connections. One technique is to reserve a range of ports, say 40000-40999, as SafeTP data ports:
Note that, since sftpd usually runs as a non-root user, the range of ports can't include any less than 1024, since these are reserved for root processes to bind.
Note to users of Checkpoint firewall: Note it is a "feature" with Checkpoint Firewall's that if you define TCP ports in large groups that the connection will be denied. The solution is to define your TCP data connection ports (ie 40000-40999) as a service of type "other" - with specific information in the Match field (tcp, dport >=40000, dport y<=40999).
There are two places the server's IP shows up in the SafeTP protocol stream. The first is during negotiation, as a countermeasure against a particular (though rather obscure) redirection attack. The second is in the reply to the PASV command, used by clients for passive-mode transfers (the common case, these days).
Since the client expects both IPs to be the external address of the firewall, sftpd must be told to supply this address to the client: this is done with the -i flag. E.g., if the firewall's external IP address is 10.9.8.7, say -i10.9.8.7.