These Cisco ACLs for DCC are derived from Dave Lugo's home router with a few extra lines thrown in for completeness.
Note that filtering inbound traffic only by source port may allow undesirable traffic onto your network. Please use this document at your own risk. It is available at Rhyolite Software and the faster mirror at dcc-servers.net.
See also the DCC FAQ.
DCC traffic is very much like DNS traffic, but with port 6277 instead of port 53.
DCC client-server traffic consists of UDP packets from arbitrary and usually changing port numbers on the DCC client to port 6277 on the DCC server and packets from port 6277 on the server returning to arbitrary ports on the client.
DCC servers must exchange or "flood" checksums of bulk mail. This flooding involves two TCP connections between pairs of DCC servers. Unless the SOCKS and PASSIVE options are used, one TCP connection is originated by each of a pair of servers. Each TCP connection originates from an arbitrary TCP port on one server and connects to TCP port 6277 on the other server.
Assume that inbound filtering access-list 101 is applied inbound on the external interface facing the Internet.
Most DCC installations are of clients. Some installations also include DCC servers. It is usually desirable to have a DCC client with a local server fallback on the external, public DCC servers. This will allow query responses from external servers to reach the internal client at 192.168.7.2:
access-list 101 permit udp any eq 6277 host 192.168.7.2 gt 1023
If a DCC server is installed, and we want don't want to bother listing each flooding peer individually, this will allow inbound flooding to connections to the DCC server at 192.168.7.2.
access-list 101 permit tcp any host 192.168.7.2 eq 6277
Access-list 101 should already have an 'allow established' line that will allow return tcp packets resulting from the local dccd flooding to a remote dccd. If does not, add this for the DCC server at 192.168.7.2:
access-list 101 permit tcp any eq 6277 host 192.168.7.2 gt 1023
If the DCC server at 192.168.7.2 has remote DCC clients, and I want don't want to bother listing each client individually, then this will allow remote clients to query my dccd:
access-list 101 permit udp any host 192.168.7.2 eq 6277
If remote DCC clients are not allowed and so I do not use the preceding line, I still need to allow external checking of the state of flooding. These two lines allow `cdcc stats` requests from the two systems that maintain the server status list to my DCC server at 192.168.7.2:
access-list 101 permit udp 192.188.61.3 host 192.168.7.2 eq 6277
If no outbound filtering is currently used, this section can probably be ignored.
Assume that access-list 102 is applied outbound on the internal interface facing our protected network to limit traffic directed to the outer Internet.
If the DCC installation includes a client at 192.168.7.2 that queries external DCC servers, this will allow DCC queries to go to remote servers:
access-list 102 permit udp host 192.168.7.2 any eq 6277
If the DCC installation includes a server, and we want don't want to bother listing each flooding peer individually, this will allow outbound flooding:
access-list 102 permit tcp host 192.168.7.2 any eq 6277
Access-list 102 will should already have an allow established line or something less restrictive that allows returning TCP packets for remote dccd flooding to the local dccd daemon. If not, add:
access-list 102 permit tcp host 192.168.7.2 eq 6277 any
If your DCC server supports remote clients, and you want don't want to list each client individually, this will allow query responses to them:
access-list 102 permit udp host 192.168.7.2 eq 6277 any
If remote DCC clients are not allowed to use DCC server, external flood status checking is still needed. These two lines allow responses to`cdcc stats` from the two systems that maintain the server status list from my DCC server at 192.168.7.2:
access-list 101 permit udp host 192.168.7.2 eq 6277 192.188.61.3
A surprisingly common error is configuring firewalls to allow UDP packets carrying DCC requests from a DCC client to leave a network for port 6277 on the remote server but filtering the returning responses. This is the most common cause of the command cdcc info saying that none of the public DCC servers are working.
An easy way to diagnose this problem is to use a version of traceroute that sends UDP instead of ICMP or TCP packets. It is often necessary to make some trials with traceroute to see where firewall filtering is occurring and then set the base UDP port number or initial time-to-live value so that the probe packets with port 6277 are presented to the firewall. For example, traceroute -p6277 dcc.example.com or with smaller port numbers can uncover firewalls filtering DCC status queries.
telnet dccserver.domain.com 6277 is a simple way to test connectivity for DCC flooding.
cdcc "flood list" and cdcc "flood stats all" show what a DCC server thinks about its flooding.
Contact Vernon Schryver at vjs@rhyolite.com.