When dealing with FTP forwarding through IPTables, we face two major technical hurdles that most standard port forwarding doesn't address:
- The need to remap default FTP ports (20-21) when they're already in use
- Proper handling of the passive (PASV) port range required for data connections
Before any IPTables rules will work correctly with FTP, these kernel modules must be loaded:
modprobe ip_conntrack_ftp
modprobe ip_nat_ftp
These modules enable IPTables to properly inspect and modify FTP control channel communications, which is crucial for PASV mode to work through NAT.
Here's the working solution that handles both control and data channels:
# Forward main FTP control port
iptables -t nat -I PREROUTING -p tcp --dport 2121 -j DNAT --to 192.168.220.51:2121
iptables -I FORWARD -p tcp -d 192.168.220.51 --dport 2121 -j ACCEPT
# Forward PASV port range
iptables -t nat -I PREROUTING -p tcp --dport 11000:13000 -j DNAT --to 192.168.220.51:11000-13000
iptables -I FORWARD -p tcp -d 192.168.220.51 --dport 11000:13000 -j ACCEPT
The FTP server (Cerberus in this case) must be configured with matching settings:
- Listen on both standard port 21 AND alternative port 2121
- Explicit PASV port range set to 11000-13000
- PASV address configured to use the router's external IP
To verify the setup:
# Check NAT rules
iptables -t nat -L -n -v
# Test FTP connection from external host
telnet your_public_ip 2121
If connections fail, check these:
- Ensure modules are loaded (lsmod | grep ftp)
- Verify no conflicting firewall rules exist
- Check that the FTP server is properly configured for external access
- Test with packet capture (tcpdump) if needed
When exposing FTP externally:
- Consider using FTPS (FTP over SSL) instead of plain FTP
- Restrict source IPs if possible with -s parameter
- Monitor connection attempts in your logs
When trying to expose an internal FTP server (Cerberus FTP on Windows Server 2008) to the internet through a Linux router, we face several technical hurdles:
- Standard FTP ports (20-21) are already occupied
- PASV mode requires a range of additional ports (11000-13000 in this case)
- Traditional port forwarding alone doesn't handle FTP's control/data channel complexity
The basic port forwarding attempt:
iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 2121 -j DNAT --to 192.168.220.51:21
Failed because:
- Missing connection tracking modules for FTP
- No forwarding rules for PASV ports
- No corresponding FORWARD chain rules
First, load the necessary kernel modules:
modprobe ip_conntrack_ftp
modprobe ip_nat_ftp
These modules enable IPTables to:
- Track FTP control connection state
- Inspect PORT/PASV commands for dynamic port forwarding
- Handle the data channel negotiation
The working configuration involves multiple rules:
# Control channel (command port)
iptables -t nat -I PREROUTING -p tcp --dport 2121 -j DNAT --to 192.168.220.51:2121
iptables -I FORWARD -p tcp -d 192.168.220.51 --dport 2121 -j ACCEPT
# PASV mode data ports
iptables -t nat -I PREROUTING -p tcp --dport 11000:13000 -j DNAT --to 192.168.220.51:11000-13000
iptables -I FORWARD -p tcp -d 192.168.220.51 --dport 11000:13000 -j ACCEPT
On the Windows FTP server (Cerberus in this case):
- Configure the server to listen on both standard (21) and alternative (2121) ports
- Set PASV port range to match the forwarded range (11000-13000)
- Configure the server to advertise the router's external IP in PASV responses
Check if rules are active:
iptables -L -n -v
iptables -L -n -v -t nat
Test connectivity:
telnet your_router_ip 2121
For passive mode testing, use a client that supports passive mode and check if data transfers complete successfully.
- Limit source IP ranges in FORWARD rules if possible
- Consider using --connlimit to prevent brute force attacks
- Implement fail2ban for additional protection
- Regularly update both the router and FTP server
For more complex setups, consider:
- Using a dedicated FTP proxy like vsftpd in proxy mode
- Implementing port knocking for additional security
- Using SSH/SFTP instead of traditional FTP when possible