firewall troubleshooting
April 26th, 2005

If something stops working after you dropped in the firewall, it might be the firewall causing it. How to debug:

  1. Try pinging the server you can't connect to; if you can ping, but not connect, it does suggest a firewall issue.
  2. Check which ports the application uses, and make sure the firewall is permitting traffic on that port (usually in the 'packet filter' section in the firewall's control panel). If the port is not listed, or is blocked, then create a rule to permit traffic on that port.
  3. Try disabling the firewall momentarily, and see whether the application works again. If it still doesn't work, the firewall is not the problem.
  4. Go to the firewall console and monitor the eventlog for blocked packets, as you simultaneously attempt to connect to the service. Use the server's IP address to identify your traffic. If the traffic is being blocked, the port on which the traffic connected will be noted. Use this port number to create a rule to permit traffic on that port (usually called packet filters in the firewall setup).

Common packet filter rules

FTP21TCP in/outused by FTP protocol
SSH22TCP in/outsecure telnet
SMTP25TCP outemail (outbound)
DNS53TCP/UDP outdomainname resolution
HTTP80TCP/UDP outweb
POP110TCP outemail (inbound)
IDENT113?sometimes used during POP3 and FTP sessions
NNTP119?network news (UseNet)
NTP123UDP outtime synchronisation
SSL443TCP in/outused by secure websites (including Hotmail and e-banking sites)
RTSP554?RealPlayer (the Real Time Streaming Protocol)
H3231720?Instant Messenger (audio)
MSN IM1863?Instant Messenger
Yahoo IM5050TCP in/outInstant Messenger

Running a server

  1. ensure packet filtering rules permit traffic on the external port you wish to use
  2. set port forwarding to forward traffic on the external port to an internal machine

Some routers permit external traffic on port x to be mapped to port y on an internal machine (eg. a different port number); other routers will forward traffic only to the matching port number on the internal machine (eg. same port number).

Running an FTP server

Routers apparently translate the IP addresses in inbound FTP packets to match the remote system's external IP address (the internal address appears to be sent by the client). To identify FTP packets, routers may inspect the packet contents (application-level) or by port.

If the router in front of your FTP server does not support application-level address translation, then it probably only supports address translation on port 21 (unless other ports can be defined in the control panel).

Modern FTP clients seem to work with routers doing port translation on ports other than 21, however older FTP clients (such as WS_FTP) seem to have issues. The client typically can login, but gets a timeout on a directory listing. The FTP server log will show PORT 192,168,1,100,8,244 (note the internal IP address). The FTP server presumably tries to send the data to that address which of course fails.

The solution is either to

  1. use a router that supports application-level address translation
  2. require all users to use modern clients (such as CuteFTP)
  3. use port 21 on the server;root=equip%2C16;mode=flat