[ previous ] [ next ] [ threads ]
 
 From:  "Chris Buechler" <cbuechler at gmail dot com>
 To:  "Molle Bestefich" <molle dot bestefich at gmail dot com>
 Cc:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] problem when using VLANs and NAT
 Date:  Thu, 8 Jun 2006 13:39:44 -0400
On 6/8/06, Molle Bestefich <molle dot bestefich at gmail dot com> wrote:
>
> I'd also appreciate very much if you could elaborate a bit.
>
> I have enabled handling of fragmented packets on every single rule in
> m0n0wall, so how could this issue ever arise?  Shouldn't the
> blackholed packets just be fragmented if they happen to be too large
> at any point along the way?
>

Modern OS's all enable Path MTU Discovery (PMTUD), which means they
set the DF (don't fragment) bit on all outgoing packets.  If at some
point in transit the packet is too large and hence gets dropped (it
can't be fragmented), the system expects an ICMP unreachable
"fragmentation needed and DF bit set" message, at which point it
retransmits that packet, but smaller this time.

m0n0wall has a slew of issues with blackholing oversized packets when
there's some type of encapsulation involved (IPsec and VLAN's).

802.1Q tagging adds 4 bytes to a packet, making your maximum Ethernet
frame size 1504 bytes once the packet is tagged.  It's possible your
switch is seeing 1504 byte packets as giants and dropping them.  It's
possible the driver for your particular NIC in FreeBSD refuses to pass
anything over 1500.  It may just be that you need to up the MTU on
that interface (I'm not sure if m0n0wall does this on the back end or
not, it very well might).

I don't really have a definitive answer because I'm not intricately
familiar with the FreeBSD internals that handle VLAN's, nor how the
variety of NIC drivers can or can't affect that.

-Chris