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.