On Sun, 18 Jul 2004, Andrew Eglington wrote:
> While using QTracker to browse a list of available game servers, many
> servers that are known to be 'up' do not display, however they are
> When I investigate the m0n0 logs it appears that their packets are being
> dropped because of fragmentation:
> 10:30:21.999866 rl0 @0:17 b [GameServerIP] -> [MyLANIP] PR udp len 20 (595)
> frag 575@1480 IN
> As a test I tried adding a rule to allow everything from this server
> through, fragmented or not:
> WAN interface
> TCP/UDP [GameServerIP] * LAN net * TestRule
> and "allow fragmented packets" for this rule IS ticked.
> But still no joy.
So you've just proved that it isn't fragmentation per se. :-) Though
allowing fragmented packets may be *one of* the requirements for making
You've removed all information about ports from the description, and not
given any details on the "no joy" behavior (i.e. do you still see blocking
at the firewall?).
The most common problem with using UDP-based protocols through NAT is that
if the server tries to send before the client, then the NAT code has no
way to know where the packets should be delivered. And in such a
protocol, the clinet typically won't send until it sees something from the
server, which it can't. So it's a deadlock.
Some protocols are like active-mode FTP, in that there's a "control
connection" initiated by the client (which works fine), and one or more
"data connections" that may operate server->client and not get along with
UDP-based protocols that are trying to be NAT-friendly *should* send
client->server first, but unfortunately some don't. If it uses a fixed
port number, you could set up NAT redirection, but that would limit you to
a single client.
The log entry above seems to show a packet getting through NAT
successfully (since otherwise it wouldn't have been rewritten for the LAN
IP), but it's not known from the above whether that's the same traffic
that has the problem after allowing fragments.