On Fri, 27 Aug 2004, Quark IT - Hilton Travis wrote:
> Hi Fred,
> > -----Original Message-----
> > From: Fred Wright [mailto:fw at well dot com]
> > Sent: Tuesday, 24 August 2004 16:00
> > On Fri, 20 Aug 2004, Quark IT - Hilton Travis wrote:
> > > > From: Fred Wright [mailto:fw at well dot com]
> > > > Sent: Friday, 20 August 2004 12:01
> > > > On Fri, 20 Aug 2004, Quark IT - Hilton Travis wrote:
> > > > > The DNS server encountered a bad packet from
> > > > > 192.168.69.254. Packet processing leads beyond packet
> > > > > length. The event data contains the DNS packet.
> > I'm actually surprised that the client was able to get the
> > incomplete packet at all. Normally a packet is discarded
> > unless all fragments are present. A Windows "feature"
> > perhaps. :-)
> As for Windows actually receiving this packet, I'm kinda thinking that
> it saw it and dropped it because it was only one fragment in a group,
That much is normal. Fragments can get dropped by the network, so the
reassembly code has a timeout.
> and then logged the error instead of just staying quiet about it (as
> Windows normally does wrt bad sh1+ happening).
But fragments are processed within the IP code, and discarded within the
IP code when packets are incomplete. It sounds like the DNS server was
somehow able to get the incomplete packet.
> Now, as for the option of having an "allow fragments" option on the
> default rules, if this will help this error, and if m0n0wall is the
Assuming the message is correct, I'd expect it to help. You can certainly
try adding a specific rule for DNS with "allow fragments".
I do think "allow fragments" ought to be a global option. And to avoid
having to edit all the rules when changing it, I'd have three states in
the rule: allow, disallow, and default, where the last would inherit the
The WebGUI tries to discourage allowing fragments, but I think this is
inappropriate for a couple of reasons:
1) I believe IPFilter has a limit on the size of the fragment cache, so
the "DoS attacks" being referred to would only interfere with other
*fragmented* packets. This is hardly much more of a "denial" than
disallowing fragments altogether. :-)
2) Although it's true that filtering fragments involves more overhead,
that only applies to the *fragmented* packets, so it has negligible effect
when packets aren't actually fragmented.
Of course if IPFilter's fragment handling is buggy, that's a different
> cause of this error - as I mentioned, it only started happening recently
> (shortly after 1.1b17 was installed, and it continues happening with 1.1
> final) - than I agree that this should be available in the advanced
Is it really the m0n0all version, or just a coincidence?
> section. If m0n0wall is creating the problem, then it should also be
> able to uncreate it. :) If it is not the cause, I'd like to find out
> what is, and fix it there.
It certainly doesn't pass fragments by default, so that much shouldn't
have changed. Unless something shrunk the MTU, it shouldn't have caused
new framentation where there was none before.
If you can run tcpdump on the server, you could try looking for
fragmented DNS packets with something like:
tcpdump -nvs 1536 -i <interface> (udp port 53) && (ip&0x20!=0)
Or to catch DNS packets that are getting "dangerously large":
tcpdump -nvs 1536 -i <interface> (udp port 53) && (greater 1400)
You might have some client that's trying every possible combination of a
whole bunch of domains, for example.