Archive for the ‘Network’ Category

A few common problems when setting up a stateful firewall to allow FTP traffic.

FTP needs a separate data connection for transferring files or file listings. It has two modes of operation

passive
The clients request the server to listen for a connection. The server responds with the address and port where it is listening for the data connection. The client connects.
active
The client listens on a port for the data connection. The client notifies the server about the address and port. The server connects to the client

Stateful firewalls only allow specific traffic or already established/related traffic. Since the data connection uses a separate port it cannot easily be distinguished as being related to the legitimate FTP connection. This is where the helpers come in play.

ip_conntrack_ftp is a module that monitors ftp traffic and marks a data connection as RELATED to the control connection of a FTP session. When using the module, make sure you pass the option ports=21, or it will monitor all traffic and probably be very slow. This is easily done from /etc/modules.conf.

In order to allow data connections behind a NAT, the ip_nat_ftp module can do the trick. The ip_nat_ftp module depends on the the ip_conntrack_ftp module and does not need any parameters.

If the FTP session is encrypted (TLS for example) there is no way to statefully let the data connections through. When running a FTP server behind a NAT that allows encrypted connections the only solution is to specify the ports that it will listen on for passive connections and explicitly allow those.

After trying to use jumbo frames on my newly upgraded network and realizing that one adapter is not enough, I simply left things as they were. Come today, my NFS mounted directories on the server were unaccessible and none of restarting the NFS server (just the NFS server process, not the machine itself) unmounting the directories or trying to mount them again helped. Eventually a little playing around with tcpdump on both the server and client
tcpdump -i any port 2049 revealed that the client was sending requests and the server the appropriate responses, but for some reason the responses were not reaching the client. Quickly disabling the jumbo frames on the server ip link set mtu 1500 dev lan and everything was back in order.
Conclusion: Jumbo frames are evil.

Update: The Gentoo Linux Wiki has a nice tip about jumbo frames and NFS and why it is not good to mix jumbo with standard frames.

I got a new Intel Pro/1000 XT server adapter, a so-so switching hub (NetGear GS105) and I immediately upgraded my network. Since both the Intel adapter and the switch were jumbo frame compatible, I decided to try that feature out. Ran the following commands on the server (with the Intel adapter):
ip link set mtu 9000 dev lanand after a small delay everything seemed to be OK.

Ran the same command on my workstation — an Asus K8V SE Deluxe motherboard with an onboard Marvell Gigabit adapter. The screen froze and after a few seconds the computer rebooted. That’s with a vanilla 2.6.18.5 kernel. Gotta be more careful.