There seems to be something wrong with either ipchains or the kernel's handling of UDP port filtering. I'm using Redhat v6.2, kernel-2.2.16-3, and ipchains-1.3.9-5 straight off the RPMs. In particular, port 65535 seems to be a special case that is handled incorrectly. The following line should allow all UDP traffic above 6020 to be accepted: ipchains -A input -p udp -d 0.0.0.0/0 6020: -i eth0 -j ACCEPT However, this configuration does NOT cause connections to UDP port 65535 to be accepted, nor does explicitly specifying the port range as 6020:65535. A similar rule for the TCP side results in TCP port 65535 connections to be accepted, so this is somehow UDP specific. This is particularly tiresome if you are trying to talk to an NFS server, which periodically expects to be able to connect to UDP port 65535. The only options I have found thus far are to either blindly accept all UDP ports from the NFS server, or reverse the sense of all the firewall rules to be REJECT rules, and accept the high-numbered ports through default behavior. The significance of 65535 is obvious. This is possibly an integer/short problem, where 65535 is being interpreted as a -1 somewhere along the way. But if so, I cannot find the mistaken code segment.
Port 65535 means you're dealing with a fragmented datagram. This issue was brought up in linux-kernel a little while ago. See this and the follow-ups: http://www.uwsg.indiana.edu/hypermail/linux/kernel/0101.2/0284.html There's a way to filter fragments with -f but usually you don't want to do that.. The solution you're probably looking for is net.ipv4.ip_always_defrag in /etc/sysctl.conf.