[ previous ] [ next ] [ threads ]
 From:  Chris Buechler <cbuechler at gmail dot com>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] accessing netbsd.org from behind m0n0wall
 Date:  Wed, 8 Sep 2004 01:22:07 -0400
On Wed, 8 Sep 2004 00:04:42 -0400, David Kitchens <spider at webweaver dot com> wrote:
> OK, since watching this thread, I feel compelled to point out that on the 4
> m0n0walls that I run for myself and clients, I have successfully connected
> to this site EVERY time on EVERY LAN. 

I checked three of mine, one of them being PPPoE.  None of them have
this issue either.  Glad to see some further confirmation.

>  None of my clients
> are on a PPPoE connection however but I can't see that as a problem either,
> the type of connection should have no difference in connecting to any site.

The MTU on PPPoE is lower (1492 vs 1500 for Ethernet for non-PPPoE
connections).  This is probably complicating this issue (PPPoE should
be avoided if possible, IMO, but frequently that isn't possible)

> The only thing I can see that is odd is that "nslookup netbsd.org" returns a
> non-authoritative answer which indicates a DNS problem which could produce a
> hung browser that you describe. 

Non-authoritative answer simply means your local DNS server has cached
the entry for netbsd.org and the TTL on the DNS record has not yet
expired.  Waiting for that TTL to expire and re-querying is the only
way to get authoritative answers (on subsequent lookups) from your
local DNS server.  This is not a problem, this is normal.

> If the site can be accessed by a Mac OS
> behind the same m0n0 that cannot access it pretty much rules out the m0n0 in
> my mind, if m0n0 was blocking the site, it would not work on the Mac either.

I'm curious of the MTU on the Mac vs the other machines.  

The root issue appears to be that he can't get fragmented packets to
be passed.  The reason the packets are fragmented is because they are
larger than the MTU of *something*.  Either need to allow fragmented
packets, which doesn't seem to be working (or maybe not the problem),
or find the MTU at fault.  Easier said than done, but if the Mac
works, then that's a starting point.

On the PPPoE LAN I tried, MTU of everything is set to default and I
had no problems.