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:
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.