[Previous: Performance] [Contents] [Next: Authpf: User Shell for Authenticating Gateways]
You can use FTP in one of two ways: passive or active. Generally, the choice of active or passive is made to determine who has the problem with firewalling. Realistically, you will have to support both to have happy users.
With active FTP, when a user connects to a remote FTP server and requests information or a file, the FTP server makes a new connection back to the client to transfer the requested data. This is called the data connection. To start, the FTP client chooses a random port to receive the data connection on. The client sends the port number it chose to the FTP server and then listens for an incoming connection on that port. The FTP server then initiates a connection to the client's address at the chosen port and transfers the data. This is a problem for users attempting to gain access to FTP servers from behind a NAT gateway. Because of how NAT works, the FTP server initiates the data connection by connecting to the external address of the NAT gateway on the chosen port. The NAT machine will receive this, but because it has no mapping for the packet in its state table, it will drop the packet and won't deliver it to the client.
With passive mode FTP (the default mode with OpenBSD's ftp(1) client), the client requests that the server pick a random port to listen on for the data connection. The server informs the client of the port it has chosen, and the client connects to this port to transfer the data. Unfortunately, this is not always possible or desirable because of the possibility of a firewall in front of the FTP server blocking the incoming data connection. OpenBSD's ftp(1) uses passive mode by default; to force active mode FTP, use the -A flag to ftp, or set passive mode to "off" by issuing the command "passive off" at the "ftp>" prompt.
Packet Filter provides a solution for this situation by redirecting FTP traffic through an FTP proxy server. This process acts to "guide" your FTP traffic through the NAT gateway/firewall, by actively adding needed rules to PF system and removing them when done, by means of the PF anchors system. The FTP proxy used by PF in OpenBSD 3.9 and later is ftp-proxy(8). (note: earlier versions of OpenBSD used a different proxy of the same name, which is documented in OpenBSD 3.8's ftp-proxy(8)v3.8).
To activate it, put something like this in the NAT section of pf.conf:
nat-anchor "ftp-proxy/*"
rdr-anchor "ftp-proxy/*"
rdr on $int_if proto tcp from any to any port 21 -> 127.0.0.1 \
port 8021
The first two lines are a couple anchors which are used by ftp-proxy to add rules on-the-fly as needed to manage your FTP traffic. The last line redirects FTP from your clients to the ftp-proxy(8) program, which is listening on your machine to port 8021.
You also need an anchor in the rules section:
anchor "ftp-proxy/*"
Hopefully it is apparent the proxy server has to be started and running on the OpenBSD box. This is done by inserting the following line in /etc/rc.conf.local:
ftpproxy_flags=""
The ftp-proxy program can be started as root to activate it without a reboot.
ftp-proxy listens on port 8021, the same port the above rdr statement is sending FTP traffic to.
To enable active mode connections, you need the '-r' switch on ftp-proxy(8) (for this you had to run the old proxy with "-u root").
pass in on $ext_if proto tcp from any to any port 21 keep state
pass in on $ext_if proto tcp from any to any port > 49151 \
keep state
Note that if you desire, you can tighten up that range of ports considerably. In the case of the OpenBSD ftpd(8) program, that is done using the sysctl(8) variables net.inet.ip.porthifirst and net.inet.ip.porthilast.
ftp-proxy(8) can be run in a mode that causes it to forward all FTP connections to a specific FTP server. Basically we'll setup the proxy to listen on port 21 of the firewall and forward all connections to the back-end server.
Edit /etc/rc.conf.local and add the following:
ftpproxy_flags="-R 10.10.10.1 -p 21 -b 192.168.0.1"
Here 10.10.10.1 is the IP address of the actual FTP server, 21 is the port we want ftp-proxy(8) to listen on, and 192.168.0.1 is the address on the firewall that we want the proxy to bind to.
Now for the pf.conf rules:
ext_ip = "192.168.0.1"
ftp_ip = "10.10.10.1"
nat-anchor "ftp-proxy/*"
nat on $ext_if inet from $int_if -> ($ext_if)
rdr-anchor "ftp-proxy/*"
pass in on $ext_if inet proto tcp to $ext_ip port 21 \
flags S/SA keep state
pass out on $int_if inet proto tcp to $ftp_ip port 21 \
user proxy flags S/SA keep state
anchor "ftp-proxy/*"
Here we allow the connection inbound to port 21 on the external interface as well as the corresponding outbound connection to the FTP server. The "user proxy" addition to the outbound rule ensures that only connections initiated by ftp-proxy(8) are permitted.
Note that if you want to run ftp-proxy(8) to protect an FTP server as well as allow clients to FTP out from behind the firewall that two instances of ftp-proxy will be required.
Trivial File Transfer Protocol (TFTP) suffers from some of the same limitations as FTP does when it comes to passing through a firewall. Luckily, PF has a helper proxy for TFTP called tftp-proxy(8).
tftp-proxy(8) is setup in much the same way as ftp-proxy(8) was in the FTP Client Behind the Firewall section above.
nat on $ext_if from $int_if -> ($ext_if)
rdr-anchor "tftp-proxy/*"
rdr on $int_if proto udp from $int_if to port tftp -> \
127.0.0.1 port 6969
anchor "tftp-proxy/*"
The rules above allow TFTP outbound from the internal network to TFTP servers on the external network.
The last step is to enable tftp-proxy in inetd.conf(5) so that it listens on the same port that the rdr rule specified above, in this case 6969.
127.0.0.1:6969 dgram udp wait root /usr/libexec/tftp-proxy tftp-proxy
Unlike ftp-proxy(8), tftp-proxy(8) is spawned from inetd.
[Previous: Performance] [Contents] [Next: Authpf: User Shell for Authenticating Gateways]