I wrote this for all the firewall maintainers that need to know how to allow minimal holes in their firewalls while allowing multi-media, peer-to-peer and other functionality. The symbol "><" means "between but not equal to". If I do not specify part of the connection, assume that I mean "any". For example, if I say the client attempts to send UDP packets to the server from port X, then you must assume that it is to an arbitrary port number. When I say "to=from", that means both source and destination ports are equal. For TCP connections, you can assume an unspecified source port is in the ephemeral range for that computer. If I don't specify what protocol, assume I mean both UDP and TCP.
If you have additions, please email them to me.
Client, upon startup (connecting), attempts to connect via TCP to server (hard-coded IP?) on port 1214. Client starts to download by sending UDP packets with source port 2578 (configurable in the client options) to remote hosts with destination ports varying but in general 2001-2999. It receives UDP replies to these packets with the same endpoints. Then to actually download data, it creates an outgoing TCP session between the same port numbers that were just used for UDP. This TCP connection is formatted exactly like an HTTP connection, but for some reason does not use any HTTP proxy settings (although it appears it would respect a SOCKS 5 proxy). I believe that to be a "SuperNode", you must open port 1214.
Client gets seed hosts from server via HTTP download of file from tracker server with filename extension of "torrent". Client communicates with another client (the data "server") using destination TCP ports 6881-6889.
You must allow clients to connect to server's TCP port 7070.
You must allow clients to connect to server's TCP port 554.
You must allow clients to connect to server's TCP port 80.
After either type of request to a server, the data comes back from the server to client's UDP port 7000.
It appears the client tries to listen to port 6970. I need to investigate this more, but it freezes the Windows GUI when I run it as admin. When I don't run it as admin, it fails to autoupdate and bombs out. I'm guessing it would be UDP.
You must allow clients to create outbound connections to server's TCP and UDP port 1755. The streamed data comes in as UDP packets from server ports 1024-4999 to client ports 7000-7001.
This is actually covered in a standard, but it is similar. You must allow clients to connect to servers's port 6667.
Regarding DCC; I think you'll need special support on your NAT box, if you use one, as the IP is encoded in the data stream. I think you can specify what ports to use in the client options.
This section is under development. Welcome to MS-Windoze networking!
You must allow in and out subnet-directed broadcasts to=from UDP ports 137-138. This is to allow SMB's retarded browsing and name resolutions to work right. Thanks for filling my firewall logs and saturating my network with unsolicited "I'm still here" crap.
You must allow clients to send to=from UDP ports 137-138 for browsing and name resolution. You must allow clients to make TCP connections to destination port 139 and 445 for file, print and other services.
If you are using Active Directory, you need to allow clients to access the AD server's LDAP, DNS, and Kerberos ports (NB: since I didn't specify, that's both UDP and TCP for all three).
You must allow the server to make TCP connections to client ports 139 and 445 (these are callbacks necessary to get browsing and printing to work right).
You must allow the server to make TCP connections from port 139 and 445 to client ports >= 1024.
For unknown reasons, clients sometimes try to ping (ICMP echo) the server. Clients also occasionally try to connect to the server's TCP port 80, which may be rejected with an ICMP port unreachable. If you simply drop these packets silently, the client may experience long freezes waiting for timeouts.
MSN messenger communicates with others through a hub-type topology. It has an annoyingly short message length restriction, too. Try cut-and-pasting something in there to see for yourself.
Client talks from local port generally 4000-5000 to hub's remote port 1863. Formatting of this communication (in both directions) is similar to HTTP but using other commands instead of GET (namely, USR, CAL, JOI, MSG, ANS, IRO, BYE).When you offer a file to someone, it sends an "invitation" through the hub. The receiver sends an "accept" message in which they can request information such as your IP. Then the offering party sends an "accept" message, which can contain an IP address and port (despite this, it seems to work even if the offering party is behind NAT). This process is like the TCP 3-way handshake, but at the application layer. These are all sub-commands of MSG.
The recipient is then able to directly connect to the sender. The offering machine's port number for file transfer has always been 6891. This direct connection uses some simple ASCII commands (VER, USR, FIL, TFR) to transfer data. There is little evidence of HTTP-style headers in this connection.
I have experienced failures when using Trillian and an MSN messenger client offers a file. In some cases, it appears that Trillian does not accept invitations, and thus they time out and are cancelled. In another failure mode, Trillian accepts, gets an accept response, then tries to directly connect (sending a SYN) but never gets a SYN/ACK. I can't see any difference in the file-transfer control conversations with the hub, but it wouldn't surprise me if Microsoft somehow broke compatibility with Trillian intentionally.
I'd really like to see a network file system that only uses one open port. Until that happens, there's always NFS. Here's an article describing how to tunnel NFS over ssh. I find application-level tunnelling a little annoying; Unix really needs a good interface for that. The following is a summary of what I discovered with my particular clients. Your NFS implementation may use different ports and whatnot, so proceed with intelligence. You will need more ports than these open if you intend to do things like "rpcinfo -p", but you're hardcore so you don't need that.
The client makes UDP connections from ports 1000 >< 1024 to server port 111 (the portmapper) to find the port numbers for things like mountd. The client makes UDP connections from ports 1000 >< 1024 to server ports 512 >< 1024 for mountd. Finally, for actual NFS data transmission it makes UDP connections from 1000 >< 1024 to server port 2049. The replies are frequently so large as to fragment on ethernet.
YIM uses server port 5050. It appears to send YMSG commands and some things that look like HTTP cookies. More later.
AIM uses server port 5190. Embeds URLs into stream occasionally. More later.
Inbound connections terminate at a user-defined port which is 6346 by default.
Outbound connections to edonkey peers are generally to port 4662.
For application-level formatting of a whole bunch of relatively undocumented protocols, see the mini-TCP/IP FAQ.
I recommend that you use the logging function of your firewall. You can either try something while denying packets, in which case the protocol will not go beyond the first step, requiring iteration, or you can put in a rule to allow the packets (after logging) which will let you do it in one fell swoop. However, you should be careful to only log packets that relate to this new behavior, by allowing any known traffic types before reaching your log rule for unknown traffic.