http://www.irchelp.org/irchelp/security/fwfaq.html
13. Q: How does a firewall interfere with DCC?
A: DCC uses randomly selected ports, typically in the range 1024-65535 (mIRC uses 1024-5000 by default, this can be constrained in DCC options). As it is common security policy to block all "unused" ports, a firewall is often configured to block all traffic outside of common ports, or to block all inbound traffic not intended for authorized services, such as web servers. In the DCC protocol the receiver initiates the connection to the sender, so a common problem is that a firewalled user can receive but not send. In this case the firewall is not restricting the outbound connection, therefore the receiver can connect to the sender to retrieve the file, but when the roles are reversed, with the firewalled user sending, the receiver cannot connect through the firewall to retrieve the file.
Solutions for users who cannot send or receive because of a firewall:
* Disable the firewall. Probably the easiest solution, but also the least desirable, as you lose all security provided by the firewall this way.
* Configure the firewall to permit outgoing connections on any port, if it fits within your security policy.
* Configure the firewall to permit incoming connections to a range of ports, and configure clients to use those ports for DCC send, unless the ability to transmit files outside of your network is against your security policy.
Solutions for users who cannot send because of a firewall.
* Configure the firewall to permit incoming connections to a range of ports, and configure clients to use those ports for DCC send, unless the ability to transmit files outside of your network is against your security policy.
14. Q: How does NAT interfere with DCC?
A: NAT implementations are typically not aware of ports being opened on client systems behind the NAT gateway, and generally have no idea that they need to forward the incoming connections needed for DCC SEND to work. Generally, most NAT implementations will allow receiving files, but won't allow sending them. There are a few ways to work around this:
* Use the DMZ feature in many cable & DSL routers. This feature causes all untracked connections to be redirected to a single internal machine. Be aware that the machine is then effectively exposed to the internet, as if it were directly connected without the router. This method will weaken the security of the machine exposed in this manner, and will only get DCC working properly for that one machine.
* Forward a range of ports to each machine which needs to be able to send files via DCC, and configure the client to use those ports. This takes a little more work, and is more secure, but only a few transfers can be managed at the same time, and the ports for those transfers become easier to guess, potentially enabling someone to "steal" a DCC send by connecting before the intended receiver does.
* Use an implementation which tracks IRC connections, and monitors them for the CTCP handshake used to initiate a DCC transfer, automatically forwarding the needed ports.
* Implement a SOCKS5 proxy server, and DCC via it. Just make sure you configure the proxy to only allow authorized users to connect, misconfigured proxy servers are commonly used to mask the source of malicious activity, by redirecting from one internal host to another internal host. Also, a misconfigured proxy server can be used to gain access through a firewall, potentially subverting that firewall.
* Implement special client software which interacts with the firewall to request port forwardings for DCC transfers transparently to the user. This would be difficult, but would work.