[ previous ] [ next ] [ threads ]
 From:  "Molle Bestefich" <molle dot bestefich at gmail dot com>
 To:  "Chris Buechler" <cbuechler 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 20:02:36 +0200
Chris Buechler wrote:
> 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.

Thanks a bunch!

m0n0wall is directly connected to the server on the inside ATM, so
can't be a switch problem.

The only frames which are actually big (> 100 bytes) are those
containing HTTP content, which as you can see on the packet trace gets
through to the client just fine.

Still a bit confused, but I'll get back when I've tried your
suggestion, hopefully with success.