>> For some reason, whenever I attempt to increase the MTU on my in kernel
>> pppoe interface beyond 1460, it fails:
> It does not allow you a MTU setting greater that what the ppp ipcp
> negotiation said your peer would accept. Bring the link down, set mtu high,
> check mtu and bring the link back up. You'll probably see a higher mtu with
> the link down, but as soon as it goes up, it will be at the value your peer
> requested.

Hi Martin:

You are correct, when I "ifconfig pppoe0 down", the MTU jumps up to 1492,
but then automatically drop down to 1460 when I "ifconfig pppoe0 up" and
the NetBSD negotiates it PPP IPCP with its peer.

So it looks like I am stuck with the lower pppoe0 mtu of 1460.  But I
still have the problem that Windows machines behind the NAT are unable
to use Windows Update or down load large files from some websites, even
though I am using my maximum allowed mssclamp value of 1420 in my
ipnat.conf:

map pppoe0 192.168.1.0/24 -> 123.123.123.123/32 portmap tcp/udp 20000:40000 mssclamp 1420
map pppoe0 192.168.1.0/24 -> 123.123.123.123/32 mssclamp 1420
map pppoe0 192.168.1.0/24 -> 123.123.123.123/32

and with only a MTU of 1460, I cannot use a higher mssclamp.  I heard
that Windows machines typically use an MTU/MSS value of 1480.  Even
when I lowered the mssclamp value to the recommended:

	1408 = MTU - 52 = 1460 - 52

the Windows machine still can't access Windows Update.

Note that these Windows machines are connected through a D-Link NAT'ed
router (statically) to get to the second NetBSD NAT'ed PPPoE gateway.

The wierd thing is that when I was previously running RP-PPPoE (Roaring
Pengiun) PPPoE on a older version of NetBSD on the PPPoE gateway, with
the same LAN setup, the windows machines were able to run Windows
Update, even though no mssclamp was specified in the ipnat.conf.

Any suggestions on what I can do to get Windows Update to work with the
NetBSD NAT even though my MTU and mssclamp values are so low?

Alicia.